Sign in to follow this  
Replicon

Level format in sprite-based games

Recommended Posts

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 :).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this