Been a while since I've actually put any code into my game, and it still going to have to wait some more. Right now, I'm working on handling states and what the states can do. 

I feel like my original design of state handling was alright, but it wasn't very friendly to change or refactoring. It definitely was not portable. The states themselves were handling too much. They were handling updates, drawing, input, etc... For a small scale game, this could be passable, but it's really not good enough and really not good practice. 

The idea that I had worked out with Adam was to separate things out into different pieces. There will be a state manager that will be in charge of handling states being created, activated, destroyed, and any other stuff to do with states. Then a game manager will use the information from the states and input from an input manager to determine and make any changes to the objects. After which, the objects will then be drawn to the screen.

Sound complicated? It is. The point is that each piece of this puzzle can be more simplified. The game manager shouldn't have to care about the states nor should a drawing manager have to worry about the updates made by the game manager. The thing that all of these pieces have in common is the objects within the active states. If the game manager gets the objects, it can tell the active objects to update based on how to update said object. After it has been updated (or maybe not updated) it is sent to the drawing manager to draw the pieces at the current coordinates. Once again, the only thing they care about is the object.

There are probably going to be more intermediaries as I go through this, but I feel like this is a good start. The part that comes in after that is refactoring the objects themselves to make sure the have all of the data that they need to be drawn. I may already have that in place, so drawing the objects may already be built into the objects. Probably just need to normalize on having an IUpdateable and an IDrawable. That will make the whole thing work.

Even though it's a pain to refactor work already done, it can really be worth it in the long run. You figure out new things, or make something easier to test, or it's just a better standard/best-practice. We should always strive to improve things, but at the same time, there is a time to stop and actually release a product. I don't yet really know when that point is, but I'm hoping that I will know when it is the right time.

-- Boris