Re: Representing 3d Staircases? (Python)

You want to look into how Minecraft is implemented: it is exactly what you want to do here.  Though I'm not sure how you're going to get around the "vertical HRTF sucks" problem.  I imagine that's where you'll stop, but since I've had ideas on this myself, maybe it can be done.  If you are hoping to do a staircase without any tiles at all, you'll be disappointed: even sighted games that use voxels use voxels for those parts of the geometry.

And yes, the magic Google word is voxel.

You can save on resources by encoding your map in run-length encoding.  That is, pick a  dimension (say z), then instead of having the map be a big 3d array, it's a 2d array of lists, and each list looks a bit like this:

[(ground, 0, 5), (sand, 5, 7), (air, 7, 15), (cave ceiling, 15, 20)]

Where the numbers are the start and stop for each tile in that vertical column.  Because most tiles are air, and because when they aren't they're usually runs of the same thing, you can compress the map very significantly--significantly enough that being thousands of tiles in all dimensions is perfectly possible on a laptop.  There are libraries for this I believe: it's called run length encoding.

Go two steps further, though: first, never record the default tile at all.  Second, replace your tiles with integers that refer to a tile in the tile map.  Then you have tuples of 3 integers each, and you can grab Python's built-in array module, which will pack it as efficiently as C.  Concretely I'm suggesting 3 arrays, tile, start, stop, that represent the parts of the tuples.

Go one step further still: you don't do (tile, start, stop), you do (tile, start, distance), and you say that distances will never be more than 255.  Now the array for distance can be a byte instead of a multi-byte int, for another factor of 2 (or 4) on savings, and when it needs to be more than 255 you just add another entry with the same tile (and because you never record the default tile, this almost never happens).

As for accessing this, you find the x and y in the obvious manner, then you do a binary search on the entries in the column to find the one that's closest to where you need to be.  Then either it's covering the coordinate you're interested in, or the coordinate you're interested in is the default tile, which is probably air.

Make the default tile air and you don't pay for huge caverns *at all*.

Next run this through cython, possibly with some type hints, and you'll be able to handle 1024 tile cubes like they're nothing at all.

"But that's not enough," I hear you say. "It's no good unless it can simulate a whole planet": to get that, do the following.

1. For anything beyond a certain distance from the player, stop simulating it all together. It can be in memory but you never touch it (note: you need something like an octree to efficiently find out what's close to the player);
2. Learn about mmap, which lets you treat files on disk like they're actually in memory, and the OS will handle whether it is or not for you depending on what's available (if you're wondering how big multi-terabyte databases work without going insane with seek calls, this is it);
3. Change the top-level x/y coordinates from an array to a set of boxes, where each box is a file on disk that's run-length encoded, so say 128 by 128 squares, and load/unload them on demand; and
4. If you need to do really complicated physics, fully decode the world into a 3d array for some distance around the player on demand.

You can do all of this in Python unless you decide you need to do graphics, but you can probably also do the graphics in Python.  Some of it requires numpy and some of it requires cython, it won't be as fast/lean as if you used something else, if you try to go multiplayer you'll very quickly need threads (since everyone can be very far apart from each other).  But yeah, Python scales out this far.

And for the trade-off: you lose read performance.  Not enough that the level editor is going to care, but enough that if you want to do minecraft-style falling sand or pistons or something you'll need to do further optimization.



-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : ogomez92 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : ogomez92 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : ogomez92 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : amerikranian via Audiogames-reflector

Reply via email to