Roguelike column thumbnail ['@ Play' is a kinda-sorta bi-weekly column by John Harris which discusses the history, present and future of the Roguelike dungeon exploring genre.]

Here's a bit of hopefully-useful insight into a topic that every roguelike designer has to cover eventually: how to simulate variable rates of movement on the game's essentially integral, Cartesian grid.

One of the most distinctive aspects of a roguelike game is time-equivalency of actions. Moving a step, picking up an item, dropping an item, hitting an opponent, drinking a potion, reading a scroll, wielding a weapon, putting on or removing armor or a ring, and zapping with a wand: all of these things take the same amount of time, that is to say, one turn.

This is a subtly powerful concept. If the player swings at an adjacent monster, it uses up the player's turn so the enemy can get a hit in. If he's adjacent to an armor-degrader, taking off his armor to protect it still takes a turn in which the monster can get a swing in first. If he's wielding a weapon ill-suited to a foe, like a bow when fighting an adjacent monster, it'll take him a turn to change it, again giving the monster a free opportunity to hit.

And significantly, so long as a player and monster are the same speed and adjacent to each other, the monster is impossible to shake. The player must use some special item or ability to get away, because no matter what direction he steps, the monster will be able to match it. Since the player can't get away, once a same-speed monster gets adjacent melee combat will, barring special effects on either side, always be tit-for-tat, attack-trading affairs. The player can run in order to pass time, hopefully regenerating hit points, but that gives other monsters the chance to join in pursuit.

All the actions that change the player's state consume a turn. There are a few commands, particularly Inventory, that never take up a move. It should be noted that this is not realistic. A real person rummaging through his pack for a particular item will probably spend more time unslinging it, setting it down, opening the flap, and getting out the needed item, than it would take him to walk across one space's worth of dungeon floor. Giving him this action for free is a concession to playability. If there were a game penalty for looking to see what you're carrying, then it would be advantageous to keep notes on paper of your inventory instead of relying on the command, and a game that pedantic would probably scare away even the most devoted of @-signs.

But concerning those actions that consume time, there are two major types of speed systems for handling them in roguelike games: player-centered, and world-centered.

The world revolves around me

Player-centered is the simplest and oldest system. Rogue used it, the Mystery Dungeon games and Izuna use it, and some other popular roguelikes used it early in their history. Hack probably used it, but its descendent Nethack dropped it some versions back.

explayercenter.pngUnder this system, the player's moves are organizing moments of game time. All the monster turns are scheduled relative to the turns the player gets. Most roguelike monsters have "average speed," one turn per turn of a normal player, and such monsters behave identically under either system. The player acts, then all the monsters act, then repeat. It's when either the player or monster is faster this situation changes. Greater speed in roguelikes is handled by handing out more turns. If the player is faster (drank Rogue's potion of haste self, zapped the monster with a wand of slow monster, is wearing Super-Rogue's ring of speed, et cetera) then he gets two consecutive turns before the monsters can act. If a monster is faster, it gets two actions after each of the player's one.

Just because this system is simple doesn't mean it doesn't work well for many games. In particular Japanese roguelikes, which tend to latch onto roguelike play systems more for being like a special kind of puzzle game rather than a simulation of dungeon exploration, benefit from making turn ordering predictable to the player. (This is part of the general tendency of JRPGs to abstract role-playing game rule systems away from being a simulation towards general gameishness.)

Being faster than an opponent, in a roguelike world, is a tremendous benefit. Your options are greatly expanded by being faster than a foe, more than nearly any other single advantage. You can either get twice as many attacks, or you can attack and use magic items, or you can successfully run away from melee-only monsters, or, by using your extra moves wisely, you can change your equipment without danger. Most significantly, so long as you have running room, you can always kill arbitrary melee foes by using your extra moves to hit and running on the others, allowing the player to both get in his damage while himself escaping any attacks.

fracspeeds.png(By the way, being slower than a monster, while painful, is not usually as bad for the player as a fast player is for the monster. This is because very few roguelike monsters seem to have the presence of mind to adopt hit-and-run tactics as players can. In fact, only one comes to mind: not only will Nethack's unicorns occasionally hit then step away, they'll even attempt to remain at least a knight's move away at the end of a turn so they can't be hit by missiles or wands.)

