tiles - 2D Top down view maps

I was wondering how this works.

Do you load the complete map when the game starts up, or do you load parts of the map at runtime?

And how would you save the maps? Would it be in XML or some binary format?

Thanks!

Answer

I agree with eBusiness. It depends on the size and how you want to edit it.

Estimate the byte size of your map in a reasonably compact representation. Also decide which parts of the map can change as the game plays. Those parts that don't change can be loaded and don't have to be saved. If the estimated size is small, just store everything in memory. It's not worth the extra complexity of loading parts of the map and tracking what you've loaded or not, unless the data is so large that it's necessary.

For example if you were writing Civilization II, your map size might be 100x100 tiles.

1. Each tile is one of 12 types, so you can store that in 4 bits. That means the main map is 100 x 100 x 0.5 bytes = 5,000 bytes to store the tile types. The main map never changes.



2. You can also improve map tiles with roads, irrigation, etc., and there are up to 7 improvements. That means 2^7 different values, taking 7 bits, but we'd probably just use 1 byte for it. That give us 100 x 100 x 1 byte = 10,000 bytes to store the improvements.


3. The fog of war tells us which map tiles you've seen, so you need 1 bit per player. If you limit to 8 players, that's another byte per map tile, or 10,000 bytes for the fog of war.


4. Finally, there are all the cities and units. You might estimate that each player has up to 20 cities and 100 units, and each of these might require 100 bytes of data (wild guess), so that's 12,000 bytes (much more if you're using XML).

That's under 30k for a compact binary representation the Civ II map + objects, so you can store all of it in memory, even if you use a verbose format that's much larger. I got the above numbers from someone reverse engineering the Civ II map structure.

Daggerfall, considered by some to have a ridiculously large map, appears to be 5000x2500 and around 25 megabytes, but it also has a large number of NPCs (750,000 is what I've read but that seems very high). On today's desktop/laptop machines this too could fit into memory, but on mobile devices or browsers that might be a bit too big. There's a wiki describing the Daggerfall map format.

You can reduce the size by identifying and factoring out redundancy. For example, instead of storing 100,000 identical trees or swords each in an XML format, store one tree and one sword and 100,000 references to them. In the binary formats that reference might be only 1 or 2 bytes, and in a more verbose format the reference can still be reasonably small.

Do the simplest thing that works for your game. If the map is small, it doesn't matter if you use a compact or verbose format. If the compact format would fit into memory but the verbose format would not, you have to decide whether the extra work of the binary format is more or less than the extra work of loading portions of the map. That'll depend on the game. In a Civ-like game where you need all the data to simulate turns, the binary format is probably a better choice. In a Daggerfall-like game where you don't need to load areas except what's near the player, loading portions of the map is probably a better choice. If the map is so big that even the compact format won't fit in memory, then first ask yourself if it's really worth all the extra work to deal with it, and if so, design a binary format that you can load portions of.

For my current (hobby) project, the maps and all the objects on them fit into 50 MB, so keeping it all in memory would be fine. However, I want it to run in the browser, and 50 MB is more than I want to transfer over the network, so I'm keeping them all in memory on the server and then loading only parts of the world in the client. My map tiles are 1 byte per tile, 2048x2048 tiles (4 MB). The objects (trees, chairs, orcs, etc.) are JSON-encoded for simplicity. In the client I only load the map areas (including their objects) that are near the player.