   Game states and nested game states
  When designing and implementing your state handling logic for GUIs and game screens, have you ever found the need to have states nested within states?In my case, I have a set of state objects with a common interface, along with a pointer to the current state in the main loop.  When a method is called on a state, it returns a state object pointer which is either itself or the next state.  This works fine for states like the title screen, cutscenes, and the game screen itself.But for implementing relatively complex GUIs, short of implementing an actual GUI framework, I've found the need to have some states carry a state pointer of their own.  These inner states represent the screen's different GUI states.  I'm making a strategy game, so I have a main map state with has nested states for operations like building units at factories and moving existing units around.One thing that's tripping me up is switching between states that are actually the same state with different conditions.  In my particular case, such a state is my unit control menu.When you select a unit on the map you get an interface that displays its stats, allows you to move the unit, or perform operations on it like repairs.  Additionally, some of my units are vehicles that can carry other units.  I want the same functionality available to vehicles on the map to be available to their passengers.  I want to be able to select a vehicle, select one of its passengers, and move the passenger around or make repairs on it as if the passenger was on the map.  This is how I intend to implement entering and exiting vehicles, among other things.The unit control menu is represented by a state with a pointer to the currently selected unit.  If I select a vehicle unit I'd get the menu with its pointer set to the vehicle. If the unit has passengers I want to select one of the passengers and get the same unit control menu, only this time the menu's pointer is directed at the passenger. If I exit the menu for the passenger, I want to be back to the menu for the vehicle.  Handling what unit the menu state points to would get complicated, and I'm left wondering if something more generalizable is possible.I've read about people using stacks in state management.  That might be useful in my case since I may first push a unit control state object for a unit on the map, then push another unit control state object for a passenger unit.  When I'm done with the passenger unit I'd pop the stack and have the menu for my vehicle unit back.  The drawback to the stack is that it suggests that I'd be constantly creating and throwing away state objects as I manipulate the stack.   
  A stack of states sounds sensible to me. It's clean and allows for things like popup messages, modal boxes, etc.If you're worried about creating and destroying states constantly you can always implement a stack that uses inplace new to allocate from a pool - but I doubt it would be an issue for you.Alternatively each unit or game object could store its own UI state object. This gets pushed onto the stack when that unit is selected. You're not creating any objects just modifying the stack index.   ;Quote:I've read about people using stacks in state management.  That might be useful in my case since I may first push a unit control state object for a unit on the map, then push another unit control state object for a passenger unit.  When I'm done with the passenger unit I'd pop the stack and have the menu for my vehicle unit back.  The drawback to the stack is that it suggests that I'd be constantly creating and throwing away state objects as I manipulate the stack.Are you sure that creating and throwing away state objects as needed would be a problem? What programming language are you using?A game state stack would be a logical (and fairly typical) solution to the problem you're describing, so I wouldn't shy away from it. If you're worried about object management for some reason, you could create all possible game states on startup and then just switch between them as needed. (This method actually has some other advantages as well, as a 'strict' stack can be somewhat limiting in terms of what state transitions are available.) There are other solutions to the 'creating and destroying objects' problem as well, but they're language-specific, for the most part.   ;  All right.  I guess I was being a bit paranoid over the stack idea.  I suppose pushing and popping new states wouldn't be that big of an issue.  Still, I'd like to be efficient in case I might ever take my algorithms to a different language and environment like mobile devices.Just a few things though.  When I have a stack of states I'd assume only the top state gets input.  What would be a good way to decide which states get rendered?  Some menus might occupy a single space on the screen, so only the active menu should get rendered.  On the other hand, states like dialog boxes would allow states below them to get rendered.  There's a similar question about when states can get updated.  Some menus may pause the screen, while others may not.  Would booleans on each state that gets checked each update or render be the best option?Finally, would it be good enough to have a state stack local to the main screen stacks that need them?  Or would be better to have a stack handling all states in the game, both main screen states and menu/gui states?  Here, managing whether only the top state or multiple states in the stack is more important since now it has states covering the entire screen.Since jyk was curious, I'm writing my game in Lua using the Löve 2D engine.   ;  The way I do it, only the top state gets explicitly rendered, and it makes the decision about which lower states to render, if any. I'm not sure how well that would work for a GUI, though. It might be better for your menus to just have sprites or something and render all of those separately.   ;  For what it's worth, here's how I do it:Each state gets an opportunity to update and render each game cycle. In the update and render functions, each state is 'told' which state currently has focus. Each state can then decide to update/render or not, as appropriate, depending on which state currently has focus. Furthermore, states can optionally dim by some specified amount under certain other states.As an example, the 'game' state renders fully under the 'level complete' menu, dims out under the 'in-game menu', and doesn't render at all under other menus that might be brought up. As for updating, the game state continues to update under the 'level complete' menu (so that NPC and background action will continue naturally when this menu comes up), but not under other menus (to effect a pause). State parameters and behaviors are all data-driven, so it's easy to tweak state behavior or create new states as needed.This system has worked well for me, but YMMV.   