Roguelike turn-based time

After doing a little reading on how to handle turn-based time in roguelikes I want to summarize what I found here. There is a metric crap-ton of posts about this on RGRD, not to mention a couple of articles at Roguebasin, and probably several giga-reams of source code you could look at…it’s a bit overwhelming at first, so I’ll start with the simplest:

I go, you go

Now every way of doing it is going to be ‘I go, you go’ naturally, but this is how people describe the simplest way of ordering things. I guess you could call this ‘equal-priority order’ or maybe ‘first-in, first out’ time. There is a global, incrementing turn counter, and all entities are in a list which you iterate over. Each entity takes their turn in the order they’re on the list, and actions either take one turn, or no turns (for stuff like looking at stats, saving the game, and so forth).


Similar to the above, but using a speed for each entity. Set each entity’s timer to 100/(speed), then get the entity with the lowest timer. Decrement all timers by that amount, then run actions for any entity with a timer of 0. Afterward reset those zeroed timers to their original value.

Plus player time

This is a simple system where the player takes an action that costs some amount of time. Then that time is given to all the other entities in the game. They can use that time to take their actions, so for example if the player casts a spell with a long execution time, the monsters can get multiple moves in.

Phase order

I’m calling this phase order after a post made by Jeff Lait (creator of POWDER). I believe a similar system is used in Martin Read’s Martin’s Dungeon Bash. Jeff describes the system on RGRD, and again in a separate post.

The basic idea is of a repeating pattern of phases with a repeating tick running through the pattern, like a musical cross-rhythm. In Jeff’s game the phases are Fast, Normal, Slow, Quick, Normal. The tick occurs on the normal and slow phases. If an entity is marked for a phase it acts in that phase, unless it’s marked slow, in which case it only acts on the slow phase. The tick is the global heartbeat, where you execute all durational effects.

Angband Energy/Speed

Explained here in the Angband FAQ. Every entity has an energy level; each turn, their energy increases by the amount of their speed. When the energy reaches 100, they act, and the action decrements their energy by some amount. I’m not sure if all actions take the same amount of energy or not; ADOM uses a similar system, but the energy threshold is 1000, and different actions do take different amounts of energy.

In a modified version of this (explained here), you decrement the energy level by 1000, but keep the remainder.

You also can ‘count backward’ in another alternative, explained here as a ‘Time/Speed’ system using segments.

Priority Queue

This is a priority queue in the sense that you do the action of the entity at the front of the time queue, not the entity with a high ‘priority value’. I’m just pointing this out as there seems to be a couple of different interpretations of what a priority queue is. A simple method for this is explained well here.

Every entity has a speed, and each action has a cost (to follow the example in the link above, a cost in milliseconds). At ‘turn 0’, every entity’s time is set to 0. Then iterate through that list and select an action for each entity, which gives the time (action cost * (average speed))/(entity speed). Insert the entity in the priority queue, sorted by time, and once that’s all done you pop the entity off the list with the lowest time. The entity does its action, then chooses a new action, the time for that added to its previous time. You then reinsert it into the list and repeat the process.

A variation of this method uses a general priority queue, and in addition individual priority queues attached to entities. It’s described here by Ray Dillinger on RGRD. Each entity gets one entry in the general priority queue, but multiple entries in their individual queues.

If you look at some of the RGRD threads from 2004-2006 you can find some interesting debate between Jeff Lait and others over the relative gameplay value of time systems. If the player can’t accurately predict the order of the events because of the nature of the time system you use, is that a good or bad thing? It’s well worth reading those threads yourself to hear both sides of the debate.


5 comments so far

  1. Todd on

    Aarrrggg… now I am sucked in. Time is one of those things that you assume is easy in a turn-based game. Turns out… not so much.

    Although I don’t think I really follow the criticism surrounding the Troll healing in the vanilla “priority queue” system. Why not just have a dummy “regeneration” object that gets turns like everyone else and heals entities based on whatever formula. (“Dummy” as in: it’s not a real monster you interact with)

    Troll has a regen value of 5HP because it is awesome.
    The Bat has a regen value of 1HP (or 0.. since when do bats heal?)
    The player has something like 2HP.

    So every X seconds the “dummy regen” monster gets a turn and simply goes through all the monsters/players and bumps up their HP (Or decrements if they are poisoned, hungry, etc, etc).

    Keeping everything in a simpler framework seems worth it to me.

  2. georgek on

    Todd, I had the same thought when I read that thread. I think the PQ method received criticism because the poster who presented the PQ method didn’t go into much detail about it beyond his simple example.

    From a programming perspective the PQ method seems attractive for its relative simplicity but, along the lines of Jeff Lait’s comments (in that thread or a similar one, I can’t recall), I don’t know if it’s equally simple to understand from a player perspective. It might be one of those situations where you just have to try out both methods and get a feel for how they play.

  3. Time System | Bronze & Faith on

    […] off, I found a small listing of different methods here .Easy enough to get started? Nope. I sure want something to happen that is described as “Plus […]

  4. […] got kind of ugly and annoying. I decided to look into what other people had already done. I found this post, detailing a wide variety of time systems used in roguelikes, and decided to go with an […]

  5. […] got kind of ugly and annoying. I decided to look into what other people had already done. I found this post, detailing a wide variety of time systems used in roguelikes, and decided to go with an […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: