Putting units or actions in the outer loop …

Many of the discussions regarding rules design in miniature wargaming involve the turn sequence, and how to structure it in order to achieve some desired effects. Over the years, there have been many different variants of the turn sequence, illustrating various schools of thoughts on how to organize the game. Often, discussions are framed as IGO-UGO vs unit-activation, but the spectrum is more varied than that. See also my earlier post on discussing various ways of looking at the turn sequence.

In this post, I will offer a slightly different way of looking at the turn sequence, and how it can affect rules design.

Action-based turn sequences

In an action-based turn sequence, the turn is defined as a (strict) sequence of actions, and within each action, every units can do exactly that action. This is best illustrated with the classic move-shoot-melee-morale sequence. First, we have the movement phase, in which all units get to move. Then we have the shooting phase, in which all units can shoot. The same goes for the melee phase and the morale phase.

In computer programming terminology, one can see such a turn sequence as 2 nested loops . An outer loop loops over all actions, and an inner loop, for each action, loops over all units doing that action:

  • for each action X (in fixed order move, shoot, melee, morale):
    • for each eligible unit Y (order usually chosen by player):
      • unit Y does action X

Such a turn sequence has a number of advantages – there is a fixed order for all actions, and this implies one can be sure that all movement has happened before shooting and melee, morale checks are performed after all combat etc. This can lead to a design in which those various phases of the turn are strongly coupled. However, it also often leads to rules in which all turn phases use separate mechanisms which have not much in common from a procedural point-of-view. The mechanisms for shooting and melee can be very different, and morale usually is a separate subsystem.

An important and crucial disadvantage is that actions which are not explicitly listed in the turn sequence cannot be added to the games engine in an elegant manner. Such actions are often defined in terms of an existing action. E.g. setting a building on fire might take half a move; or instead of fighting a unit might build (part of) a bridge. An alternative solution is to add such additional actions explicitly to the turn sequence. E.g. one can imagine having a separate “engineering phase”, or “spell casting phase”. The drawback is that such specialized actions become very visible in the outer loop, while relatively few units might be eligible to act on them. These actions might also be rarely used during the entire game, depending on the specific scenario. In a fantasy ruleset we used during the late 90s, there was a phase in the turn sequence called “Morph Friendly Cyclics”. It always gave rise to the same joke in each and every game. “Hold on guys, we forgot the Morph Friendly Cyclics phase! Friendly cyclics anywhere? No friendly cyclics? Are you sure? Ok, now we can move on …

Unit-based turn sequences

In computer programming, 2 nested loops can often be interchanged. We can also do this in the turn sequence. Instead of defining the turn as a loop over all actions, we define it as a loop over all units:

  • for each unit Y (order usually chosen by player, and/or driven by an activation mechanism):
    • for each eligible action X (chosen from a list of possible actions):
      • unit Y does action X

Such turn sequences are often called unit-based activation, since the units might be activated by die rolls, cards in hand etc. There might even be a terminating condition (e.g. a failed die roll), indicating the end of the turn. When a unit is activated, there usually is a choice of what actions, or a combination of actions (perhaps expending a budget of ‘action points’), can be executed with that unit.

The main disadvantage of such a sequence is that it is difficult to maintain coherency between units. E.g. if one would like to maintain a battle line, and one cannot be sure that all units can move forward during this turn (e.g. if there is a possibility not all units might get activated), this can really frustrate player or result in ahistorical behaviour of the troops on the gaming table. Often, a mechanism for activating a group of units is necessary as part of the activation procedure.

On the other hand, there is a big advantage when one wants to add additional types of actions. Since actions do not drive the turn sequence at the top-level, adding actions does not change the turn structure. Rather, actions are an add-on to an already existing structure, which makes it easier to maintain coherent procedures and game mechanisms.

This does not prevent from actions having their own disparate procedures, but it does create a structure in which a coherent mechanism for resolving actions is more viable. One of the best examples is the Basic Roleplaying System by Chaosium. It exists in many different variations (the Call of Cthulhu rulesystem probably is the best-known). Looping over the characters is the outer loop (as in most roleplaying games), and each action – whether it is searching in a library or swimming across a pond – is resolved by checking a D100 vs a target number. That results in a very elegant and tight design, and adding new types of actions is rather straightforward.

The same structure can be used in miniature wargaming. Whether you want to add engineering actions, special movement or shooting actions, or actions invented for a specific scenario only, they can be fitted much easier in the overall game structure as opposed to an action-based turn sequence.Wargaming Mechanics Blog