I'm creating a highly flexible 2D tile-based map editor in XNA to make some of my future projects easier (will work for side-scrollers and top-down games). This editor can work with any sized tile.

This editor is based on a standard system. It has pre-determined layers such as Base, Fringe, and Collision. However, I've run into a bit of a problem. I don't know how many Fringe layers to use.

I'll be working with fairly detailed tilesets and will want enough Fringe layers to be able to render a wide variety of fairly complex scenes (e.g., forests with lots of trees overlapping).

I'm also considering having multiple Base layers to enable things like a player walking both over and under a bridge.

So my question is this: Is there a "right way" to approach this situation, and if so, what is it? Just lots of Fringe and Base layers? If you were a map editor, how would you expect/want this situation to be approached?

Also, while I have this question here, is storing layered maps in 3D arrays a good way to go about things? Meaning the first level is an array of layers, the second is an array of tile columns within the layer, and the third is the array of tile rows within the column.


2 Answers 2


There is a concept in software architecture called the "Zero, One, Infinity Rule". This basically states that you should support either zero of something, one of something, or any number of somethings. You should (almost) never write an application that supports (for example) 3 of something.

So in your case, if you are sure that a single "Fringe" layer will not be enough, the next solution - without considering any other requirements - is to support any number of fringe layers.

Of course, part of the problem is that you're committing a fairly major game development sin by creating technology for a game that doesn't exist. So any requirements are purely speculation. It is almost inevitable that you will over-develop some areas and under-develop others.

If I were in your shoes:

  • My first reaction would be to stop making an editor at all, unless I had a specific game to go with it.
  • Failing that, I would think about making base/collision/fringe layers all be "layers". At which point you have 3 of something - so according to the rule you should allow for any number of those things (and in any order). I believe this is what a few existing tile editors support. They let the game code handle the semantics of the layers.
  • And, failing that, I would support a single fringe layer, and not implement multiple layers until an actual need for them existed. YAGNI.

One other important thing to note - one place where YAGNI may be worth ignoring is with your file format. If you choose to have just one layer now - but think you might add more layers later - be sure that your data is stored in such a way that you can store multiple layers without breaking old files.

To answer your "bonus" question: Yes a 3D array is acceptable until some other requirement comes along to contradict that. Although if you go down this route, be sure you are storing a proper 3D array ([,,]) not arrays of arrays ([][][]).

Personally I would go with a list of 2D arrays (List<Tile[,]>).

  • \$\begingroup\$ You are absolutely right about the ZOI rule, was stupid of me to forget it. And I have several games that I'm making this map editor for (both top-down and side-scrolling). It's very simple (yet useful) and only for 2D tile-based games, but it's hopefully going to save me a lot of time. So don't worry, I have games to go with it ;) \$\endgroup\$
    – Djentleman
    Jul 22, 2012 at 7:42
  • \$\begingroup\$ Also, what's wrong with lists of lists? The flexibility is a plus for me (resizing maps is made easy, although could still be done with arrays of course) and it's what I'm using at the moment. \$\endgroup\$
    – Djentleman
    Jul 22, 2012 at 7:48
  • \$\begingroup\$ Good to hear that there is a game(s) behind this. You should let that be the primary guide of your design. I hope that you're implementing at least one game in parallel with your editor. And the same basic principle still applies: avoid early generalisation. About lists: There is indeed some benefit due to their built-in resizability (doesn't apply to arrays). And the fact you already have an implementation is important to consider. They are less-than-ideal memory-wise, but not too bad. I suggested List<Tile[,]> because it is a good semantic match: an ordered collection of 2D tile maps. \$\endgroup\$ Jul 22, 2012 at 11:08
  • \$\begingroup\$ Correction to my above comment: "They are less than ideal, memory wise, but not too bad" is supposed to refer to jagged arrays and jagged lists. Not to lists in general. \$\endgroup\$ Jul 22, 2012 at 11:18

Well what you should do is not worry about that and design it to be flexible. Perhaps even allow the users to choose how many they want. But in reality, don't even bother until you have made your game or at least some sort of design doc. That way you can know what you actually need and can design around that. Like many have said, don't design engines, design games.

On a side note, in terms of memory layout, you can either use single or double arrays for the individual layers, then have a list or an array holding that, making a double/triple array.


You must log in to answer this question.

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