Map with 20 million tiles makes game run out of memory, how do I avoid it?

Question

While loading extra huge maps, the loading method throws out of memory exception where a new instance of map tile is created. I'd like to have whole map processed at least on server app (and on client if possible). How should I solve this problem?

UPD: the question here is how to make the game stop crashing when there's still free memory for it to use. As for splitting map in chunks, it's a good approach, but not what I want in my case.

UPD2: At first I went and assigned a texture to every new instance of tile class and that's what took so much memory (also loading time). Now it takes about four times less space. Thanks to everybody, now I can run huge maps without thinking of breaking them up in chunks just yet.

UPD3: After rewriting the code to see if arrays of tile properties work faster or consume less memory (than said properties in their respective tiles as object properties), I found out that not only it took me a lot of time to try that, it didn't bring any performance improvement, and made the game terribly difficult to debug.

Answer 1

the app crashes when it reaches 1.5Gb.

This strongly suggests that you're not representing your tiles correctly, as this would mean that each tile is ~80 bytes in size.

What you need to understand is that there needs to be a separation between the gameplay concept of a tile, and the visual tile that the user sees. These two concepts are not the same thing.

Take Terraria for example. The smallest Terraria world takes up 4200x1200 tiles, which is 5 million tiles. Now, how much memory does it take to represent that world?

Well, each tile has a foreground layer, a background layer (the background walls), a "wire layer" where wires go, and a "furniture layer" where furniture items go. How much memory does each tile take up? Again, we're just talking conceptually, not visually.

A foreground tile could easily be stored in an unsigned short. There aren't more than 65536 foreground tile types, so there's no point in using more memory than this. The background tiles could easily be in an unsigned byte, as there are fewer than 256 different types of background tiles. The wire layer is purely binary: either a tile has a wire in it or it does not. So that's one bit per tile. And the furniture layer could again be an unsigned byte, depending on how many possible different pieces of furniture there are.

Total memory size per tile: 2 bytes + 1 byte + 1 bit + 1 byte: 4 bytes + 1 bit. Thus, the total size for a small Terraria map is 20790000 bytes, or ~20MB. (note: these calculations are based on Terraria 1.1. The game has expanded a lot since then, but even modern Terraria could fit within 8 bytes per tile location, or ~40MB. Still quite tolerable).

You should never have this representation stored as arrays of C# classes. They should be arrays of integers or something similar. A C# struct would work as well.

Now, when it comes time to draw part of a map (note the emphasis), Terraria needs to convert these conceptual tiles into actual tiles. Each tile needs to actually pick a foreground image, background image, an optional furniture image, and have a wire image. This is where XNA comes in with its various sprite sheets and such.

What you need to do is to convert the visible part of your conceptual map into actual XNA sprite sheet tiles. You should not be trying to convert the entire thing at once. Each tile you store should just be an index saying that "I'm tile type X," where X is an integer. You use that integer index to fetch which sprite you use to display it. And you use XNA's sprite sheets to make this faster than just drawing individual quads.

Now the visible region of tiles needs to be broken up into various chunks, so that you're not constantly building sprite sheets whenever the camera moves. So you might have 64x64 chunks of the world as sprite sheets. Whichever 64x64 chunks of the world are visible from the player's current camera position are the chunks you draw. Any other chunks don't even have sprite sheets; if a chunk falls off the screen, you throw that sheet out (note: you don't really delete it; you keep it around and respecify it for a new chunk that may become visible later).

I'd like to have whole map processed at least on server app (and on client if possible).

Your server does not need to know or care about the visual representation of tiles. All it needs to care about is the conceptual representation. The user adds a tile here, so it changes that tile index.

Answer 2

Split the terrain into regions or chunks. Then only load the chunks that are visible to the players and unload the ones that are not. You can think of it like a conveyor belt, where you're loading chunks at one end and unloading them at the other as the player moves along. Always staying ahead of the player.

You can also use tricks like instancing. Where if all the tiles of one type just have one instance in memory and are drawn multiple times in all the locations where it's needed.

You can find more ideas like this here:

How'd they do it: Millions of tiles in Terraria

'Zoning' up areas on a large tile map, as well as dungeons

Answer 3

Byte56's answer is good, and I started writing this as a comment to that but it got too long and contains some tips that might be more helpful in an answer.

The approach is absolutely just as good for server as it is for a client. In fact it's probably more appropriate, given that the server will be asked to care about far more areas than a client will. The server has a different idea about what needs to be loaded than a client would (it cares about all the regions that all the connected clients care about), but it is equally capable of managing a working set of regions.

Even if you could fit such a gigantic map (and you most likely can't) in memory, you don't want to. There is absolutely zero point in having data loaded which you don't immediately have to use, it's inefficient and slow. Even if you could fit it in memory, you most likely wouldn't be able to process it all in any sensible length of time.

I suspect your objection to having certain regions be unloaded is because your world update is iterating over all the tiles and processing them? That's certainly valid, but it doesn't preclude having only certain parts loaded. Instead, when a region is loaded, apply any updates that were missed, to bring it up to date. That's far more efficient processing-wise as well (concentrating a big burst of effort on a small area of memory). If there are any processing effects which might cross region boundaries (e.g. a lava flow or a water flow which will carry over into another region), then bind those two regions together so that when one is loaded, so is the other. Ideally those situations would be minimised, otherwise you'll find yourself quickly back at the 'all regions must be loaded at all times' case.

Answer 4

An efficient way I've used in a XNA game was:

• use spritesheets, not an image for each tile/object, and just load what you will need on that map;
• split the map in smaller parts, say chunk maps of 500 x 200 tiles if your map is 4 times this size, or something you can haldle;
• load this chunk in memory and paint only the visible parts of the map (say, the visible tiles plus 1 tile for each direction the player is moving) in a offscreen buffer;
• clear the viewport and copy the pixels from the buffer over (this is called double buffer and smooths the moviment);
• when you char moves, track the bouds of the map and load the next chunk when it gets near it and append to the current one;
• once the player is entirelly in this new map, you can unload the last one.

You could also use a single big map in this way if it is not SO big and use the logic presented.

Off course the size of your textures have to be balanced and the resolution pays a great price in this. Try working at a lower resolution and, if you need, make a high res pack to load if a config setting is set to.

You will have to loop only the relevant parts of this map each time and render only what is needed. This way you will improve the performance a lot.

A server can process a huge map faster because it don't have to render (one of the slowest operations) the game, so the logic for it can be the use off a bigger chunks or even the entire map, but process only the logic around players, like in a 2 times the player viewport of area around the player.

An advice here is that I'm by no ways an expert in game dev and my game was made for my graduation's final project (which I had the best score), so I may be not so right in every point, but I've researched the web and sites like http://www.gamasutra.com and the XNA creators site creators.xna.com (at this time http://create.msdn.com) to gather knowledge and skills and it worked fine for me.

Answer 5

Either

• buy more memory
• represent your data structures more compactly
• don't hold all data in memory at once.

Answer 6

the question here is how to make the game stop crashing when there's still free memory for it to use. As for splitting map in chunks, it's a good approach, but not what I want in my case.

In reply to your update, you cannot allocate arrays over Int32.MaxValue in size. You have to split it into chunks. You could even encapsulate it in a wrapper class that exposes an array-like facade: