Monthly Archives: February 2014


What is a tile in a roguelike, anyway? If you’ve followed the development of more than a few, you’ve seen how trivial decisions at the beginning shape the whole process. Brogue’s system of layers has stretched to everything Brian has thrown at it, but at the cost of a few weird interactions (shallow water from traps will destroy spider webs; they happen to be in the same layer) and the occasional bug (a whole class of crashing bugs pertains to trying to shove too many things into a cell). Simpler systems treat simpler games very well indeed. Cataclysm has a single terrain type per cell, but it has a few flags that govern smoke and fire, and water and blood are items.

In most roguelikes, each cell has terrain, maybe a few items, and maybe a mob (a movable object), like the player or a monster. Because the terrain is pieced together out of repetitive chunks, they’re traditionally called tiles; it’s helpful still to distinguish tiles from cells. Tiles go in cells. Cells are arranged in a grid. Mobs and items stand on tiles, in cells, on a grid. And if you’ll follow me in a strange convention, mobs and items can be tiles, too.

After all, as long as you can stack several pieces of terrain in one cell, you’ve got to handle more than one tile per cell. You’ve got to deal with rules about which terrain can stack and which keeps everything else out, which block FOV and how they transition from turn to turn. That’s most of the complexity necessary just to toss in items and mobs as tiles. Most, but not all. What’s missing is a model of independent behavior, of the agency exhibited by mobs and the potential for action implicit in items.

Let’s be puzzled, for a moment, by the fact that mobs exist in cells. It makes sense that the body of a goblin should be there, but it seems like its intelligence is something else entirely. Follow this suspicion a moment. I’ve often seen roguelikes handle this by attaching an AI object, a mind to the mob, which still exists in the cell, but this is unnecessary deference to realism. From the standpoint of code clarity, especially if coroutines are cheap, it makes much more sense for the mob’s intelligence to be the free thing that uses the body in the cell to find its way through the world. Notice the appealing symmetry with the experience of the human player, who manipulates the world by way of the @ that takes commands and tells what it can see.

In my 7DRL last year I settled on the name cog for this floating intelligence; there are more exact names, but none so short with so few implications. A cog is arbitrary code, free (up to a practical limit) to use any language faculty it needs, to make decisions and interact with the world — but the world it interacts with is governed exclusively by the tiles it injected into it when it was spawned. And those tiles exist in cells, and the cells exist in spaces (of which a grid is the most sensible example) and those spaces are responsible for telling the cog, through its tiles when it asks, what it can see, where it can move, whether it can attack, and so forth.

This is the upshot of the breadboard metaphor, and these spaces happen to be supersets of the topologies from PDS.

The lovely thing is that the cog can store references to its tiles; it can move its tiles around each turn; it can send messages through its tiles to neighboring tiles, which then dispatch those messages to the cogs they’re in, which can either handle them or else leave them to a default. Incredibly complicated spatial interactions can be handled like this, and the architecture underlying it really isn’t terribly difficult. Multitile enemies, lever and door puzzles, moving platforms, and more — all quite easy.

Spaces organize cells. Cells contain tiles. Cogs inject tiles into cells and then use those tiles to send messages to other cogs. The design of the message system can be complicated but it doesn’t need to be; more on that soon.