Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What i still can't figure out is which would be the more sane way / easier and faster way to draw the map on the screen.. I mean i will use many tiles for my maps in my side scroller.. But problem is should i make the maps in whole images like one .png file for each map (Example) or should i draw the tiles by code like a for loop in c++.. Which way is most recomended or where can i read about which way is the best.

share|improve this question
Personally I suggest you use a well established library for this sort of thing. Personally I like Tiled's format and the libraries built around it. – ClassicThunder Nov 28 '11 at 23:58

I would never recommend having one large image. One large image will make changing and creating levels very tedious.

In my tile engine, I draw all the tiles to a separate screensized render target, and reuse that render target as the player moves around in the world, only drawing tiles as they enter the screen. This all happens in the background. I then use the render target as the background, and then draw the entities on top. This is what I believe one of the most efficient ways of drawing a tilebased world.

share|improve this answer
Just to be clear, you draw all tiles to a separate render target (many tiles, one target), not each one to their own (many tiles, many targets), right? – Richard Marskell - Drackir Nov 28 '11 at 20:02
@Drackir, Yeah, all tiles to one rendertarget. I'll reword the answer. – William Mariager Nov 28 '11 at 20:28

Tiles have the benefit of being stored in less memory, taking advantage of re-using the same graphics for all the areas in the map that need them. I will describe why it's not a good idea to use large images.

Drawing large images in place of tiles is inefficient also for the workflow. You'll have to recreate an new image from scratch every time a change in the map design is needed, and plus you'll have an arbitrarily large amount of images for any maps, they will barely be reusable.

Another caveat is managing collision detection- I mean, it's going to be more than a pretty backdrop in that you will want to interact with it. Handling collisions is much easier on a tile-based level since tiles can contain collision logic or vice versa, and their collision boxes are "locked in" with the tile area itself. With large static images, there will be a tendency to lose the spatial connection between the visuals and collidable areas, and you'll have to take extra care in not letting collision boxes become misaligned with the visuals. This will just lead to more unpredictable, buggy results.

Even in 2D games where the level design looks very "freeform" (see Aquaria) there is usually still a copy-paste philosophy behind it. The editors may not use tiles that snap to specific areas, but you're still using reusable bits and pieces for making maps and levels that can be scaled, moved and rotated which may take some interactive properties along, collision boxes being among them.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.