Most effective way to manage a gamestate system that is easy to use?

Question

I just started working on my game, mostly the game management. I plan and using game-states to make the menu's and other stuff easier.

My main idea for implementing the game-states is creating a game object and passing it as a reference to classes which control the current state, then storing the game-state classes via references inside a vector.
My main concern is that is this the better way to do it? Or should I implement it differently? Also, when you do use game states, where does the game loop go? Does it go inside a state such as gamePlaying or is it put somewhere else?

Hopefully someone can clear this up for me, thank you!

Answer 1

I usually implement a state-machine similar to this:

StateMachine
   + changeState(State)
   + getCurrentState()
   + update()

State
   + enter(StateMachine)
   + update(StateMachine)
   + exit()

When a state becomes the active state, the StateMachine calls the enter method. The StateMachine continiously calls update on the active state. When the state changes, exit will be called on the currently active state. The StateMachine passes itself as parameter to the enter and update methods, so that the State can initiate a state-change by itself.

Here's a pseudo-code example.

StateMachine:

// example for the StateMachine
Game implements StateMachine
{
    void changeState(State newState){
        if(currentState){
            currentState.exit();
        }

        currentState = newState;

        if(currentState){
            currentState.enter(this);
        }
    }

    State getCurrentState(){
        return currentState;
    }

    void update(){
        if(currentState){
            currentState.update(this);
        }
    }
}

Example State:

// example for a state implementation
IntroState implements State
{
    void enter(StateMachine sm){
        // start the intro
    }

    void update(StateMachine sm){
        if(introComplete){
            // change the state!
            sm.changeState(new GameState());
        } else {
            // play the intro
        }
    }

    void exit(){
        // nothing to do.. maybe free some stuff?
    }
}

Main:

// the main method that starts everything up..
main(){
    Game game = new Game();
    game.changeState(new IntroState());
    while(runGame){
        game.update();
    }
}

This architecture doesn't need switch or lengthy if statements. It's also really easy to change the flow of the states or add in new states. Imagine you wanted to start the MainMenuState after the IntroState? Change one line to: sm.changeState(new MainMenuState());. Then in the MenuState you could branch into whatever State you want, depending on which buttons have been pressed etc.

Answer 2

The most important thing you can do right now is actually just to make your own implementation without much regard to whether it's the "right" solution. Just write some code. You'll quickly find where the pain points are.

Having said that, one solution that works well for me is to have a Screen base class and a ScreenManager class. The ScreenManager class manages a list of Screen instances in a vector, calling Update and Draw on each one every game loop. One instance of the ScreenManager class is created at initialisation time in the main class (note I didn't say singleton. Generally you don't need singletons) and its Update and Draw methods are called from there at the right times. ScreenManager has methods AddScreen and RemoveScreen. Each inherited Screen class has access to the ScreenManager through a member of the base class (this value is set in ScreenManager.AddScreen) so each screen can remove itself and add new screens.

In this way, your game states are actually just screens, so you'll typically have a main menu screen, an options screen, and a game play screen etc, each with their own Update and Draw methods.

Answer 3

You could have a pure virtual class called game state. Then inherit from this class whenever you make a different game state, such as main menu or in game. You would have an enum that would be for your game states. You would also need one that was for not making a change. If you need to change the game state the current state will request the change. Then in your main game loop you would have a place to check if you need to change.

You can then utilize new and delete to facilitate the change in states. For instance, when you first start the game, you would have something like this pseudo code:

currentgamestate = NO_CHANGE;

gamestate = new IntroState;

while(shouldplay)
{
     gamestate->HandleEvents();
     gamestate->HandleLogic();
     gamestate->HandleRendering();

     if(currentgamestate != NO_CHANGE)
     {
           delete gamestate;
           switch(currentgamestate)
           {
                case INTRO: 
                { 
                      gamestate = new IntroState;
                      currentgamestate = NO_CHANGE;
                      break;
                }
                case MAIN_MENU:
                {
                      gamestate = new MainMenuState;
                      currentgamestate = NO_CHANGE;
                      break;
                }
           //and continue for each state and make this portion a separate function

This way you only have to deal with one switch statement for your states and your main game loop only deals with the one game state instance. You just have to insure that your constructors will create the bits they need to create and the deconstructors do their job right. Content loading and what not will happen automatically when you create the new state if you put it in the constructors. You can also have engine tools such as a renderer or a collision detection tool pass a reference or pointer of themselves into the different functions so you game states can utilize that code in their functions if they need to.

You could even have just gamestate-Run(); and run the three portions of events, logic, and rendering, inside the different gamestate classes. Up to you really.

Answer 4

I'd suggest making your main game class a singleton and using public functions to change the state.

I'd implement the game loop within the singleton game class and have a switch() statement with cases for your various game states that call functions for whatever actions you want to do within each state.