Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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?
First about the technical aspects:
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:
(Image source: http://www.codeproject.com/Articles/106884/Implementing-Auto-tiling-Functionality-in-a-Tile-M)
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.
Now about the gameplay aspects
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.
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.
