Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351331 views, last view: 12/09/2021 06:27

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#60: editing and subdivision

by Gilt on 04/13/2004 17:02

Alright, I took a look and will start on the editing part. My todo list is at home, but so far I've got something like this:

- subdivision / reverse
- finish orientations
- texture selection
- copy / paste (move??)
- flip / rotate
- undo
- reduce, reuse, refactor

Here are my ideas for subdivision, please double check the logic:

- put subdivion algo in newcubes(). change newcubes(uint face) to newcubes(cube *p), where p is the parent the new cubes are going to model. will need to 'handcraft' global solid and empty parent cubes for worldroot, newcubes(void) etc

3 Steps for subdivision:

step 1: increase # of edges per dimension from 4 to 9.

p edges:
**
**

new:
*x*
xox
*x*

where x is avg of the * beside it, and o is avg of all x
ie: x hi coord = avg(*a hi coord, *b hicoord)
same for lo coord

step 2: expand and split edges

put proper values in '+ve/-ve' region of each dimesion.
ie: if p hi coord < 5 then +ve is empty, -ve edge is 2*p edge
if p lo coord > 4 then -ve is empty, +ve edge is 2*p edge - 8
else p edge covers both regions and needs to be split.
splitting then is:
+hi = 2*p hi - 8, +lo = 0
-hi = 8, -lo = 2*p lo

step 3: assign the new edges to the new cubes.
----------------------------------------------

Does this look right? I suppose these steps could be combined in some fashion. Or does anyone else have other ideas for how subdivision should work? If not, I'll try coding this later tonight, or sometime soon.

also, what are the opinions on when the reverse should be used? when a cube is modified using a larger gridsize then it? personally I don't like that idea, but we'll see. Either way, the reverse should simply use lod data (ie: just discard the children).

reply to this message

#61: Re: editing and subdivision

by Thalion on 04/13/2004 17:31, refers to #60

Good to see someone who knows how it all works.
... because I surely don't =)

reply to this message

#62: Re: editing and subdivision

by Gilt on 04/13/2004 17:42, refers to #61

shush, don't jinx me :) I still haven't tested it to see if any of that actually works.

reply to this message

#63: Re: editing and subdivision

by pushplay on 04/13/2004 21:31, refers to #62

Step 2 went over my head. Step 1 looked right though. It confused me at first cause you're not really going from 4 to 9 but from 4 to 16.

As for the reverse, I would expect it to do exactly the opposite:

p edges:
*x*
xox
*x*

new:
**
**

discarding x and o. As for who wins the texturing, there's no simple solution so I would just pick the top right one or something.

reply to this message

#64: Re: editing and subdivision

by Aardappel on 04/13/2004 23:53, refers to #60

Looks mostly alright, just "newcubes" is pretty much just a contructor function, and probably not the place to do this. The actual subdivision happens from lookupcube() or whatever it is called when you try to lookup a cube size that is not there. There may be the place where you want to insert a function that takes the big cubes and the result from newcubes and set the edges to something as fitting as possible, pretty much as you describe.

The reverse happens when someone does an editing operation (such as the regular "face move") with a grid size bigger than the size of the cubes indicated. It will be hard to do a good job here, and I am not sure its even worth doing, but you can for sure try.

Sounds all cool, let me know when you have it all working and you are ready to get commit access.

reply to this message

#65: Scripting

by macdonag on 04/14/2004 08:17

Anyone got an opinion on scripting for Sauerbraten? I was thinking Lua would be a good match: simple, comes in a 'module' that can be kept seperate from the main code, relatively fast, and very easy to integrate. I'm not so sure about other languages, but have experience integrating it with a PS2 FPS engine.

I think having it in at this stage, along with some simple hooks could lead to some interesting areas.... Opinions?

reply to this message

#66: similar ideas

by shahar2k on 04/14/2004 08:38

In response to how the world actually "works" it is similar to the way Metal Gear solid, the original Soul Reaver, or Tomb raider operated, where the world is devided into cubic volumes, and each edge on the cube can be "pushed" in a direction to make the inside of the cube less than the entire volume...

the diffrence between sauerbraten and those other games, is that Sauerbraten also allows you to take any world cube and either subdivide it (into 8 cube volumes with sides half as long) or combine 8 volumes up to 1 larger volume... basically it allows variable cube sizes...

I hope that made things clearer, I'm not really a programmer, more of a modeler/animator/UI freak so if you need anything along those lines, I'll be happy to give from my free time

reply to this message

#67: Re: Scripting

by Thalion on 04/14/2004 16:25, refers to #65

Aard has got an opinion; at least it was there last time we met on IRC =) In two words: no scripting. And trust me, there are good reasons for that.

reply to this message

#68: Re: Scripting

by macdonag on 04/14/2004 23:59, refers to #67

Ok, so any chance someone could tell me what the 'good reasons' are?

reply to this message

#69: Re: Scripting

by Aardappel on 04/15/2004 00:22, refers to #65

That opinion I had was about cube, and indeed my opinion is similar about sauerbraten, but has slightly different considerations.

First, one reason I am not interested in scripting for cube, is that the cube engine serves the cube game, and I am the game designer of the cube game. I don't want too much scripting in the cube game because I am trying to achieve a certain kind of gameplay, and I have bad experience with level designers trying to butcher games into something it was not meant to be.

Sauerbraten is a different story. It is more meant to be more generic engine for multiple games, and also, no matter how hard I try having people adhere to my "minimalism" code style, having it made by multiple people will mean it won't be as minimalistic an engine as Cube (its more involved implementation wise too).

So there could be a scripting engine at some point. Though I would suggest keeping that till later, when the core engine features are done. Lua is certainly one of the best out there, but I'd also be interested in making something really good for game scripting... remember I actually know more about compilers than I do about game engines :)

And really, the current scripting engine actually allows you to write a wide variety of custom gameplay... the work is just in exposing more of engine internals to it.

Any scripting also has to overcome the security issue (client side gameplay).

reply to this message

#70: .

by Gilt on 04/15/2004 00:33

Ok, I've written up some code, and while I'm pretty sure the code and spec is right, I think my understanding of how everything is stored might be off. so just to clarify, is this how it is?:


children stored like this:

:: 0 1 2 3 4 5 6 7
z: - - - - + + + +
y: - - + + - - + +
x: - + - + - + - +

or visually:
http://server6.uploadit.org/files/hapoooo-cube.JPG


Edges stored like this:
[z0][z1][z2][z3][y0][y1][y2][y3][x0][x1][x2][x3]
http://server6.uploadit.org/files/hapoooo-edge.JPG

start of edge spans are at -ve end of dimension, and end near +ve end.

and with the faces, what exactly are the 2 perpindicular faces that the edges describe?

reply to this message

#71: Re: Scripting

by macdonag on 04/15/2004 00:50, refers to #69

Ok, that's more like what I was looking for.

All these points are good, I'm more curious than anything else, I've only gotten as far as building & running the engine on the mac & scanning the code, so haven't had a chance to try out anything yet...

Regarding the 1st reason, (for the sake of a wee debate), my initial thoughts of a scripting language (like Lua) would be less for designers, and more for programmers to prototype things for the sake of rapidity or simplicity. I'm inclined to think letting designers get too low-level is a bad move, and something more restrictive would be more appropriate for a designer (something more customised to a game-type). As always there are pros and cons, it depends on how technical a designer is etc., and the distinction is less clear cut in amateur game-design circles than in the commercial world. I'm rambling here, but this is what I've seen/is my opinion.

As for the 2nd, I like the idea of minimalism, but like you seem to admit, the engine will grow in directions you care less about. Keeping it modularised to some extend (as Lua is) helps maintain minimalism whilst allowing growth (obviously). The fun starts when you have hooks into Lua (or whatever) from all over the engine - that would surely become a bit messy!

As for the 3rd, I know about your background and will admit that's one of the reasons I'm attracted to the project. I played with Amiga E for a bit back in the day and liked it. Having looked at it, the minimalistic style has produced something I can quickly understand and modify/enhance. I look forward to contributing something interesting!

And finally, as for the security issue, I'm no expert. I did some Unrealscript editing for another FPS-type game, to get the initial network prototype going, but without worrying about security too much. I can fully imagine there would be issues. I just haven't thought much about it yet. :-)

Cheers.

reply to this message

#72: Re: Scripting

by Thalion on 04/15/2004 03:56, refers to #71

Please don't forget that, due to the nature of Cube's thick-client-thin-server networking code, scripting may (and will!) be abused. If you have hooks all over the code, and these are easy to redefine without recompiling the engine, we'll have all kinds of aiming helpers and super-mega-ultra-shotguns and health replenishers in a week after the release =)

reply to this message

#73: Re: Scripting

by macdonag on 04/15/2004 08:23, refers to #72

Any hooks would be defined in C - we're just creating an API for use by the scripting language (eg, set animation, change position, play sound,...)

These would be used for, say, door code. A trigger would set off the script which would perform the animations, sounds of the door, take care of any special cases (it's locked, don't close if someone else is under it, don't open if damaged, etc.).

This is just a small example of the type of situations I had in mind, a generic door, not a custom thing created by a designer. Think of defining AI in a scripting language rather than C. A situation we want to test can be set up, and the scripts continually edited, reloaded, run, without ever leaving the engine or the situation set up.

It makes it easier to test things, to play around in very fuzzy situations (like AI), where there is no right solution, just levels of goodness(!)

Whether we allow poeple to redefine scripts after the fact is a matter of taste. We could include checks (MD5?) so everyone agrees they have the same scripts, so that the playing field is level on multiplayer. Besides, things like weapon results, any game code should be performed on the server, not the client. Client should stick to special effects, etc. Assuming you have a simple client/server model here.

And having thought a bit more of security, in the case of actually allowing people to edit scripts once a game has been 'released', we'd have to be *very* careful about what we can let them do - I guess removing the ability to write to file etc....

reply to this message

#74: Re: Scripting

by macdonag on 04/15/2004 08:25, refers to #73

Having re-read the last post a bit, and not knowing the client/server code, if there is a large amount of trust left to the client, there would be problems...

reply to this message

#75: Re: Scripting

by Aardappel on 04/15/2004 09:57, refers to #74

yes there is... that is the issue. Though there is no reason why we couldn't move the gameplay to be more serverside if sauerbraten becomes a more "serious" (cough) engine than Cube.

reply to this message

#76: Re: .

by Aardappel on 04/15/2004 09:58, refers to #70

Gilt, no idea, I would have to reread the code as much as anyone else to figure out the axes... I am one of those "run it, if it doesn't work swap the - sign" amateur graphics programmers :)

reply to this message

#77: Re: Scripting

by Thalion on 04/15/2004 10:44, refers to #75

Please, no! =) One of things which make Cube so attractive is its superb ability to provide smooth gaming experience even on crappy connections (e.g. dialup).Remove that, and half of fun is gone.

reply to this message

#78: Re: Scripting

by Aardappel on 04/16/2004 20:29, refers to #77

well, its either that or keep the gameplay simple & unmodifyiable as it is now.

reply to this message

#79: Re: Scripting

by pushplay on 04/16/2004 20:35, refers to #78

If you want to do more than a basic hack and slash style rpg, some form of scripting is the order of the day. I really like the visual scripting in radiant with triggers and arrows, but that's not really apropriate for Sauer, is it?

reply to this message

   Board Index