But player-centered timing is a fairly limited system. There are only three "speeds" under the basic scheme: half-speed, normal, and double-speed, and each level is much more than twice as good as the one below. If the programmer is cagey, he might make an effort to simulate fractional speeds. If the player is fast by half a turn, then he gets an extra move every other time, and if monsters are faster they get extra turns at the same rate. But due to the nature of roguelike world simulation, this is actually only slightly worse than if the player were faster by a full turn. All a 1/2-turn speed advantage player has to do is to run on the two regular turns, and attack on the one extra. It'll take longer, and he'll end up running further, but the monster still doesn't get any licks in.

Also, the case where both the player and monster have extra speed must be seen to. If not handled specially, the game could run into a case where the player gets two turns, then the monster gets two turns, over and over, which is nonsensical; in such a case, each side should get one turn.

To counter these problems, a programmer may choose to randomize the awarding of turns, either giving him or the monsters an extra half the time (which sometimes gives him strings of lucky, or unlucky, extras) or dividing the player's moves into pairs, and randomly deciding which will be followed by the extra. This works, but by this point most of the benefits, in terms of simplicity, of using a player-centered turn scheduling system are lost.

Wait... do you hear ticking?

A world-centered system is rather more complicated to implement, and it loses the abstract purity of integral turn scheduling schemes. Although it loses that simplicity, it's a method of scheduling turns that's much more amenable to fractional speeds. The idea is that both the player and monsters get scheduled turns according to a world clock. There's an internal game timer that counts what we might call time atoms, instants of time that pass for every actor in memory simultaneously.

exworldcenter.pngOne way to implement such a system, similar to Nethack's current scheme, goes as follows. Each monster, and the player too, keeps track of its place in the global queue. The creature's readiness-to-act is measured in energy. After acting, the creature's energy is set to zero. As each atom of time passes, the creature's speed rating is added to its energy, and when it exceeds some value the creature gets a turn. Or alternatively, 1 could be added to energy when a time atom passes, and when the value exceeds (maximum speed - monster's speed) the turn occurs.

Under this system, the greater the energy threshold (or maximum speed), the more flexibility is available in timings. It's best to pick a number that's evenly divisible by many other numbers, like 24, 36, or 72, since the programmer will probably want most monsters to act in a manner similar to Rogue's integral system: a monster with a speed of 12, compared to a player with a speed of 24, will behave exactly as if it was a half-speed monster in Rogue. If the player were to obtain a slight speed increase, say a +1 to speed, then he'd get an extra turn only once every 12 moves, still an exploitable advantage, but one that's a bit trickier to take advantage of. And it even allows for different actions to consume different amounts of game time; a quick action could result in less energy being depleted.

I've used the words turn and move pretty much interchangeably here, but more-recent versions of Nethack make a precise distinction between these terms. There, move is when the player makes a decision, essentially a unit of volition, and a "turn" is an objective measure of game time equal to one old-style move. If the player is faster than normal, then there will be times when he gets two moves in the same tick of the game's turn counter, which can be observed by watching the turn counter.

Special cases
Two games in particular, one of each style, take advantage of the flexibility of their respective speed systems in interesting ways.

The Mystery Dungeon series, which either use player-centered timing or a system so close to it that it makes no difference, have extra, in-between levels of monster speed. One of them is two moves per turn, but only one attack. Mecharoid-family, Baby Tanks, Death Reapers and Guard Dogs and have this type of movement. Effectively, the monsters can move twice, but if it attacks on the first move it loses its second turn. The other system is single-move-multiple-action, and higher-level Sabergator monsters have it: a single move per turn, but if adjacent to the player they get multiple attacks (more for higher-level monsters).

Among games with world-centered speed there's ADOM, which uses a neat system whereby there's no real maximum to the player's speed, but the higher it gets the less frequent are the additional extra turns granted to the player. Greater speed increases player hunger at a linear rate, but additional turns increase at a declining rate as speed gets higher. Eventually a point is reached where further increases in speed are not worth the greater food consumption. While ADOM's source code is closed so we really have no idea how turn scheduling in that game is implemented, to work this kind of system in a game with player-centered timing would be quite annoying.

Breaking news! Temple of the Roguelike informs us that the maintainers of Dungeon Crawl Stone Soup, the closest the game has to an official maintenance body, has announced a tournament to take place during the month of August! We've covered Crawl before, and need I remind you, it is an awesome game that plays many ingenious riffs upon the roguelike theme. Go forth and play!