Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been attempting to make a game engine in C++ and have come across the dilemma of game state management. I have done a lot of research and found numerous ways of accomplishing from game engine with derived classes to using enums and I would like to know the most effective/efficient way of managing game states.

I would like to know how other people implement their game state management, i.e. what you like the most and why you like it. Also, any tutorials/code examples that are generally about game state would also be much appreciated.

share|improve this question
possible duplicate of Game State 'Stack'? – The Communist Duck May 24 '11 at 10:42
There is a lot of questions like this: "What is the best way to..." The sad answer to these is that there is no best way, especially not with the little information given. It all depends on the constraints of the system. How do you need to work with it? Does a non programmer have to script it? How often will you update? The list goes on. – void May 24 '11 at 11:45
@The Communist Duck: it's not a duplicate the question you refered to is a possible solution to this one. – Ali.S May 24 '11 at 13:37
I think void hit the nail on the head. It's a hard question to answer in a generic way. – CiscoIPPhone May 24 '11 at 15:13
Just do whatever makes the most sense for you. If you're comfortable with enums and a switch, go for it. If you prefer a pattern of derived classes or function pointers, go for that. Don't worry about efficiency until you have a need to. At this point in the game it's all about expressiveness and malleability, and that's a somewhat subjective field. – Tetrad May 24 '11 at 15:40
up vote 1 down vote accepted

In most of my games (that are all small in scope) I have used an enum and a switch (in some cases an if..else if...) and it has always been sufficiently fast. I've never had more than a few states, which helps.

enum GameStates
    Running = 1,
    Menu = 2,
    Credits = 3

// update loop

    case GameStates.Running:
    case GameStates.Menu:
    case GameStates.Credits:
    // add more states here

void UpdateRunning(GameTime gameTime)
    if(running == null) LoadRunning(); // 
    // perform the rest of your game logic

This gives you a few things worth mentioning:

  1. You can change state anywhere, as long as you have a pointer to your main class.
  2. You can load/unload as necessary to save memory (if your game is big it might be nice)
  3. You've kept your very simple and easy to follow. This is the single most important thing a programmer can do IMO.

(Please excuse my C#/XNA style this was copy/pasted and tweaked, shouldn't be to hard to adapt to C++)

share|improve this answer
if you define a class for each state, it'll help you organize your code and also let you to define OnEnter and OnExit events for every event, very useful for loading unloading unnecessory data. – Ali.S May 24 '11 at 19:10
Loading and unloading becomes a lot easier when you can just delete an instance of a class instead of having to manually free stuff. An OOP approach here would probably be cleaner and have the same (and more) benefits as your enum system here. – Tyyppi_77 1 hour ago

The most common approch to GameState algorithm is to have some game states and program can freely choose to run any one of them, this means there is a GameDirector which has a pointer to current running state, and in each update cycle it'll call 'currentState->run()`. in this approch GameDirector is a singleton and every one can access it, and also every one can change game state. also gameDirector is responsible for game's main loop.

class Director
private :
    RendererEngine* rEngine;
    SoundEngine* sEngine;
    PhysicsEngine* pEngine;
    GameState* gState;
    static Director* instance;
        rEngine = sEngine = pEngine = gState = NULL;
public :
    static Director* GetDirector()
        if (instance == NULL)
            instance = new Director;
        return instance;

    RenderEngine* getRenderEngine() {return rEngine;};
    SoundEngine* getSoundEngine() {return sEngine;};
    PhysicsEngine* getPhysicsEngine() {return pEngine;};

    void runGame(GameState* pState)
        return instace;
        rEngine = new RenderEngine;
        sEngine = new SoundEngine;
        pEngine = new PhysicsEngine;
        gState = pState;
        while (gState)

    void changeState(GameState* pState)
        gState -> onEnd();
        gState = pState;
        if (gState)
            gState -> onEnter();
share|improve this answer
No, there is absolutely no need for a Singleton here. – DeadMG May 24 '11 at 14:00
@DeadMG No, there is absolutely no need for a Singleton anywhere (with a few extreme corner case exceptions) <- Fixed it for ya :) – The Communist Duck May 24 '11 at 15:09
@The Communist Duck: That's not a fix, it's saying something completely different. I specifically only stated anything about this particular use. – DeadMG May 24 '11 at 15:10
Singletons are also hell if you want to do anything with threads. Or touch something by mistake when shutting down you game that will reinitialize all singletons again ;) It's just Bad Design (TM). – void May 24 '11 at 17:48
@The Communist Duck: when i'm talking aboat game resources it's realy somthing that should only be initialized once ,eg. you'll only get error for trying to initialize DirectX with same configurations, or same window. and on the other hand there is no restriction to use singletons, you can use multiton whenever you feel there is need for more than one instance to a class, the main point is all the resources should be shared with all other classes in game and singleton(multiton) is an acceptable pattern to share your resources across your application. – Ali.S May 24 '11 at 20:25

Something I found interesting when looking around was the Advanced Ogre Framework which has a state management implementation. It is designed for the Ogre3D rendering engine but that part can be replaced pretty easily.

share|improve this answer

Your Answer


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.