#9 Server-side movement of armies

[Ulf Lorenz]

Implement the server-side part of the movement. The following things should be roughly done in this task:

• a concept for simultaneous movement, which covers things like pursuit, blocking etc.
• a manager to move armies over the map (?)
• a server-side service that receives client move requests
• a server-side service that, when all clients have ended their turn, moves all units

Sending proper updates to the client is part of the client-side implementation, and needs not be considered here. Also, battles in case two opposing armies meet, can be done as a stub.

[Arno Kemner]

Sorting of movements:
Fast army move before slow army
A fast army has more movementpoints. A fast army doesn't have to use all movementpoints. So use movement points left to detect fast army

In case of same movementpoints left:
Easy tile, lower movementpoints needed, move before then difficult tiles (ie. grass before desert)

Calculation of the movementpoints left of an armyMovement:
first move has all movementpoints of that army minus the needed points of this move
second move has movementpoints of previous move minus the needed points of this move
etc..

[Ulf Lorenz]

Chat summary:

• MovementExecutor has some problems with algorithm and testing; postpone to separate ticket
• MovementChecker has some problems (what to do when you encounter an error?); postpone to separate ticket

3 Things left to do:

1. Return some useful data to tell the client what happened during the movement phase
2. Assemble the checker, sorter and executor into a phase object
3. Integrate into the existing infrastructure (factory for the phase, return the values etc.)

For now, we tackle mainly item 1:

• Update the MovementChecker: If an ArmyMovement fails the check, remove all ArmyMovements for the offending army (not optimal choice, but good enough for now).
• Add a MovementPhaseResult
  • derives from PhaseResult
  • Constructor takes a List<movementitem>, stores it</movementitem>
  • add a getter for the List<movementitem></movementitem>
• MovementExecutor should return a list of actually done movements (in order).
  • 2 new tests: return correct list for non-conflicting movements and for blocking conflicts.

[Ulf Lorenz]

Chat summary:

Discussed how to put everything together in a MovementPhase:

• add a server.phases.Phase interface with a process() function that returns a PhaseResult
• add a MovementPhase class that implements this interface
  • the constructor gets a ServerGame object, and a MovementChecker, -sorter and -executor
  • The process() implementation takes the list of movements from the ServerGame, and sends it in this order through the checker, sorter and executor. The output of the executor is wrapped in a MovementPhaseResult object and returned.
  • When there is an exception, process() logs it. Should not happen, though, as the checker already catches problems.

[Ulf Lorenz]

Chat summary:

Discussed final integration of the movement phase:

• in PhaseManager, add a constructor that takes and stores a list of Phase objects
• PhaseManager.executeTurn() goes through this list, executes each phase, and appends the PhaseResult object to a list of PhaseResults that is returned.
• GameRoomBuilder sets up a PhaseManager with a MovementPhase and adds a TurnExecutionService to the game room
• In the Builders, add all turn execution-related classes (commands, updates, PhaseResults, ...) that have to be serialized.