Top-level component architecture

[Twisol]

I redesigned the application's top-level architecture (i.e. the early stages of input and rendering) to decouple the data (the screen list, the virtual controller) from the processes that manipulate them. This kind of separation is a core principle of the Data-Context-Interaction pattern.

There are also a couple of bugfixes included in this patch. For example, the LevelSelectScreen would previously push a new copy of the MainMenuScreen onto the scene, rather than reusing the old one. This could theoretically (if you went between the level selection and the main menu enough) cause an out-of-memory situation. In addition, the toolbox is now removed through ExitScreen, rather than affecting the scene directly.

[Jjp137]

It seems to work with both the keyboard+mouse and the controller. :)

[Twisol]

Just to clarify what my major changes here are (because I forgot to write that in the first place):

I conceptually pushed both the Scene and the VirtualController into the model, and created (or adapted) high-level components that update these models during the game loop. The various game screens use the events and data provided by these models to react to game events, which decouples the game from the lower-level details of the game loop.

This separation isn't complete, but it's there to a greater degree than previously. Some of the complexity has been pushed into the GameScreen class; most notably, the controller manages a set of input hooks that are triggered when the controller model is updated. Additionally, a "TopLevelModel" model has been created to encapsulate some of the top-level state required by the game. This should be minimized as much as possible, and it should be passed around as little as possible; its widespread use through the GameScreens should be considered a code smell.

Future work:

• Make controller updates atomic. As it stands, event notifications are interleaved with the controller state updates (i.e. set Confirm state, emit Confirm event, set Back state, emit Back event, etc.), whereas it would be more consistent (and error-proof) to change the controller state fully and then emit events.
• Streamline transitions between menus and gameplay. Whenever a gameplay screen wants to return to the menus, it has to set up the Background as well. If it wants to return to the Level Select screen, it also has to push the Main Menu so the Back button works. This could (and arguably should) be simplified, perhaps by using C# extension methods to create a context in the spirit of DCI.
• Reduce TopLevelModel usage. The GameScreen subsystem should be redesigned to avoid passing the whole TopLevelModel around. This may be slightly related to the above bullet.
• Implement new input spec. With the new input adapter architecture, this should be fairly easy to accomplish.