This is basically just building off of what you wrote..


Windows Stuff
It's good to have a class that just creates and destroys the window for you.

DirectX
Graphics, input, and sounds really should be split up. They're all basically independent of each other, so there's no reason they should be together.

Graphics
Initialization and global state changes.

Input
Initialization. Getting input and knowing where to hand it off to.

Sound
Initialization of sound stuff. Also possibly manages music and sound effects.

Sound effects
Loads and plays sound effects.

Music
Loads and plays music.

Tileset
Loads tilesets, and manages drawing tiles (or at least handing out tiles for drawing). Probably will also hold collision data for the tiles.

Sprites
Loads and draws a single sprite.

Particle
Just one particle in a particle system

Particle System
Generates one set of particles

Particle Manager
Handles all the particle systems

Physics
Hmm this is hard to put anywhere. It'll probably be the physical object in the object hierarchy.

Objects
There'll probably be a whole hierarchy of these things.

Level
For the actual level information.

Game
For game logic stuff. Might also be used to hold everything else, like the level, tileset, managers, etc.

Program
Basically holds the game, and uses the windows stuff. It should be the only thing in WinMain, I think. (I haven't actually used a component like this in a game yet, but I think it's something that would work well.)

Globals
You don't want to use real global variables. I've found that it works much better to have a class that contains all the globals, and have only one instance of that clase be the only global variable. The way you can ensure everything is constructed and destructed in a safe order.

Time
Just holds and can be queried for the game time and real time.

AI
Might also end up with a hierarchy of AI classes.

Settings
I generally like the idea of not hard coding anything. Instead, stuff like object statistics or whatever should be stored in external files. I've called these 'settings' before, but that might not be the best name because it's more just any data. Basically it's just been a collection of numbers and strings.

HUD
Something to draw the heads up display stuff.

Menu Stuff
This can be a lot of stuff. Depends on how much you want to do with the menu system.

Resource Managers
All those sprites and sounds and stuff need to go somewhere. It's best to have objects just reference them from some sort of bin or manager. One of the imortant things the resource manager does is makes sure the game doesn't crash by giving something a NULL resource, or deleting a resource when it's still in use. Loading and deleting resources would go through these things.

Logger
It's very useful to have a global class that can be used to log debug information to. Basically it just writes to a file, or it could use a windows console.

Quadtree
Most likely we'll want this to optimize stuff like collision. Basically it's just splitting up the world so we only have to check a small set of objects rather than everything at a time.

Object Manager
All those objects/entities/unknowns have to be stored and updated somewhere. Best to keep them all in one place.

Networking
Networking stuff really needs to be considered early on because it's a lot harder to properly insert it into something that's already half made. Generally it seems to be good to always have stuff going through the networking module, and if the game is single player, it just loops back on itself. This is a pretty core component.

There's also stuff like the networking packets and the Winsock wrapper.

Player
Info on the player. Important for multiplayer.

Player Manager
Manages the multiple players. (Wow!)


Ok, that's all I have for now. Whoa, that's a lot of stuff. Didn't realize that when I was writing it. :P