Crave For Games


The text below is one of the notes from the StoneDrop development log. If you want a list of only technical articles you can go to the Articles page.
Game architecture

First draft of application architecture is ready and presented on the figure 1. I've tried to make it in an UML diagram style, but for me it's more convenient to have a combination of class diagram and data flow diagram.

151215_scan.png

Figure 1. Game architecture draft

 

The purpose of the Menu scene is to form a valid Level object to pass it to a Game scene. This can be done either by Story (simply by deserializing selected Level), or by CustomGameComposer (setup all settings via UI for custom game and save them as a custom level). Before any deserialization of Levels is done a PlayerState should be loaded (later it will be used to evaluate which levels, islands or modes are unlocked by the player). A valid Level object contains a link to Rules (object that encapsulates all info about rules of the level, such as winning conditions, time restrictions, sequence of moves, modificators, etc.), PlayerSettings for all players (type, visual style), Reward (only for story levels), IslandInfo (name and visual style of island), InitialStones (stones and objects on the island at the beginning of the game, optional) and ReplayInfo (only if we want to watch replay instead of playing the game)

 

In the Game scene a singleton Referee will be created while loading. It will get the Level object and after this the set of IPlayer objects, GameRecord and FieldManager will be instantiated according to the Level content. The FieldManager is responsible for changing state of the field, providing information about available moves and existence of winning lines. Referee is handling the sequence of moves, score and provides information for the GameRecord which records all moves for a replay.

Along with the FieldManager creation the AIManager loads baked information for AI on the island and stores computed AI players' tree of possible moves.

When the level ends, the object of GameResuls will be created by the Referee. The GameResults object will apply all necessary changes to the PlayerState and to Statistics and save GameRecord to a corresponding level replay file before switching the scene back to the Menu.

Color depicts object-file relationship in serialization.

 

UPD may 2016: after I've read the "Singleton" chapter in the book "Game Programming Patterns" (highly reccomended!) I've came to the conclusion that the presented architecture suffers from singletons (some of them were eliminated during the development). If the project would have more than one programmer I would face this problem earlier, but in the StoneDrop I strictly follow the restrictions I've set from the beginning regarding the singletons, so they don't bother me much.

This article in social networks: