Mech Retriever Dev Blog
Continuing to work on the driver for the Battle Screen. Mech retriever actually has a fairly sophisticated architecture–one that has evolved over the course of the project.
The main organizational principle of the game is the concept of a Screen. This has profound implications.
Why? Because the game is structured such that it progresses through several phases. It was natural to organize the code according to those phases as well–hence we have the Buy Screen, Build Screen, Battle Screen, etc. Because those are all phases that must be completed discretely before moving on to the next step.
Each Screen has a number of element within that orchestrate the functionality and make everything work. There’s a Driver, a Layout, a Resources object, and a View. The View is evolving to itself have an Input object and a list of commands.
The screens are built by either the game, or, in the case of testing, by a test class. This allows the screens to be tested with special test views, and a TestLoader and TestRenderer. When not built by tests, a ScreenSequencerFactory builds a ScreenSequencer to have all the Screens, and the ScreenSequencer uses its own Renderer to actually render the screen (actually it renders the content of the Resources through the Views). The ScreenSequencer also uses a ScreenQueue which uses its own loader to build all the screens in the first place.
Whew! This architecture has a ton of benefits, the primary one being that it makes the code decoupled, and thereby easy to code and test. We’ll look at the testing aspect next time.