My plan is to split the code up into the following layers: Main, App, Systems, and Game State.
The main layer is pretty much just WinMain(). It handles the creation of the app layer and starts the main loop.
The app layer is responsible for the program's instance handle, the main loop, and the message pump. It also handles creation of the systems layer and manages changing the game state.
The systems layer is responsible for setting up and providing access to the various required systems such as audio output, networking, graphics, file I/O, etc. The systems are constants ie. new ones aren't created and old ones aren't removed in between game states. All game states will require a window, rendering, file I/O, and the rest, so these are all setup once and access to them is granted through the systems layer. This also makes changing game states and shutting down easier, since only a single thing needs to be shared or shutdown, rather than many things.
The game state is where all the interesting stuff happens. Resources are loaded, swords and monsters are drawn and animated, damage is dealt, the GUI is drawn and managed, etc. This will likely be broken up even further.
The systems and game state "layers" are actually more like components; one doesn't contain the other. I may decide to use that terminology instead in the future.
[size="1"]Reposted from http://invisiblegdev.blogspot.com/
