Automatic mode

Imagine a full battlefield of a hundred and more units arrayed on each side - commanding each and every of those individually gets cumbersome and error-prone quickly. However, this also wasn't historically how things were done - the general could not simply tell any unit what to do, especially when it was engaged in combat or behind hostile units. Instead, unit commanders were instructed before the battle what they should be trying to do and they had to make judgements based on what they could see around them instead of deciding upon the more complete picture of the situation a general might have.

Indeed, that was one important reason for the use of reserves - to provide the general with a body of men that was sure to be able to receive commands and hence react to unforseen developments when units already engaged in battle could not do that.

The simulation is set up to support this idea of pre-arranged battle orders. Internally this is done via events and conditional orders that are triggered by the events.

Initial orders

Just as they can be typed into the command line, initial movement orders can also be written into the definition section of a unit inside the config file. For instance, the following section contains the equivalent of the typed command unit G1 advance_to 260 150:

unit
name Greek_1
type Phalanx
tag G1
army 1
order advance_to
tgt_x 260.0
tgt_y 90.0
pos_x 260.0
pos_y 150.0
dir_x 0.0
dir_y -1.0

But of course usually the unit is supposed to do something when it reaches the location, and it might not even be able to reach the location because an enemy unit interferes - so how is that handled?

Internally both arriving at a commanded location and getting into contact with an enemy unit represent events - upon which a unit can react with a conditional order. For instance, upon_position defines an order that is executed when a commanded position is reached, upon_contact is executed when contact with another unit happens and upon_victory when an encounter with another unit is won.

So if we want to send the above unit to the position and then let it guard the area (i.e. attack any enemy units that come too close), we might do that as

order advance_to
upon_position guard
tgt_x 260.0
tgt_y 90.0

Movement, combat and observation orders

There's three different kinds of orders we might give to a unit. The first class consists of the movement orders (and we've covered that subject in the last tutorial). The second class of orders defines what to do when a contact occurs, i.e. once the unit gets into combat. Basically, there's a balance to strike between agressively assaulting the enemies' position (which causes high losses but might bring position gains) and acting defensively - up to the point of really avoiding a solid contact and fight and rather have the odd clash here and there to mainly delay the other unit's movement. Combat orders tell the unit how to behave once a fight has started. Finally, an order like guard or engage_upon instructs a unit to observe the surroundings and act in a certain way once a condition is met (here the condition is that another unit approaches sufficiently close).

It's important to understand the distinction and not mix orders. For instance, upon_contact can only ever contain a combat order. If a movement order is given here, the unit does not know what to do because once in contact it can not move freely. Likewise, observation orders act as modifiers to movement orders, they do not replace the movement order but exist simultaneously, so a unit may be commanded to advance and to engage upon closing 50 m to an enemy - but equally well it may be halted and yet retain the order to engage when an enemy approaches.

In other words, if a unit is in contact with the enemy, it needs a combat order. If it is not in contact, it needs a movement order, and it may (or may not) in addition get an observation order.

The default is that units advance, upon contact attack the enemy, upon victory seek out the nearest enemy and engage again and upon reaching a position stop there.

Statistical analysis

The beauty of the automated mode however lies not in the fact that less commands have to be typed, it is in running a simulation of many variations of the same battle. This accomplished by

run_iterations 100

to the config section. Whenever more than one iteration is requested, manual command input is off and the simulation runs the requested number of iterations, giving a breakdown of victories, defeats and draws in the end (to speed up processing, switching output like battle_verbose or automated battlefield display off is recommended.

We can use the automated mode to analyze the effect of a certain tactical move - first we run the simulation for 1000 iterations and note the result, then we change tactics and re-run, to see how the numbers have changed. This allows to optimize the tactics in an encounter (strictly speaking, the opening tactics as the battle degenerates into a chaotic melee quickly after the first victories have been scored).

We'll experiment some with that in the next section.

List of combat orders

attack - launch a straightforward attack on the enemy
assault - try to overrun the enemy position, accepting high losses
yield - fall back slowly while trying to minimize losses
hold_line - defend the current position at all cost, but do not advance
skirmish - try to avoid real contact but take attacks of opportunity

Continue with Analyzing tactics.

Back to main index     Back to science     Back to historical battle simulation

Created by Thorsten Renk 2022 - see the disclaimer, privacy statement and contact information.