ArmyMovement

It should be stressed that we are well aware that the algorithm needs another one or probably two rounds of refinement. The current implementation has partially been chosen for ease of implementation; once the framework is there, it is rather easy to upgrade the actual algorithm.

Preliminaries

Just to nail down a few definitions: The core of the military is a unit. Multiple units on the same map tile (currently up to 9) are grouped together in an army. Each map tile can hold only one army.

The overarching idea here is that all players send in plans for the movement of their armies, and then all armies are moved simultaneously. This means in particular that armies can have movement conflicts, when multiple armies want to access the same tile, and loops (in the simplest case, A chases B, B chases C, and C chases A running around some mountains). Both issues are features, not bugs, of the simultaneous movement. In the following, we describe how to resolve them.

Basic algorithm

To cross a tile, a unit has to expend a certain number of movement points (MP). The current simplistic algorithm assigns to each unit 2 MP, where grass map tiles require 1 MP to cross, mountains are blocked altogether, and all other terrain requires 2 MP. While this will be certainly made more flexible, having such strongly reduced movement is intentional.

To move onto a tile, armies first need to "accumulate" the required MP. As an example, if unit A moves onto grass tiles 1, 2 while unit B moves onto a swamp tile 3, the movement order is A1,A2,B3 (or A1,B3,A2, see below), that is, B stands around until enough "movement time" has passed for its move.

In case of multiple units being eligible for movement, the server always prefers the unit whose movement orders were sent in first. This allows an individual player to arrange the movement orders (though this is currently poorly supported by the GUI), and gives a bonus to players with few assets, which can end their turns and hence send in their movements earlier. As a side note, this also solves loops, because there is a fixed order in which movements are processed.

With regards to the above example, the movement order is then A1,A2,B3 if the movement of A came first (e.g., A's player differs from B's and he finished the turn earlier), otherwise it is A1,B3,A2.

Movement conflicts

If multiple armies want to move onto the same map tile, this will generally produce conflicts or blocking situations. There are two situations here:

• if armies of the same or of allied players want to move onto the same tile, they will generally block each other.
• if armies of enemy players (currently all players are enemies) want to move onto the same tile, this results in a battle. Currently, battles are not implemented, and this results in the same blocking situation.

Always the army that moves onto the contested tile first (see the basic algorithm description above) occupies it and blocks it for all other armies. Armies that cannot move onto a blocked tile, just stand around and lose movement points.

As a specific example, let us assume that each army had three MP, and consider two armies. Army A (moved first) moves first onto grass tile 1 (1 MP), then swamp tile 2 (2 MP). Army B wants to move onto grass tiles 1,10, 20.
The movement order without blocking would be A1, B1, B10, A2, B20. However, after the first step, Army A blocks tile 1, and B cannot move there and loses its MP. Army A only leaves tile 1 when it spends it third MP. After that, the tile is free, and army B can move there and ends its turn on map tile 1.