occasionally useful ruby, ubuntu, etc


Quasi-turn-based game design: movement

I'm fiddling around with building an online browser-based game right now, but am having some trouble trying to figure out how and when different units should move (since they can move at different speeds). The game is turn-based, i.e. actions happen in fixed time intervals, but it has real-time elements, since each unit is on its own clock -- actions that happen every 5 minutes for one unit don't necessarily coincide with actions for another unit that also has a 5-minute tick interval. In my mind, these are the requirements:

  • No unit should move multiple tiles in a single turn -- in a given turn/tick/whatever, they move at most one tile.
  • Some units can move faster than others -- namely, cavalry can move 3x as fast as infantry, for example.
  • Units that have varying movements speeds could have the same attack speed -- just because they move faster, doesn't mean they do everything else faster.
  • The speed of units can change dynamically -- if they are Haste'd by magic spell, or Slow'd by a bog, then...they do what you'd expect.

So far I've come up with three strategies for how one might implement these in a game.

Tick Rescheduling

In an interesting spin, the game is turn-based, but every unit is basically on its own clock. If you start building a unit at 4:21 PM, it might be ready at 4:36 PM, and then it might have 15-minute ticks from 4:36 PM on, while other units have ticks at 4:30 PM, 4:37 PM, etc. This is mostly a performance hack to get around the problem that a game like Utopia would have, where every player was ticked at the top of the hour (crushing the database, I'm sure).

So, if a unit normally ticks every 5 minutes and you cast Slow on it, it could reschedule itself so that it then ticks once every 10 minutes. This seems plausible. However, for other cases, like comparing speeds of units...say Cavalry can move once per tick, and ticks every 5 minutes. Now, Infantry can move once per tick, and ticks every 15 minutes. This seems okay, but once you think about things other than transportation it breaks down. With this design Cavalry would get to attack 3 times as often as the Infantry, which is not desirable (they should get an equal number of opportunities to attack).

Action Points

Another approach would be to use action points that individual units accumulate, all at the same rate with units having ticks at the same length. This way, we can imagine that every 1 minute, Cavalry and Infantry both gain one action point, and when the Cavalry has 5 action points (or when the Infantry has 15 action points) that unit can spend those points in order to move. Additionally, there would be a maximum number of points a unit could accumulate, to prevent moving more than once per turn, for instance Cavalry and Infantry could never have more than 5 or 15 points, respectively.

Only catch here: what about murky bogs or Slow spells? They could simply raise the required number of action points in order to move (to say, 10 action points for Cavalry instead of 5), but then, the required number of action points to move may exceed the maximum number of action points a unit may accumulate! So you could temporarily raise the maximum number of points that may be accumulated temporarily, but this gets messy (keeping track of old and new values, when to set it to lower/higher values, etc).


The final approach I've come up with is based on pure chance. Supposing Cavalry and Infantry have a tick every 1 minute, Cavalry would have a 20% chance of moving a tile per tick and Infantry would have a 6.67% chance. The good news is that this solves every problem mentioned so far. Units can have different chances for different actions (maybe Cavalry and Infantry each have a 50% chance of scoring an attack in a tick?). However, the game becomes nondeterministic. It is possible, however extremely unlikely, that one could build a unit that was never able to move for the duration of the game because of chance. The workaround, weighty though it is, would be to keep track of a unit's historical success rate, and ensure that 10-30% of moves that a Cavalry unit attempted resulted in a successful move over the course of its life, to prevent horribly unlucky or unfairly lucky units. How this would actually be implemented is still a mystery to me, though.

Despite the drawbacks listed for the Chance mode above, I actually like that it introduces a level of nondeterminism. If you have a Cavalry unit and Infantry unit racing for a tile (say a castle), you don't actually ever know who will arrive first, and this keeps players on their toes. To keep things fun though perhaps unlucky players should be given some sort of "pity party" achievement to help them along :)


Tick rescheduling has the problem that all actions happen slower or faster, so long as each unit has a single tick cycle associated with it, though Cavalry and Infantry should be able to perform some operations at the same speed and some at different speeds. Action points have the complexity of managing the maximum allotment of action points that a unit can have at a time. Chance is nondeterministic, and may require extra code and storage to ensure that it's not too nondeterministic, but otherwise satisfies all requirements.

Comments (1) Trackbacks (0)
  1. (just found this post… sorry, if it’s necro posting).

    You have to be careful using the same mechanics for a slow spell (a game effect) and a bog (a terrain effect).

    If you have any pathfinding, you will have to iterate over terrain’s move cost without considering the slow spell.

    Plus, I’d rather have the game content (the slow spell, the bog terrain, the heavy armor, etc.) separate from the timing / ticks / etc. You want to be able to tweak content and add content easily without breaking the core game.

    Just my 2 cents.

Leave a comment

No trackbacks yet.