In celebration of the end of exams... (armagetron3d)

[Infa(mous)]

Ummmm.... Is armagetron3d supposed to be able to play on a regular server?

[Tank Program]

No, it's not two way compatible because of added data types. I have a few ideas for fixing that, but it needs more thought.

[Infa(mous)]

Ah. Ok, then.

[wrtlprnft]

No, it's not two way compatible because of added data types. I have a few ideas for fixing that, but it needs more thought.

Just use the protobuf branch as your base, where it comes at zero cost.

[Z-Man]

Yeah Just add the z coordinate this way:

Code: Select all

// message for coordinates
message Position
{
    optional float x = 1;
    optional float y = 2;

    // legacy message end marker, extensions go after it
    optional bool legacy_message_end_marker = 20000;

    optional float z = 3;
}

and you'll be automatically compatible.

[wrtlprnft]

z is an int in guru3's implementation of tCoord, which doesn't seem to be all that future-proof
Then again, it's just a test.

[Tank Program]

I think it could be a float as well, but I was having problems with lack of collision detection and luke-jr was talking about floats never being equal so I switched it to int for the time being.

How hard would it be to switch base branches? Create a diff and then repatch or do some funky merge-ness?

[Z-Man]

Yeah The proper way to go multi-layer and full fancy 3d without too much trouble would be this:

Split the current tCoord into tCoord2D (which is left as is) and tCoord3D (with added float z); probably they should inherit from a templated vector class. typedef tCoord3D to tCoord. All the functions there still make sense, except Turn(). Add a second parameter to that: the top direction. For operations on game object directions, the top direction is taken as the normal of the current face it resides on, which currently would be just (0,0,1). Rewrite the camera to use full 3D tCoords instead of a 2D tCoord and a separate Z value, using the current game object's top direction to determine what means 'up' currently. We have to rewrite the ugly camera anyway, so here's our chance.

So far, nothing has changed, really The next step is to adapt eGrid to the possibility of non-flat surfaces (give it a good rewrite, too, while you're at it), adapt the rendering code so it can render those grids (and walls and objects on them) correctly, adapt the game code so it selects suitable driving directions, add game objects that allow teleports between different grid positions, implement new map elements, and profit.

[wrtlprnft]

I wonder if the game engine itself should use full 3D coordinates at all. What about an approach where only the rendering code translates/rotates each grid to its proper location, but the game engine has no idea about the third dimensions?

I think really flying cycles aren't a good idea, anyways. Tank's solution works because there are only two levels, you could realize that with a second transparent grid right above the normal one, with the zones just teleporting between those two (or screw zones and replace them by real ramps implemented as seperate small grids)

[Z-Man]

I wonder if the game engine itself should use full 3D coordinates at all. What about an approach where only the rendering code translates/rotates each grid to its proper location, but the game engine has no idea about the third dimensions?

That would make the game code for moves over edges between surfaces a lot more complicated. I don't think it saves enough work to be worth the extra complexity.

[wrtlprnft]

That would make the game code for moves over edges between surfaces a lot more complicated.

Would it? I was thinking of defining teleport lines, so you'd say, “if someone crosses that line at X percent of its length away from a specific end point, then the cycle has to go to the point that 's X percent away from <other line>'s endpoint (and on the line), with <specific axis mapping> (and possibly on another grid)”.

Those lines could either be automatically generated or left for the map designer to place (or both). That would easily enable you to make grids with holes in them (just surround an area with walls and/or teleport lines to grids that act as ramps).

That's just my instinct on how I'd implement it, I'm ready to go with whatever you come up with, those things usually turn out to be quite well thought out

[Tank Program]

I've merged in the experimental protobuf code, this breaks compatibility with previous bzr revisions of the armagetron3d branch, but restores compatibility with normal clients and servers.

[Al's Used Cars]

Could someone write a little how-to for compiling this interesting branch on Mac 10.4? I've got the files through bzr, but don't know what to do with them. I have some ability with Terminal (unix) but not a lot. Thanks.

[epsy]

http://www.lmgtfy.com/?q=how+to+build+a ... nad+on+osx

[Infa(mous)]

Hey again. Since protobuffers got merged in with armagetron3d, i haven't been able to compile it. A few of the problems I noticed is that there is no libprotobuf.cbp, and that it isn't compiling nprotbuf.