   Game States Without a Stack
  This post is largely inspired by this thread:http://www.gamedev.net/community/forums/topic.asp?topic_id=361171I 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 theonly 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 buttondelete 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 statesfor 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.   ;  I'd go with a list... I'm currently using the stack method in a game I made for school homeworks and the best thing I've seen that it could be improved is to be able to have a state that is a list of states to implement "layers".If you're doing it in a (pure) stack only the top element is available. A list would give you access to other states and it will be possible to "sort" the states.  If you want to disable a state you could have a flag somewhere to do that. Having a state being a list of states allows interesting things like, for example, the game itself running in the back of a in-game menu.  Having the state manager as a state and a list allows the same as having a state being list but can provide more flexibility with the states.By changing to the list method (from the stack) you will need to see this more like different layers.  This is a good way to have a layers in the game, then a layer for the rendering for the UI, then maybe add a layer with a menu, all those could have acces to the game through a pointer.   ;  My question would have to be: why do you need to store the previous scene in a menu to begin with? Just use scene pointers, allowing them to switch freely based on options availiable.  Then you can do pretty much anything cleanly.;Quote:Original post by NairbI 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.   ;Quote:Original post by PaulCesarMy question would have to be: why do you need to store the previous scene in a menu to begin with? Just use scene pointers, allowing them to switch freely based on options availiable.  Then you can do pretty much anything cleanly.If you want the game to continue in the back when a menu is displayed it could be easily implemented that way. Every layer is independent so I wouldn't even have to care about a scene pointer that way. Bringing a state to the front would mean to bring that state on the top. Also, like in a process manager it would look like a tree because each states can have childrens and will manage them.The states would look like they are squeduled and they will run until they send back the control to the manager. If a state blocks (in any of the ways it could) it would block the whole game but anyway this would mean that something is wrong.Every state layers would act like if they were threads on the same CPU since we implemented a way to have each states to be run (kinda reminds me my first process scheduling experimentation when I tried to make a operating system long time ago). Maybe priorities could also help ordering which state should run first (children shouldn't have higher priorities than parents) so you don't have to reorder anything.   ;  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:registerTaskactivateTaskdeactivateTaskderegisterTasktickTasks 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:initactivatedeactivatedeinittickWhen 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.   