« In-Depth: Braben On Why 'We Are An Industry To Be Proud Of' | Main | Gamasutra Adds Alexander To Award-Winning Site »

Monday, August 4, 2008

COLUMN: @Play: Modeling Motion on a Dungeon Grid

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!

Comments

Whoo hoo! More @Play! Good column as always.

Hooray for @Play!!

Yhe one problem I have with DoomRL is the time-scheduling.. it's really weird. Like, each weapon has consumes time differently for both reloading and firing, your movement speed is fractionally affected by boots/armour, etc.. in practice this makes it impossible to predict what the enemies are going to do. Each reload is like russian roulette!

raigan: I can imagine why DoomRL would do it that way. Allowing players to easily predict what a monster will do allows for semi-abuses, like the hit-flee cycle that allows players to infallibly kill slow monsters.

A problem with doing it that way, however, with every item having its own speed benefit, is that the direct results of that benefit is rarely conveyed to the player in a way that makes it obvious exactly what the benefit is. If you tell the player the item makes them 12% faster, or gives them a +3 to speed, or something like that, and it still doesn't come home to them that the item is useful for this attribute, not the same way that +2 to damage would be.

thanks for another interesting @play article! I had never considered the player-centric vs. world-centric time systems. How is Crawl setup?

Good column, I took the liberty of adding it to the roguelike wiki, Here: http://roguebasin.roguelikedevelopment.org/index.php?title=Time_Systems

Crawl is probably world-centric. Usually one can tell depending on how regular enemy movement appears. If all monsters ALWAYS get one or two moves to the player's one, or one move for every two of the player's, then it's probably player-centered.

Just a warning, there'll probably be a few more development articles coming soon....

I have something to add (and correct) about ADOM. Turn scheduling in this game is complex (perhaps needlessly), but well explained in the manual.

Every action has a cost in energy points (usually 1000, but for example attacking with a weapon you're skilled with costs less). A player and monsters have speed (with average of 100). In every 'time segment', all actors gain the number of energy points equal to their speed, and once it's sufficient, they can move - so both higher speed and lower action cost means lesser delay after the action.

The mapping of Speed score to player actions is thus linear - double Speed means being able to move twice as often.

AFAIK several player-centered actions (regeneration, corruption and hunger) are turn-based (applied after each player action, regardless of speed) and thus increase at the same rate as Speed, so there is no downside to high speed (except that it's increasingly hard to obtain, once you're fast it's harder to become faster by in-game means).

What's interesting in this system is that in addition to overall speed, different player actions take different time, which you can change (by training combat, putting on seven league boots for faster movement, etc.)

More development articles? Great, looking forward to it!

I am also looking forward to more development articles. They will (obviously) be useful to developers, and I hear that there are 3 new Roguelikes per month.

You should definitely make an article about AI.

This seems to be my night for going over old article comments....

humpolec, that would make ADOM's setup world-centered. I've been playing around with a minor roguelike project of my own, privately, and the system I ended up using looks a lot like ADOMs. I wonder if I remembered it subconsciously....

AI is a trickier subject to handle, but I'll see what I can do.

Post a comment



If you enjoy reading GameSetWatch.com, you might also want to check out these CMP Game Group sites:

Gamasutra (the 'art and business of games'.)

Game Career Guide (for student game developers.)

Indie Games (for independent game players/developers.)

Finger Gaming (news, reviews, and analysis on iPhone and iPod Touch games.)

GamerBytes (for the latest console digital download news.)

Worlds In Motion (discussing the business of online worlds.)


GameSetWatch [Twitter / RSS feed] is an alt.video game weblog from the people who run:



Copyright © 2009 Think Services