Handlers

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.

Definitions

Flow

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).



fig. 1 Command flow

Actually a command flow can be considered as a list of commands.

Producer

Commands are generated by producers : the first element in the chain of responsability is a producer.



fig. 2 Producer

Producers create command flows and send them to the next handler.

Consumer

The last handler in the chain is called a consumer.



fig. 3 Consumer

Handler

A handler is an object responsible for handling command flows.



fig. 4 Handler

A handler plays the role of both a consumer and a producer.

Components

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.

Executor

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.

Error

This consumer component raises an exception for each received command.

Sort

The purpose of this handler component is to sort commands according to a custom total order relation.

Buffer

The role of this handler component is to bufferize and multiplex commands and to release them as a single flow when triggered.

Switch

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.

Units

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.



fig. 5 Chain of responsability

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 :



fig. 6 Moderator units chain of responsability example

Each unit responsability would be :

  • Serialization Unit : deserializes commands from a given source
  • Security Unit : checks the received commands are orders of a type the user has the right to issue
  • Synchronization Unit : bufferizes received orders and releases them to trigger the turn computation
  • Computation Unit : processes the orders to compute the next game turn