Wednesday, 14 October 2015

Terrain tiles as objects

When refactoring message routines I realized that terrain tiles are not game objects. It makes rather difficult to handle messages since it's clearly designed for object handles. I could have added special cases to message routine to get stuff like direct char pointer to terrain's name.

Changing terrain tiles from a simple int in map data to actual game object is difficult, sure. But it would not only solve this message thing, but many other problems related to terrain. For example when terrain tiles are objects they can have individual data for stuff like damage and so on.

This question of terrain tiles as objects has been kind of "debate" in roguelike development for a long time. They certainly spend more memory than simple tile maps, but in modern computers it's not a problem anymore. And it's about the only downside in them. My advice for developers who are thinking this question is that make them objects. You wont regret it later when more advanced terrain operations are needed.

What this means as a refactoring work is.. well.. I don't actually know the exact answer. The map system is already changed so that there is Tile object for each map tile, where the terrain tile is. Since the Tile is the owner of the terrain it becomes important not to override the existing terrain object, but that's quite easy to do. Most refactoring is spent in replacing the current system where "regular" game objects and the terrain is handled with different routines and style. When terrain becomes a game object it's possible to handle them using same routines as with other objects.

This change has been long overdue, because I knew the problem about the terrain much earlier, but was still reluctant to start the refactoring since it was working for the purpose at the time.


  1. For very basic beings like floor tiles and obstacles, I keep a single instance of my Being class that can be referenced by multiple coordinates. When some action causes changes on an individual tile (eg. causing damage to a rock wall with a pick axe), the game makes a copy of the Being instance before applying the effect. It has the benefit of saving memory whilst retaining flexibility, without requiring much extra code to handle corner cases, if planned properly.

    As always,

  2. I guess that's one way to handle it, but in my opinion using a copy of object is not good.