I first of all updated SubVersion and TortoiseSVN, the software I try to motivate myself to use for version control. It's good stuff (especially when I was using it for larger projects at work, back when I had a job), but I tend to be lazy, and for small projects, it takes a bit of effort. Once directory layouts, filenames, and so forth have stabilized, it's perfect, but I think I get tired of having to manage the versioning of all the stuff other than the contents of files. But if I don't use it at this stage of the project, I probably won't use it later either, so I'll deal with it. It probably isn't so bad anyway.
I started with my core game loop, which is actually quite simple, and leaves all the non-loop processing to state and component objects. The main loop maintains a state variable that is the active state. I call a Process() function on this state, and receive back a pointer to the next state (or null to end the loop and thus the program), as well as a list of components to process. I then process all these components in order (making sure I don't process a component twice), and do it all over again, with whatever state is now active.
I will describe my ideas on handling timing within components once I get to that section of code, but I will mention now that despite the simplicity of the loop, I do intend to be able to support fixed-frequency game logic, optional variable-frequency graphics, and the potential to Sleep() or do whatever else in order to not hog the CPU if not needed or not desired.
I decided to use the essence pattern that I just recently read about to handle the creation of states. I had a problem of state constructors requiring too many parameters. Since there is no central repository of components (graphics, physics, input, et cetera), the states themselves needed to keep track of such lists. When one state transitioned to another, it typically needed to past most, sometimes all, of these components on to the next state that it created, and it ended up looking rather messy. Something about that just seemed inappropriate.
In the previous prototype, I merely made a concrete base state class from which all other state inherited. It contained pointers for all the components and other objects that might need to be passed between transitioning states, and a copy constructor that handled this copying. When creating a new state, I simply passed in a reference to the current state, and the new state could then just pass that up to its parent's constructor, and all the objects that were available from the last state would be copied to this state. It cut down on code, and made things look a little cleaner.
However, the problem was that this base state meant that all states included this same set of components, even if they didn't use them at all. It was definitely a temporary hack, and needed to be fixed. I now intend to make all constructors private, provide a public essence class for each state that can be initialized with state-specific objects, and can then create its corresponding state, since it and the state are friends of each other. Additionally, I plan to support an interface on all essence classes that exposes an associative view of the data, mapping string names to objects. Any state constructed with an essence can save that essence object, and then when it creates a new class, can pass a reference of this first essence to the new state's essence. It can look up objects by name, saving a lot of hassle of manually specifying each item.
I suppose I could just build this into the state class itself, but I think the essence pattern will provide a separation of roles that is appropriate, or so I hope.
