Some details on the game?

[UNITiS]

I do realise I shouldn't make new topics that frequently, but does anyone know how the maps are saved. Like how exactly the map format works as well as how the server sends the map to the client? I'm working on a game of my own (again) and I'm wondering on how AoS did it.

[Jdrew]

He used the voxlap engine so just check that out and you might find the answer, good luck with your new game.

[UNITiS]

Basically, I need to figure out a way to send the map to the player as he joins the server. The problem I have is that a map 512 x 128 x 512 large (That's X x Y x Z) would be 32mb large and that's only keeping the block types. Later I'm planning to add more values which will have to be kept as well. I don't like the idea of only sending the surface to the player as I really like the idea of having caverns and such. So I guess I'll have to figure something out :/

[HoboHob]

Some resources:
VXL File Format Documentation
The VXL file format that basically stores a 512*512 2D array of 'runs' which have a color (only the top block), and a height. Atleast this is how I understand it.
You could also take a peek at the VXL loading code from the Voxlap engine
The topic for the Voxlap port
And the PySpades protocol documentation on the AoS Dev wiki
Also you should take a look at the PySpades source code

I believe pyspades is coded in Cython.

[Sonarpulse]

All good links, except "Voxlap" will never become "GNU Voxlap", because ken won't let it be licensed under the GPL.

[UNITiS]

Thanks

[HoboHob]

All good links, except "Voxlap" will never become "GNU Voxlap", because ken won't let it be licensed under the GPL.

snap :(

[VladVP]

If you wan't an even better clue, this is the networking library that AoS uses: http://enet.bespin.org/
And here's a(n un)complete reverse-engineer of the AoS network protocol: http://aoswiki.rakiru.com/index.php/Ace ... s_Protocol
I know, I know, it's not exactly what you're asking for, but it should still be quite a clue.

[rakiru]

All good links, except "Voxlap" will never become "GNU Voxlap", because ken won't let it be licensed under the GPL.

This is good. The GPL is fucking horrible.

[GreaseMonkey]

Important note, I actually know what I'm talking about here, and people will be able to vouch for this.

Basically, I need to figure out a way to send the map to the player as he joins the server. The problem I have is that a map 512 x 128 x 512 large (That's X x Y x Z) would be 32mb large and that's only keeping the block types. Later I'm planning to add more values which will have to be kept as well. I don't like the idea of only sending the surface to the player as I really like the idea of having caverns and such. So I guess I'll have to figure something out :/

With respect to Voxlap, a 512x128x512 map will (typically) not take up the hypothetical maximum of 128MB in memory, as the client stores the map as a 512x512 array of pointers (1MB overhead, 2MB if using a hypothetical 64-bit version) to the pillars you see stored in .vxl files. Yes, AoS can hypothetically handle a 128-high map, but pysnip will not allow it as that stores the map as a raw 512x512x64 array from my understanding.

The vxl format packs really, really well. I've tried making a Z-encoded octree thing but that doesn't pack as well.

Argh, some post I forgot to send... I need to go so feel free to ask me stuff for when I come back.

[Sonarpulse]

This is good. The GPL is fucking horrible.

I mean it does what it set out to do. I say it and MIT/BSD are both valid choices, just for good different circumstances.

[GreaseMonkey]

OK, quick crash course on the .vxl format.
It is a 512x512 array of pillars of varying length. Each "dword" is 4 bytes, and can be one of two things:
- Gap dword: N S E A (N is the first byte, S is the second and so on)
- Colour dword: B G R L

Note, a height of 0 is the topmost layer of the map, 62 is the unbreakable ground layer, and 63 is the unbreakable-or-else-the-game-tends-to-crash water layer, which is also the bottommost layer. Increasing makes you go down (it's actually more natural that way if you think about how a framebuffer is arranged).

It starts with a gap dword.
S and E denote the start and end of the lower visible blocks, inclusively.
N, when not 0, denotes the distance between this gap dword and the next one; i.e. N-1 is the number of colour dwords that follow.
If N is 0, this is the last gap dword of this column, and the next (E-S+1) dwords are colour dwords, and then that's the end of this column. Move onto the next one.
A denotes where air starts, inclusively, although for the first gap this is ignored and treated as negative infinity (and you should set it to 0 by convention).

You may notice that (N-1) tends to be greater than (E-S+1). Remember what I said about them being called "gap" dwords? To draw the upper blocks, you go back a dword for the immediate ceiling, then back another dword for the one above that, and so on, until you hit the previous gap dword.
The typical convention is that you draw the last (N-1)-(E-S+1) blocks, where N,S,E are from the previous gap dword, although if you really want to be an asshole and you have the vanilla server, you CAN make a map where the first ceiling block has a different bottom colour than its side colours (but as soon as you affect that column or one of the adjacent columns, it will change to something saner).

If E = S-1, then there are no "lower" blocks, the gap is 0-high, and all you have are "upper" blocks. mesa.vxl has this happening with the many cacti around the place.

Colour dwords are simple. B G R denotes blue, green, red respectively. L denotes the light level (recalculated in the client so effectively useless) and is typically 0x7F in everything that isn't made by VOXED.

I have made extensive use of this format, internally, in both Iceball renderers, especially the software renderer... although I tend to do the (N-1)-(E-S+1) cheat for the upper blocks instead of Raycasting Like A Boss as Ken Silverman probably did in Voxlap.

Does that answer your question?

[VladVP]

[quote="GreaseMonkey"][/quote]
+1

[UNITiS]

Important note, I actually know what I'm talking about here, and people will be able to vouch for this.

With respect to Voxlap, a 512x128x512 map will (typically) not take up the hypothetical maximum of 128MB in memory, as the client stores the map as a 512x512 array of pointers (1MB overhead, 2MB if using a hypothetical 64-bit version) to the pillars you see stored in .vxl files. Yes, AoS can hypothetically handle a 128-high map, but pysnip will not allow it as that stores the map as a raw 512x512x64 array from my understanding.

The vxl format packs really, really well. I've tried making a Z-encoded octree thing but that doesn't pack as well.

Argh, some post I forgot to send... I need to go so feel free to ask me stuff for when I come back.

I'm not using Voxlap, I'm using a custom terrain code I wrote myself. I just thought that if I figure out on how AoS stores it's map data and sends it over to the client, I'll be able to "improvise" on my own code to improve it. Thanks for explaining the .vxl format in your last post btw.

[GreaseMonkey]

If you want to improvise, you could consider packing the format down into smaller entries, say 16 bits each. For the gaps, you could either keep them at 32 bits, or pack them down to 16 bits somehow (I have done the latter before).

If you'd like to retain non-visible blocks, however, and you're going Minecraft-style with each block having a block ID, you could possibly do [x][z][y] bytes (or 16-bit words, if you're going hardcore) and doing some form of RLE compression. (RLE can help zlib compress stuff better)

But yeah, if your main aim is better compression, Z-encoding + octrees isn't actually that great.