Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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!

share|improve this question
    
What is a "game-state"? –  Nicol Bolas May 11 '12 at 0:07
    
also called gamestate; it's a system that allows you to easily switch between sections of the game like menus, credits, and gameplay. –  Link May 11 '12 at 1:46
    
MikeC seems to think it's something different. He seems to think it's the difference between in-game states like playing, paused, etc. As opposed to higher-level things like main-menu, in-game, etc. So which is it? –  Nicol Bolas May 11 '12 at 1:56
    
this is the latter; higher level things such as main-menu, in-game and so on. –  Link May 11 '12 at 1:58
add comment

4 Answers 4

up vote 4 down vote accepted

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.

share|improve this answer
    
easy method, accepted thanks for help! –  Link May 11 '12 at 14:23
    
also, are the State and statemachine just simple base classes? –  Link May 11 '12 at 14:30
    
I'd implement the State as an Interface or Protocol, because it's implementation is probably different for every state and therefore a base-class isn't very useful. But since this doesn't exist in C++, it would probably be a pure virtual class, as explained in this stackoverflow question. The state-machine implementation won't change much, so implementing this as a base-class and then inherit from it seems fine. –  bummzack May 11 '12 at 14:42
    
thanks for the link, sounds good –  Link May 11 '12 at 18:41
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Beat me to it :) This makes the most sense when you're dealing with over-arching game states (playing, paused, etc.) –  Mike C May 11 '12 at 0:39
    
thanks, seems like a good idea, I'll look into it. But is there another way rather than switch and case statments. –  Link May 11 '12 at 0:54
    
In programming, there's always another way. For this kind of behavior, I find a switch() to be most readable. You can get the same effect with stacked if else blocks. You could use an actual FSM. And, I'm sure the list could go on. –  chaosTechnician May 11 '12 at 3:05
2  
-1. There's no excuse for singleton with public functions in a language where you have free functions, like C++. Just write free functions. –  user744 May 11 '12 at 8:55
    
@JoeWreschnig Are you saying that because I can write a globally accessible function in C++, I should never write a singleton class? I'd honestly like to hear your reasoning for that. –  chaosTechnician May 11 '12 at 15:45
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.