This post is largely inspired by this thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=361171 I have yet to find a way of managing game states that I really liked. I always had a distaste of the stack method, because juggling back to previous states lower down in the stack is messy. For instance, if I have a menu A which leads to another menu B which leads to C and then to D, but I want a button in D that sends me straight back into A, the stack method does not seem particularly intuitive (obviously those aren't states in the truest sense, but the principle is similar). The method I prefer, and the one which I've been playing with, is more similar to a process manager. Code Complete has something like this. The Enginuity articles also have something similar, although they seem functionally a bit different. Basically, states can be a collection of processes. When you want to change states, you remove some processes and add others. Processes can remove themselves and spawn other processes. Processes can also have children, which only receive events when the parent process is active. Obviously, there is a base process manager which accomodates adding/removing processes. In fact, I have come to like thinking of a game more in terms of an operating system - with processes and resource management and extensibility and such. So I was wondering if there were any major flaws in my thinking or if there was some more you could suggest. Cheers, --Brian

How about a linked list? (sorry for short post really gtg, but it may still help)

Ok, i've never done this with a "menu" system, but something I liked for an adventure game is a "state vector".

for the most part it was a std::vector<string> that I store strings in to represent any information that the game needed to keep track of.
This worked like store("livingroom_light_on"), you would later check that for some trigger event and swap it with "livingroom_light_off". The main benifit of this vector of different strings being that there were no hardcoded states, and there were no limits to the states you could move to.

This could be expanded to a vector of functors that point to all the functions you want to call each update. (Menu1, button1, button2, main_gameloop)

The problems? There is no elegant way to add/remove lots of states (like a whole menu of items), but this could be reduced to having the menu object be the
only state functor that you add to the state vector. Again, there is some added management over a stack, since you still have to have your button
delete the current menu from the state, and add the other menu.

But, at the same time, you can add several menu's or windows into the state vector with each managing itself. You don't have to make up speciial states
for when you want to show an invintory and have the player window open behind it and still running.

I don't think is it the most elegant design, but I found it to be more flexable than a stack when i was making my adventure game.

--edit, re-read your post, and made note that what i said above sounds kinda like the proccess manager idea.
But I think that the process manager should be something seperate, since i think of a process manager controlling the threads that stream in data, take care of resource management, and your main thread. Where as a state manager is linked more to the flow of the game than the lower level managment of resources.

Quote:Original post by Nairb
I always had a distaste of the stack method, because juggling back to previous states lower down in the stack is messy. For instance, if I have a menu A which leads to another menu B which leads to C and then to D, but I want a button in D that sends me straight back into A, the stack method does not seem particularly intuitive (obviously those aren't states in the truest sense, but the principle is similar).

In my project I handle such a situation by allowing the top level states (those on the stack) to have child states of their own in a sorted list. Thus it is a hybrid between a stack and a list state scenario. In your situation I would let the menu A be the top level state on the stack and let menues B, C and D be children of A. This way any one of the child menues could send a TerminateChildren command to A. To qualify for being a child state a state would need to exist fully within the context of another state.

I'll use the term 'task' for this discussion, but note that it is the same as 'state' or 'process' above.

I don't like the stack-based approach very much. I prefer to have a manager which exposes the following interface:

registerTask
activateTask
deactivateTask
deregisterTask
tick

Tasks are registered by name. In C++, normally this means passing a name string with an instance of a Task object to link with it. In Java, I usually provide a second form taking a name string to use as a key and a string which is the fully qualified Java name of the class to instantiate ("mypackage.MyTask", for example) - dyanmic instantiation allows for easy configuration of tasks via external data files (this can be done in C++ by implementing and registering TaskFactory instances rather than Task instances). Using dynamic instantiation, you can implement a flexible configuration system that associates menu items/key strokes/events/whatever with different Tasks, thereby eliminating the need to hardcode any flow at all. Or, you could go with something much simpler that just registers all available Tasks at initialization and leaves it up to each task how to manage flow. The other methods of the TaskManager all accept a string which was the key used to register a Task.

Each task exposes the following interface:

init
activate
deactivate
deinit
tick

When a Task is registered, the TaskManager calls the Task's init method (instantiating it first if using a dynamic system). This is for one-time initialization (which can be anything you deem appropriate). The manager then stores the Task instance away in a hash map for later use.

When TaskManager.activateTask is called, the manager finds the task in the registry. It then calls the Task's activate method. This is where any intialization not handled by the init method should take place. The Task is then added to an active Task list.

Each frame, the game loop calls TaskManager.tick. The manager iterates the active task list and calls the tick method of each task it finds. There is an issue with sequencing here. You could implement it so that when tasks are activated, they are added to the back of the active list. This makes it so that tasks are always ticked in the order they are added. Another option is to assign priority numbers to each Task and use those to sort the active list. Another thing to keep in mind is that you might want some Tasks to temporarily halt processing of the active list, preventing other Tasks from being ticked. For this, I have the tick method return a boolean. A return of false tells the TaskManager to stop iterating the task list.

The rest of the system should be obvious. TaskManager.deactivateTask finds the Task in the registry and if it is active, removes it from the active list and calls its deactivate method. It does not remove it from the registry. TaskManager.deregisterTask removes a Task from the registry and calls its deinit method. In C++, if you are using factories for dynamic instantiation, the manager should also delete the instance. Otherwise, you should put the repsonsiblity on the caller and return the Task instance pointer.

I find this system to be more flexible than a purely stack-based approach. You can do some neat stuff with it. Assuming that you separate the actual game state (and by game state in this case I mean player stats, entity positions, etc...) from the Tasks, then you can get even more flexibility. One Task could be used to handle the management and display of the game world, while another task could be used to overlay the UI. You could split things up further, having one Task manage user input and player state, another to update game logic, another to render the game world, and a final one to display the UI. This basically breaks up the game loop into different Task objects, keeping things logically divided and pluggable. When a menu is displayed, an additional Task can be added to the list to show it. You can override the exisiting Tasks to display only the menu, or pause the game logic so that game world and existing UI are still displayed behind the menu but nothing is updating. Lots of different things you can do.

This system can be as simple or as complex as you want it. For a different perspective, take a look at Scott Patterson's article in Game Programming Gems 3: An Object-Composition Game Framework.