Level format in sprite-based games
Author
In a basic tile-based RPG, it's pretty easy to represent a level as some kind of 2d array of tile references or something. Then, some tiles are walkable, and some aren't. But what about storing walkable areas in more complicated worlds? A perfect example of this is Contra 3. Sure, basic platform scroller, but the ground isn't always level. There can be various ramps and stuff. What are some standard ways to represent that?
Would there maybe be a third type of tile (walkable, non-walkable, and ramp)? Then, if we enforce that a 'ramp' has to start at the lower left corner of a tile and end at the upper right of some other, it's not too hard to add some metadata from which the current height can be calculated, and have our side scroller character walk up a ramp nicely... But there's gotta be people who've spent more time pondering this than 15 minutes :).
How about encoding the height of each of the 4 corners?
Then you can do generalized linear interpolation to determine height.
Then you can do generalized linear interpolation to determine height.
Quote:Original post by Replicon
Would there maybe be a third type of tile (walkable, non-walkable, and ramp)?
This is pretty much how I do things - I've got a few types of tile: solid, air, and heightfield. Solid is totally impassable and gets used for walls (and occasionally ceilings). Air is just empty. Heightfields are like heightmaps, except they're 1D.
Heightfield are created as 32x32 images (the same size as my tiles) and are only black and white (no greyscale). At load time these are read in and converted to a 1d array of heights. Then objects move along the top of this heightfield.
This has the advantage of being per-pixel heights (ie. lots of wobbly ground) and dead easy to create (compared to messing with ramps of different angles) and collide with. The disadvantage is that (much like a heightmap) you can't have overlaps, so things like loops aren't possible.
The image->array conversion is pretty quick, but to save disk space I'm eventually going to do the conversion at compile time into a simple bit of xml which is easy to read in and doesn't require preprocessing.
You can always define your levels as an arbitrary collection of polygons; this is how Soldat does it.
The problem with defining levels as a bunch of polys is that levels end up looking like a bunch of polys. (Although it would be a good solution to the overhang problem). And it's much easier to pathfind around a tiled environment, which may be important.
Having said that I keep meaning to try using polys (or rather, lines) rather than tiles, as it'd make it easier to add random variation and more precise placement.
Having said that I keep meaning to try using polys (or rather, lines) rather than tiles, as it'd make it easier to add random variation and more precise placement.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
