Skeleton

Ogre3d will be the graphics wrapper used for the engine (at least for now).  It does what seems to be enough.  Also I will use most of the standard plugins for it such as CEGUI.  My next goal after a few tests of the limits of Ogre3d without any optimization (I wanted to see how much static geometry I could make, as well as the number of separate scene nodes with just a single entity while maintaining 60 fps) will be the basic game engine.

The first goal will be to build a modular skeleton such that I can replace components as needed for optimisation or infrastructure improvements (like my camera management will be a wasd ctrl plus capturing the esc key to exit).  I’ll resolve to not replace any components until necessary to either maintain performance or new features.

Skeleton:

• TerrainManager: from the perspective of the graphics engine to be built, this is a class to handle most of the static geometry and from the perspective of a game, it is everything that makes up the map
• InputManager: this will handle the mouse/keyboard input from the player (I won’t support joysticks for now), this class might need some children to handle the different menus that might exist (at the beginning maybe a splash screen and then the main game inputManagers), a question for later is whether I’ll keep track of selected units in here
• ResourceManager: I’d prefer to shift all the logic for loading scripts (meshes, materials etc) in one place and it’ll store all the messiness of knowing where to load everything (as it’ll like be partially hardcoded to a relative directory structure, it’ll just look plain ugly and I’ll put all the ugly in one hidden spot)
• GameEngine: this part might have to be split up later on but this will contain the main loop and have member variables to all the different managers, it’ll load up the game, maintain the game state (keeping track of whether the player is in a menu, in the game, in some submenu, in an in-game menu etc) but I’m not sure if I want the main loop somewhere else and have a separate stateManager but we’ll see how the code goes

I’m the kind of coder that prefers prototyping over pre-design because I’m mainly uncomfortable with scoping/design without intimate knowledge of the capabilities of what I’m building.