In the demo programs, there are the following files:
A file containing the WinMain function. This WinMain function is the same in all demos. This means, IMO, that it should be hidden in the framework, but that's just me.
A file containing the GameApp class, which represents the application as a whole. This class derives from SexyAppBase, and is the "true" entry point for the code as far as the developer is concerned.
A file containing the Board class, which derives from Widget. In more complex examples, other files containing other Widget derived classes also exist. A Widget is simply something that the player can interact with... anything from a playing field to a button to a checkbox. Often there is a TitleScreen class.
For more complex examples, a file that manages all of the resources for an application, typically called Res.h/cpp.
Here is what I have learned:
* Each of the Widget derived classes for your game should mirror the various application states.
* The state of the application should be managed from within the GameApp class.
* When transitioning from one state to another, first remove the current Widget from the widget manager, then add the new Widget to the widget manager.
* Any auxiliary widgets should be added and removed to the widget manager by the parent widgets AddedToManager and RemovedFromManager functions.
* Any auxiliary widget initialization should be done during AddedToManager function, by checking the appropriate variables for NULL.
* Use a resource manifest.
* Use static members of a class to store resources and other shared data.
* Separate resources by type: image, sound, font.
* Use enumerations to differentiate between various resources and application states.
* You may want to add a state stack to the GameApp class, as it makes certain state manipulations easier(like context sensitive help, for example).
