Good map section loading strategy?

So, I want a very large game world. I know it can be done as I've played The Faery Tale Adventure on the Genesis.

How do developers handle the transition between one block of map data and going into another? All I can think of is duplicating the edges of map data from adjacent maps so it "looks" like they are connected. It seems wasteful. Another thought is to use a 64x64 variable array as a collision map and load new values as I draw new chunks of map on the screen. Again, seems wasteful.

What techniques do other people use? I'd rather shoot for DaggerFall than Shove-It
tongue.gif
 
Sonic uses a flag in the block map - when you hit certain blocks, the flag tells the game engine it's time to load a set of tiles that nearby blocks will need for the display. The engine decompresses the tiles into vram. The block map is 128x128 (Sonic 1) or 256x256 (all other Sonic games). Only some of the tiles are changed - just the ones that are different. The common tiles are used to tie the blocks together seamlessly. So when you build the level, you have to make sure the unique tiles are not so close together that unique tiles from nearby blocks are visible at the same time.
 
This might be too much of a departure if you've already defined your basic map structure, but Metroid has an interesting system:

The only "real" map is the top-level world map, a 16x16-byte array of screen numbers (so a total space of 256 screens theoretically, but many positions are empty and some screen numbers are reused with different tilesets, so there are nowhere near that many unique screen layouts).

Each screen number has an associated list of objects to stamp out to build that screenful of the world.

Each object is a ragged array of metatile numbers.

Each metatile is a 2x2 array of the pattern numbers that go in the VRAM name table.

So when entering a new screen, the game looks up its screen number and walks the object list to render that screen into VRAM. Transitions to new tile/enemy/code sets (there are five sets, one for each "area": Brinstar, Norfair, Kraid, Ridley, and Tourian) are handled with the elevators. This is mostly tied to the game originally being on FDS and thus needing to stop to load from disk.
 
@ExCyber: That's pretty cool info
smile.gif
I just watched the Classic Game Post Mortem for Pitfall. Those old school pioneers were smarter than the average bear!

@Chilly Willy: Again, very cool ideas! Loading map data by object trigger is something I never thought of.

I suppose I could have arrays for local -> area -> world. I'd use a pseudo random number generator to fill in the generic tile info such as plants and rocks. Any custom info such as pre-made towns and dungeons could be in an overlay array. That's almost DaggerFall/Oblivion like I think.
 
So, my thinking is, each point in my map will be a 16x16 tile chunk of landscape. I'll be using the 256x224 video mode. In order to fit 30x30 chunks of landscape plus 3 chunks around it (for the edges of surrounding maps) I'd make a 36x36 array. Basically padding the edges with data from adjacent maps. In my engine every 128 pixels of movement I draw 3 chunks of landscape ahead. When the player gets within 3 landscape chunks of the map arrays boundaries I recreate the map array. I put the new map area in the center 30x30 and then take the rightmost 3 columns of landscape chunks from the map to the left. Same deal with the top 3 rows: they get the bottom 3 chunks from the map above. Below gets the topmost 3 rows of chunks of the map just below etc..

So, I use up RAM in a 36x36 integer array but the player gets a seamless world to scroll through. The player gets 10x10 screen maps while being able to see and interact with adjacent maps (no visible borders). Player changes to environment wouldn't get reset until they reach a new map of 10x10 screens. Am I making any sense? Does this sound like a good idea?
 
Back
Top