Advertisement Jump to content
Sign in to follow this  

Storing 2d levels

This topic is 2839 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey i was curious as to how 2d levels are stored in side-scrolling games like megaman x. While i see some elements of tiling in it, in places the tiles are different sizes. I know in sonic for like curved surfaces and stuff they used masks to gauge collision, but all the tiles were still the same size. Does anyone have any ideas of how to store a 2d level (in a file) other than a matrix of tiles?

Share this post

Link to post
Share on other sites
My 2D isn't based on tiles. This is how a file for a level could look like:

56 717 // spawn
1534 647 // goal
levels\KUNG.txt // next map
1 -1 775 1685 100 misc\textures\brick_platform.bmp
3 610 739 610 739 930 739 36 36 0.1 100 50 misc\textures\bad_mario.bmp
2 279 726 279 726 430 726 68 49 0.02 misc\textures\grass_platform.bmp
1 520 665 52 52 misc\textures\brick_platform.bmp

Each line except for the three first represents a object in the world. The objects type, x-pos, y-pos, width, height and texture source are saved. For objects that needs other data to be stored, like a moving platform, I save that as well. This is working out really well and I haven't had any problems with it so far :)

Share this post

Link to post
Share on other sites
Well for starters, the reason why tiles are so common in 2D side-scrollers is because 2D console hardware used tiles as their display primitive - using arbitrary non-tile-aligned background objects was significantly more difficult and possibly, depending on the amount of VRAM available, not doable. The near-universal tile size was 8x8 pixels, but for historical reasons, the basic tile size used in games was usually 16x16 pixels. The reason for this is primarily the major influence of the NES - while the NES background was composed of 8x8 tiles, palette indices could only be set on a 2x2 tile basis.

That said, there were nevertheless several different methods of dealing with tile maps. For example, most Capcom games (like the Megaman franchise) used a simple 2D array of 16x16 tiles, going all the way back to the NES. Many Konami NES games, on the other hand, stored the level maps as a series of 32x32 pixel tiles (again, for hardware-related reasons. The palette index for a 2x2 tile block was only 2 bits in size, so 4 entries were packed into a single byte, that one byte containing the palette indices for a 4x4 tile section of screen space. Thus, using 32x32 pixel tiles, you would never need to worry about doing any bit-shifting to get a tiles palette index into the right part of the byte.)

Other games used more complex schemes. The world map in Dragon Warrior (not a side-scroller, I know, but still...) is broken up into 16x16 pixel tiles, and then stored in a run-length encoded compressed format (the American port added code to the decompressor that adjusted water tiles depending on what tiles they were adjacent to, creating the coastline while still using the same RLE map with its 16 possible tiles). Most Nintendo-made side-scrollers dispensed with storing a tile matrix altogether - instead, maps were composed of complex tile-aligned objects of varying sizes placed at arbitrary tile-aligned locations on the screen.

However, the truly interesting parts come not from the tile map itself, but from the tile metadata. For some games, this is a simple bitfield indicating whether a tile is solid or not, but often it can be much more complex. Some games have metadata that describes whether or not a tile is sloped, or if it's only solid from certain directions (e.g. you can jump up through it, but not fall down through it), or if it has special effects on the player (like propelling him skyward or spawning power-ups). Some even have "meta-objects" that can redraw background tiles in response to certain events, such as Super Mario Bros. - when the player jumps into a block from below, it triggers a collision handler that erases that block from the background, plays a sprite animation at it's location, and then redraws the block to reflect it's new state.

What makes a game like Sonic the Hedgehog possible is that is has an amazingly rich and complex set of metadata.

This may prove to be some useful reading.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!