Display Model

The first thing I decided to code for Mirage was my display model. This is what I call how I store my tile objects internally, and how I use that model to display the tiles to the screen. I figured this would be important to decide early on, as it creates the base on which the entire game will grow.

I initially stored tiles in a two-dimensional array. This made the most sense from an initial standpoint since most if not all roguelikes appear to the user as a two-dimensional grid. Things worked fine and I soon had the hero moving around a screen of empty tiles. I realized early on that a two-dimensional grid would create a lot of problems. When the hero (or any actor for that matter) moved from one position to the other I had to change the old position's graphic back to what it was previously. The new position would have the same problem once I moved off of it. In and of itself this is a simple problem, and one that could be solved in numerous ways. I knew going on that this would create some headaches for me down the road, so I decided to take a little extra time and think about the problem.

After much internal struggle I decided that instead of a two-dimensional grid, I could move to a three-dimensional grid. I'm not sure of most other roguelike's display models, but having typed that it may seem like throwing an extra dimension at the problem was asking for even more headache.

I'll explain why I have chosen this solution. Imagine a cube of tiles. Imagine also that the terrain tiles are on the bottom layer of this cube. Somewhere on the second layer the hero is stored. If the three-dimensional grid is traversed by column, and from the top down, then the problem above disappears. Once a tile is encountered and drawn during traversal then we just go to the next column, instead of drawing any tiles underneath it. Of course I could also add some logic to each tile so that you could ask it whether we should draw tiles beneath it, instead of just assuming.

I have an enumerator that represents my layers. I can easily add to this enumerator to add more layers to the system. Since I access layers using this enumerator, adding new layers has no effect to preexisting code, neither does changing the order of the layers within the enumerator. In essence this enumerator controls completely how objects are drawn within the game.

I have an environment layer that I hope to use to implement clouds. Clouds will be on the top layer (at a reduced alpha value), and will allow drawing of tiles beneath themselves. This will give tiles below the clouds a nice bluish tint. This is just one of many ideas that could be added to this system with little trouble and consequence to existing code.

I'm anxious to hear what others think about this solution to my problem. I would also like to know how others have implemented display models in their games, in the hopes that I can make mine more robust. I think it is a simple solution that provides great flexibility.