# Gigantic 2d maps?

I've been thinking about a game idea for a week or two and the last few hours I was thinking of some technical stuff and came up with that the map would need to be 360,000x360,000 pixels in size. To me it sounds insane, but I've never done much in depth game development so I'm not sure if its reasonable or not to have a map that large.

Basicly my question is, would it work to have a map that large in a 2D game?

• Have you considered using tiles? Nov 25 '12 at 4:38
• You definitely need to split your map in to sections/segments/areas that are loaded on the fly the moment there is a proximity between the character and the area. Nov 25 '12 at 6:05
• A 360,000x360,000 image has the same number of pixels in it no matter how it's split up. Yes, you can save on RAM usage at runtime by splitting it and paging it in on demand, but that doesn't really solve the chief data storage problem; how big it is on disk and during distribution. Nov 25 '12 at 6:52
• @TrevorPowell Well he isn't entirely clear on whether he is talking about map dimensions or a solid image. Next to that I made a comment, I didn't give it up as a solution/answer. I had the idea he was talking about the map boundaries, not so much 1 to 1 pixel data. I can't deduce from his question that he is talking about an image of that size. Nov 25 '12 at 10:54
• Technically it's feasible, but does it make for good game play? What sort of game did you have in mind? Something that big will have to be filled with procedurally generated content. Nov 25 '12 at 23:57

The vast majority of 2d game engines are tile-based. That means that the game world is built from a pool of small sub-images of a fixed size. Here is an example. Note that many of the 32x32 tiles in this image are identical to others:

When your tilesize is 36x36, you could represent your game world with ((360,000 / 36) * (360,000 / 36)) 100 million tiles. The only data you need per tile is the id number of the tile image which is used for it. So when you have between 256 and 65536 different tiles, you will need two bytes per tile, so your world data is less than 200MB. When you have about 1000 different tiles, and each tile is 36 x 36 x 4 bytes, you have about 5 MB of graphic data.

Considering that modern PCs have gigabytes of RAM (assuming that's your target platform), you don't even have a reason yet to not load the whole map into RAM... yet. A good reason to do that will very likely come up in a later development stage.

Assuming that you have a 2d engine with a fixed zoom factor, it's usually not a good idea to have such large maps in a 2d game.

When you have a 3d game, the strong point of a large game world is the ability to present great vistas to the player. Send him to a peak of a mountain, and have him stare at the huge stretches of land beneath him. Then make him realize that everything he sees is playable content, and it blows his mind.

Being able to see into the distance is also a great navigation help. When you see a tower a mile away, you know you just have to keep moving in that direction, and eventually you will reach it.

But that doesn't work in a 2d engine. The player only sees a small window of the game world which is at most 1920x1080 pixels in size on a consumer-grade monitor. He can't make out any landmarks in the distance. That makes large 2d maps a lot harder to navigate. For that reason, large open spaces should be avoided in 2d maps. Every possible map location should have a well-defined set of paths the player can follow and must be recognizable and unique, otherwise it gets too easy for the player to get lost.

As a result from this, the map design in a 2d game must be pretty compact and made with a lot of care about detail. The larger the map, the harder it gets to keep up the quality.

• Supreme Commander had a huge 2D map and it worked fine--you could simply zoom in and out. (System performance was another matter, though...) Nov 25 '12 at 17:49
• I've never played Supreme Commander, but all the screenshots I find on Google Images look very 3d to me. Are you sure you mean that game? Nov 25 '12 at 17:57
• "at most 1920x1080 pixels in size" ... any 24" display made in the last 5+ years running at 1920x1200 begs to differ, not to mention the current generation 27" displays running at 2560x1440. Your point still stands though! Nov 25 '12 at 23:55
• Terraria is a 2D game with a REALLY REALLY huge map and it is pretty good, so huge 2D maps can be made. Doesn't mean it's easy, though (-8 Nov 26 '12 at 4:32
• @ccxvii: I added the phrase "on a consumer-grade monitor", because very few average users have screens larger than 1920x1080. Nov 26 '12 at 14:09

360,000 * 360,000 == 129,600,000,000 pixels in total.

Let's be generous, and assume that you're only using a 16-color palette, so each pixel can specify its color using only four bits.

129,600,000,000 pixels * 4 bits per pixel == 518,400,000,000 bits. Divide by 8 bits per byte gives us 64,800,000,000 bytes. Divide by 1024 bytes per kilobyte (or kibibyte, if you go in for that sort of naming), and then by 1024 kilobytes per megabyte (mebibyte), and you get approximately 61,798 megabytes. Let's round that off and call it an even 60 gigabytes (gibibytes).

Of course, if you want a 256-color palette (eight bits per pixel), then you'd need double that amount of space to store it. And if you want a modern "full-color" palette, then you need at least 24 bits per pixel, so that's about 360 gigabytes. Just for your map image.

Of course, if you have ways to compress your image (say, if you have large regions of a single color so you can run-length encode it, for example, or if you're happy to work with lossy compression), then you could bring that down a good deal. But if you're starting from 360 gigabytes of data, I doubt that this sort of compression is going to bring it down to a size which many people would be eager to download.

Most 2D games work by defining larger "tile" images, and placing those tiles together to form a map, rather than using a single large image.

It would work but much better is to create a data structure that holds coordinates of all needed tiles on your screen as a branches of binary or r\b tree, for example.
So you need a structure that holds the indexes of those tiles and their positions on the screen, when you'll call a render function of your game, you'll read data from that structure and form a raster image using tiles and that data. (So you will know where to place your tiles).
For a ready-made containers, that can hold map data, you can look at the different realizations of Map containers, like ones in the STL library for C++ or java.util.Collections if in Java, and other languages as well.