A turn is managed by exchanging commands in a given sequence pattern defined by the game design.
It includes synchronization mechanisms and security checks performed by the moderator.
A chain of responsability is introduced to manage commands : chain links receive commands, can perform a task based on them and can decide whether they should forward them or not.
The flexibility of this chain between the user interface (player side) and the turn computation (moderator side) emerges as the key to the technical design of the engine and provides the means to modelize the game mechanism.
A flow of commands stands for an event notifying that some commands are to be handled.
Any number of commands can be contained in a flow even zero (an empty flow).
Actually a command flow can be considered as a list of commands.
Commands are generated by producers : the first element in the chain of responsability is a producer.
Producers create command flows and send them to the next handler.
Generic basic components are introduced in order to provide tools to modelize the game mechanisms.
The components are either consumers or handlers and handler components are not supposed to make any command disappear.
The sole purpose of this consumer component is to execute the commands in a flow according to a given strategy.
A strategy is an object that encapsulates a treatment to be done on a command flow.
The purpose of this handler component is to sort commands according to a custom total order relation.
The role of this handler component is to bufferize and multiplex commands and to release them as a single flow when triggered.
This handler component registers (Consumer, Filter) pairs in order to demultiplex received flows to the proper consumers.
A filter is an object that queries the validity of a command.
A default handler receives the commands that did not match any filter.
Flows are sent in the same order as the registration order with the default handler at the end : a command can be sent within several flows.
The components are mixed together to build high-level modules called units.
The purpose of a unit is to handle some of the received commands and to forward the others to the next unit.
The game mechanisms are modeled by chaining units in the way defined by a specific game architecture design.
On the player side a command factory acts as a producer and generates orders which are caught, filtered and managed by units on the moderator side.
Symmetrically on the moderator side units generate both results and updates received by units on the player side.
A typical chain on the moderator side for a parallel game (like a Play-By-Email game) could be :
Each unit responsability would be :