Feels like a long time since I've done some serious thinking about code design or architecture. So as myself and Boris got to talking about game states and how best to handle them, I'll admit I was (and continue to be) intruged by applying more of my professional work towards a game end.
Since my entry into the world of web development, I've spent the majority of my time with stateless applications. But the design patterns really don't change all that much, if you abstract away enough.
We started with overall application states - startup, game, pause, menu, shutdown, and the like - and even talking those relatively few brought in quite a few different attack vectors. Of course, this has since progressed into game object states. While still states, it's a bit different managing each individual object (or rather, having something else manage it, as is my preferred mehod) versus the entire application state. What we've come up with, so far, is rudimentary, but well modularized...on paper, at least.
Still, I'm happy to see recognizable patterns, and make some new ones, especially in the design phase. And be able to identify them without staring at a bunch of code for hours on end.
