Managing, the management, that will lead to better management of design for the Hidden Management Layer of the State Management System

Little time for game development. I keep attempting to get time in every day, and I do, but it seems that on average the most I pull out is an hour. Most of that time is spent recapping where I am and adding a few design notes, and a little bit more implementation. There isn't really time constraints at this point. It's been rather a matter of motivation to get my two hours that I've been shooting for and an ability to find two consecutive hours to work on things. It seems that as I'm working the rest of the world is constantly sending other challenges my way, interrupting the time that I do have set a side and distracting me. This is of course alright, because those things, such as work and family, are more important. Family always will be, and hopefully the work will be the game development some time within the next five years.

As such, I'm still working on the state management system for the game engine. I started writing ideas for it over a year ago and started working on the actual implementation last month. I think I've over complicated things for myself in the design area, specifically with something I call the Hidden Management Layer for game state management. I started out designing the HML simply to be the interface between the user and the game states. All commands going through the HML, via direct console commands, or GUI commands, and the HML being responsible for handling any commands that it was capable of taking care of, otherwise passing the integer value for a command code to a specified game state so that it could handle the functionality. The HML also is responsible for keeping track of states that are active, that are in memory, and that currently have the app focus, while the states simply update themselves if they are active and process any tansitional code, release and initialize memory, ect.. when needed. This all seems fine to me so far.

The over complication comes into play once I started growing my definition for what a game state should be and once I started to ask my HML to handle tasks that should probably be handled else where.

For example, at some point I got the bright idea to incorporate my different engine management structures(engine objects, Scenes, and levels) into game states. At some angle this made sense to me. By doing this I would be able to control every object, scene, and level in the game as if it were simply a state. I would be able to pause individual states(Meaning that if for some reason I wanted to freeze individual object logic from updating, or temporarily remove an object from a scene, it would be very easy to do.), also all the different management structures would be able to interact with each other very easily.

As I'm writing this I'm having too many ideas run through my head as to how I should approach this. Currently I've just been designing a ADT and planning on deriving three classes for the different types of Engine management structures. This may work out ok.

I can't seem to focus to write this now, so I'm going to leave these ideas un-elaborated on for now. The phone won't quit ringing.