GameStateMachine design
This page describes how the new GameStateMachine class works and interfaces with the other components.
Note: this new design is implemented as part of Milestone B on branch NewGameControls.
In milestone A (up to almost the end of milestone B), the SimulationControls class handled both the state machine and the buttons in the UI. Coupled with confusing links to other classes and spaghetti signal-slots, it was clear that this design had to improve.
Separation of Concern:
- MainWindow owns the main window, including the menu and some of the QActions
- ResizingGraphicsView displays the scene
- SimulationControls (TODO: change name) is part of the scene and contains the QActions and the buttons for play, pause, etc.
- ViewWorld is the actual scene and is the QT class interfacing with World, the top-level internal model class
- GameStateMachine contains the state machine with all states, receives all signals and makes decisions on what to do
The risk of GameStateMachine is to become the "God Class" anti-pattern.
GameStateMachine only decides on what to do with each signal. Upon state changes, other classes have to act.
The above image implies that GameStateMachine will have 11 states, of which two contain sub-states.
Only theRunningState and theStoppedState listen to SimulationControls events.