I've worked with tile-based engines before (a few years ago when I was pretty green). Now that I know a bit more, I want to revisit tile-based engines but I want to approach it correctly. I want to know two things: what is the best way to store the tiles, and what is the best way to store the levels?

For the first question: The tiles should be stored in sets, like a 10x10 grid of 40x40 tiles stored in a 400x400 image. Right? So when it's displayed, do you just place the entire image on the screen and only show the part of the image you want? And in that case, wouldn't it create a significant amount of overhead for a bunch of unused image? Or do multiple copies of the same image use the same cache?

For the second question: Should the levels be stored as two dimensional arrays? Serialized in a database? Or what?

  • \$\begingroup\$ Might be worth to take a search around the site, tons of questions like this already been asked / answered. \$\endgroup\$ Commented Feb 8, 2013 at 23:33
  • \$\begingroup\$ Sounds a lot like design paralysis to me. Just pick something that seems like it'll work for your project then come back when you have a specific problem you need solved. \$\endgroup\$
    – Tetrad
    Commented Feb 9, 2013 at 0:01

1 Answer 1


It's really not a huge deal - as long as you do it one way and keep it consistent. There's a lot of ways you COULD do this; but I guess the simplest way is to just keep a few basic data structures and serialize it down. This will be fastest way to get your game going, and if you keep it flexible, you can always add more information and refactor as you go.


Create a map class or structure and store some specific details like name, description and the like. Keep a list (depends on your language) of all map layers available to that map. Those layers then can contain a two dimensional array of 'MapTile's. The map tile can store data about a specific map tile. This is a simple and yet very flexible approach.

There's nothing really fancy about it - if you come to an important issue that is more specific, be sure to ask!

  • \$\begingroup\$ Thanks, that sounds like a good approach! Just wanted to make sure I wasn't starting in the wrong direction. Nothing like spending a few hours designing a system only to decide you want to scrap it later. I appreciate the advice! \$\endgroup\$ Commented Feb 9, 2013 at 1:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .