Passing information between states created at different times

Question

I have two states, a configuration state and a gameplay (simulation) state.

After configuring the game details (gametype, scoring type, win condition, etc. etc.) As each state is isolated, what is a good way to pass this data to my simulation state which will be created later?

Currently I'm storing configuration details in static variables of the gameplay class. Then upon creation--the gameplay class is copying that into it's internal configuration. This seems sloppy. Could I be doing something better?

Answer 1

define a GameParameter class and send it from config to game class.

myNameSpace.GameParameter= function(score, level, gun, ...) {
    this.score=score;
    this.level=level;
    ...
 }

then you must implement in all your state class getGameParameter() and setGameParameter(params) OR have a startRunLoop(params) depending on how you manage the state change.

(tell me if i'm not clear).

Answer 2

Personally, I've got a game object which holds data I want to be persistent between states, like configuration variables (e.g. gravity, difficulty, e.t.c...), player data, camera data and a world object (which in turn holds terrain, characters and other stuff).

I pass this game object to the current game state object and query it for the data I need from within the state object, e.g.

foostate::on_update(game* g){
    //I'm totally interested in knowing the current gravity...
    print(g.gravity);
}

In my main method, I have a variable that holds the game object and in my game loop, I call the update function of the current state, passing the game object as a parameter.

This way, I can e.g. set my game to a pause state, but still draw the current view.

In addition to this, being able to save/load the current coniguration to/from a text file makes life easier, because you can just load the configuration instead of having to configure everything whenever you (re-)start the game.

Answer 3

If you're dealing with small games, this is somewhat inconsequential, as a finished game is better than a well-engineered game.

That said, if you're already finding yourself wishing that you could switch back and forth between screens, or set an option on one screen which propagates to another screen, afterwards, then I'd suggest looking into something like a "Mediator" / "Moderator" pattern.

The idea is that you have one system-wide object (or domain-wide object), which can be called by all members of that system/domain.

You can subscribe/listen/"on" + <event> to this object.
When that happens, you register a method or a function to use as a callback, to act on parameters passed in with the notification.

var system = Moderator(),

    player = Player(),
    scoreboard = Scoreboard();

system.listen("register-player", scoreboard.register);
system.listen("player-kill", scoreboard.add_point);

player.suicide(); // system.notify("player-kill",
                  //               /* dead-player */ player.id,
                  //               /* killed-by   */ player.id  );

Now, instead of finding ways of tying everything together, you're dealing with custom events, the names of which you name, followed by agreed-upon types and numbers of function parameters...

The disparate parts don't know anything about one another.
So when you make a multiplayer character, you might use a moderator as a way of registering to receive network updates.
If you kill that multiplayer character, it doesn't really need to update its network position any more, so you can unregister it from the moderator.

A player character who gets knocked-out or stunned for a short time might also be unregistered from receiving controller updates.
Once your components are this loosely coupled there are all kinds of things you can do.

You might also have, say, an achievement system and a goodie-unlock system which listen for your kills, and unlock after you reach X.
Now, instead of having to be hard-coded into the middle of your player class, they can just listen to the same moderator, to be notified of the same event.

You could also have multiple moderators...

For component-based stuff, this is usually the half-way between OOP and 100% entity-system.
For example, you might have every player have their own internal moderator.
That moderator might be the talking point between each of the components (like when a control tells the movement to jump, tells the skeleton to change animations, tells the IK-engine to blend the jump in with whatever you were doing, etc)...

...and then the player might be given access to a "global" moderator (or one which manages ALL players).

And that moderator would handle all communication from the player(as a whole) as it needed to be broadcast to the outside world.