I apologize for the subjective "best" keyword.
My friend and I have started creation of a 2D adventure game. It will be top-down in the style of pokemon or zelda (just the perspective). We have been discussing methods of creating a large world-map that the player can traverse without straining the memory capabilities of our machine.
Our first impulse was to create a large map and a circle around the player in which content will be loaded. We figured this won't hold for long and decided to partition the map into sections. First we had four large sections, but realized we could simply break it down into many tiny sections.
I played some Zelda from the SNES and saw that, during the shift of a map, the content could be loaded just then. What I mean is, instead of just checking a rectangular area for data to load, we simply section the map into many tiny chunks that load and de-load data as we move from map-portion to map-portion.
Today, he told me he wanted to create a simply 2D array map[WIDTH][HEIGHT] that contains data about every grid in the game and is a constant save-to-disk operation for data that we don't need.
I'm not sure about these ideas and thought that I might as it here. Any links, resources or tutorials on the subject would be greatly appreciated as well as direct answers to our question on how to do it efficiently.
Answer
First off, estimate your map size. Don't just assume that a "big world" is not going to fit in memory. Nowadays, a map taking upwards of 10 mb in memory is absolutely acceptable, and you can stuff a LOT in 10 mb in a simple tile-based 2D world.
If you have a really large world, the most robust solution is indeed use map chunks. Split your world into fixed-size chunks (say, 64x64). Load chunks on-the-fly as player moves around, keeping at least one chunk loaded in all directions (i.e. load the chunk the player is in and all its neighbors).
As for unloading chunks, you can choose between several strategies. Eagerly unloading means you unload and save to disk all chunks the moment player moves sufficiently far away; but you can also delay unloading to improve performance (saving chunk, as any disk access, is a costly operation).
No comments:
Post a Comment