architecture - Game state sharing data

A game is a set of Game States.

Each Game State contains game objects, may be list, may be scene graph or any other data structure.

We can use Game States as Game Locations, too.

How do you share data between Game States, for example, hero and his/her inventory when it moves from one location to another?

It looks like Composite (hierarchical) Game State is a good idea. For example,

GameState MainMenu
GameState LoadLevel
GameState Gameplay - contains inner states
    GameState Location1
    GameState Location2
    GameState Location3
    GameState MiniGame1 - contains inner states
        GameState LocationInMiniGame1
        GameState LocationInMiniGame2

So we can hold shared data (hero, inventory) in Gameplay object. But this approach does not look very correct and flexible. If some objects are outside scene graph (ie in the parent Game State), how would you include it in the scene graph? Via special node type that mounts different scene graphs or scene graph branches together?

If we have stack of active Game States, and each state can contain inner state machine, and scene graphs of different Game States can be mounted into one giant graph, it can become very complex system that is hard to debug.

Very interesting to read your suggestions. How do you organize game data between Game States in your real applications?

(For editors: possible additional tags: OOP, game-state.)

Answer

The concept of state stacks is very valuable and very useful in games. One particular game in my memory had the major states of "main menu", "playing a movie", "in game", and "in-game menu", with a centralized place that handled transitioning between these things. It was great because you could push a ton of crap at once and end up where you wanted to be without guessing. E.g. at startup "main menu" is pushed, then "movie" (gamelogo) then another "movie" (dev logo) then a third movie (pub logo).

Then the in-game had a ton of state, and that state was per-level. In this case it didn't make sense to make it a stack, since only one could be active at a time and the endlevel code would take care of transitioning to the next level (after pushing the load/save UI which in this case was part of the main menu).

Each level will likely have a ton of "areas" or sublevels or whatever. There is stuff that exists only in an area (e.g. the monsters), but there is the stuff that transcends the sublevels and is more appropriately "owned" by the level itself or even the in-game state "object". (The game I'm recalling had different player "costumes" in different levels, so it made sense to attach that to the level. Other games might just load a single player model and use it for the life of the in-game state.)

Some states do have sub-states though. These aren't polluting the "main" state stack, these are internal state stacks. E.g. the in-game menu will have a page stack like Ricket discusses so that "back" works uniformly. The memory card handling may be another separate stack too since it runs asynchronous to the rest of the UI.

In short, put data where it makes the most sense to you, and don't hesitate to move it if another home becomes preferable.