Game Programming
The programming of the game is a basic task that aims to ensure game stability, correct functionality,
provide the framework for other modules, message filtering and correct synchronisation.
Apart from these aims though, the core module should also achieve further goals that are not specific to the game
being programmed, the most important being re-usability. These are detailed in the features
section of this report.
The design of the game rules programming is closely related to the flow of the game itself. At the start a player has
to place his pieces on the board and then start the battle. The board space during the initialisation phase is 6x3 and during the
battle 10x10. The game is turn based and the observer can not interfere with the game.
All these are translated to two phases in the game (initialisation and battle phase) and the board is "placed" in arrays of
dimensions commensurate to the game board.
The diagram below is an overview of the game rules division and communication. For further analysis of the two phases of the game design
please follow the links below. For description of the core module interfaces and its role in the whole system please go to
the interfaces page.
Game Rules Programming
As we see the design of the game is divided in two parts with a thin link of communication between them. These parts are:
The initialisation phase
The battle phase
Initialisation refers to the start of the game and the piece placing process, while battle refers to the stage where the game
has started. It is essential that these two parts are linked and that there is an information channel from the
initialisation phase to the battle phase. This channel will have to certify that whenever a piece is placed on the board at
the start, the battle phase structures must be notified and updated so that when the game starts they known which piece is on which
square.
Please email me if you have any questions.