TheDastard

Hey guys, a long time reader, first time poster. Currently I plan on starting up a fairly large scale project with a few friends and we're looking for a bit of feedback on the gamestate system we plan on implementing. The game is being written in C++, SDL, and OpenGL.

So I've read through old posts like http://www.gamedev.n...-the-gamestate/, and we've developed a bit of a hybrid system between several systems mentioned there. The application would have both a StateManager and a TaskManager, as we plan on eventually multithreading the program. The StateManager would call handleEvent(), update(), and render() on the current active state, as well as be able to set the new active state when the current state dictates. States would be broken up into things like an introState, MenuState, GameState, etc (fairly common).

Now within each state things will be broken up intro several tasks. For example the menuState will have a 3D scene being rendered in the background as one task while the menus are another. The gameState will have the "game" being one task (or a series of tasks in itself), and any inventory, in game menu, etc will be separate tasks. I've seen people talk about making these separate states, and even talk about using a stack so you can layer them on top of one another, making overlapping renders easy, but conceptually an entire state for a 3D game and then a state just for each small menu seems wrong. The taskManager would manage the tasks within each state, maintaining a priority list. As I mentioned before this will allow us to eventually implement multithreading much easier as individual tasks can do their work separately, causing minimal conflicts (obviously there are still a few concurrency concerns but we all have decent experience with multithreaded programs, I'm sure we can handle it )

So my question is what do you think? Are we missing anything? Does this seem like a workable framework for a large scale game project? As an aside, I've seen many sources talk about using singletons for managers and/or states and tasks since you'll never have two gameStates running, or your inventory open twice, but singletons make us nervous. I personally have always been taught to use them when they are the ONLY alternative (like a logging system). Also, with our currently described framework, will the overlaying of tasks (menus overlapping with a rendered game scene) be difficult without a stack?