Game states

[N1ghtly]

I'd like to know if it's a good design to have your class Game contain a stack of gamestates(with each it's own data and update and render functions) and make the gameloop check wether the state should be changed or not. I think it could be an efficient way of preserving different stated...

[eXpl0it3r]

It's always a question of size.
When your game is really small, maybe you'll be able to put everything in one Draw and Update function and still have a nice overview between all those if-statements.
Okay I don't know how you handle diffrent states, but what you probably basicly do is use one method but react diffrent to the active 'state'. So why not exclude it?
Use for each state a own method, yes maybe you will this way have to init somethings more than with the other design, but making a abstract state-class of which other abstract classes can be deriven will help you minimize those repetion.
I recommend it for 'real' projects.  :wink:

I made myself some thoughts about preserving states, but didn't end up with some code just ideas, but maybe not the most efficient ones.

My idea was that there could be four data structurs:
- array/std::vector - containing loaded states
- queue - containing states to activate in the next update loop of the statemanager
- queue - containing states to deativate in the next update loop of the statemanager
- stack - containing the running states

So you should be able to deativate/activate any loaded state out of any state. (If you programm the statemanager right ^^)

Don't know if it will work or if it is any good. It would be my first own statemanagement system so I'm also new to this...  :?

But there is already implemented stuff like the GQE -> http://code.google.com/p/gqe/
Browse through the code to see how he's done it!

eXpl0it3r

EDIT:
I've seen that there's another similar discussion running here.

[N1ghtly]

Thanks for the input!

I was thinking of having an array of pointers to game state.
I'd keep a variable to know which state to call, and when control needs to be passed over to another state, it can change the global integer currentState so that next time we loop, the next state would be called.
My only problem with this design was: what if i need to draw my game area in the background of the menu?

[eXpl0it3r]

Then you'll have to think about two diffrent menus.
One that is the main menu, which gets shown in the beginning where no game is loaded and one that is build into the gamestate...
Maybe you could also let your statemanager draw two states at once and set a transparenty. Or you can give your states diffrent sizes.
Anyway it will complicate the thing and use performance, which on low-hardward pc isn't always that nice.  :wink:

[MorleyDev]

Personally I tend and view things as tasks in a stack.

Each state is a collection of tasks, and as you push a state on top of the stack the tasks of the stack below it can decide either to suspend or continue. When a state is popped, all it's tasks are killed. You can obviously code in more fancy things too.

Tasks can be groubed by two additional properties: Process and Priority

- Process only matters if the program is multithreaded: Two tasks of process n are guaranteed to be running on the same thread whilst tasks of different processes may or may not, there are no guarantees.

- Likewise, tasks with the same process are guaranteed to be updated in order of priority (high -> low) whilst tasks on different processes aren't.

Some day I'll devise a more complex task system based around chaining tasks to execute concurrently (so you can say "Tasks X, Y and Z depend on Task A" and tasks X,Y and Z execute concurrently after A without interrupting the flow of any 'unlinked' tasks). Basically creating and scheduling "task trees"...Task tree! That sounds like a good way to implement it now that I think of it xD