Game state sharing data

Question

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 1

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.

Answer 2

My suggestion is to not have game states like this whatsoever. Most of your essential game objects exist across and outside of all the states (eg. renderer, resource loading, input, networking, audio), and a massive amount of the rest span multiple states (eg. players, some NPCs, certain resources).

On top of that, the stack system doesn't seem to work well in practice. What if I want to bring up an options menu from within the mini-game - how is that going to differ from bringing it up from the main menu? What if I can quit the whole game from within the mini-game?

I'd ask, what value does this big state system give you? If you need to know what location you're in, store a location object or variable. If you're on the main menu, your GUI object will have a menu panel up; otherwise, it won't. Maybe there's an argument for pushing a new state when you enter a mini-game or cut-scene but I don't think I'd even do it then.

So my answer to "how do you share data between same States" is to not have game states at all.

Answer 3

I started learning programming from web development. My first steps were opening notepad, writing some HTML, saving it, and opening it in a browser. Then I wrote another HTML file and saved it. And then I made a link. Suddenly I had two pages which I could go back and forth between.

Then I got into PHP; I could handle user input! I could even save data about an user. I used cookies or the session to save data about the user between pages.

Now just a few months ago, as I was thinking and wondering the same question as you, I realized game states are like PHP pages. They're very discrete, each one being a different view of your application (game, in this case), but they need some shared data. They need session data.

Well, in PHP, to store something in the session you just use $_SESSION['variablename']='value';. Then you can later retrieve that data, from any PHP page visited by the same user in the same session, by referring to $_SESSION['variablename'];. Essentially, it's a global array, and in PHP you can easily add values to an array so it's essentially equivalent to a Map.

So if you want to go this route, then add a "global" Map which acts as your "session" data. This will hold all of the data that needs to be shared between game states. Or simply make it a "global" object and add all the variables you need; this is entirely up to you, based on your needs. (obviously an object will get much better performance than a Map) - when I say "global", I mean make it available to all of your game states. You shouldn't make it available to any other objects which don't need it. This can be done, for example, by a variable inside the gamestate namespace, or a package-private Singleton in a language like Java.

Note this is only one way to do it. I really kind of like the way you want to attach the data to the parent Gameplay object; but in my state system I didn't really account for sub-states so I was just thinking of the PHP way.