Introduction

The state pattern is very useful when you need an object to alter its behaviour when this object’s state changes. The purpose of this article is to give you an example of the State pattern in action. In that case, the State pattern has been applied to a small game framework.

During the last year, I have written some small DirectX games. One of the problems I’ve encountered was the transition between game states. For example, when the game starts, I was usually displaying an Introduction page on which you could see a menu showing my game options. Then, according to the user choice, I had to start the game, show the high scores or show something else. I’ve solved my problem by considering all those choices as states.

Below is a diagram showing my game logic built on the State pattern.

In the application class (CStatePattern_GameApp), we have a function called Run(), which provides a default message loop. Basically, this function updates the game and then processes all other messages. The Update function simply ask the view to render the current frame.

To avoid overhead, the DoFrame function will check if it needs to redraw something, according to the frame rate, or not. I won’t give too much detail on the frame rate stuff since this is not the purpose of my article. But if you are interested, all the code related to the frame rate stuff is located in the CStatePattern_GameView class.

Let’s get back to the State pattern. In the next section, I will explain what happens when the DoFrame function is called. There are two main parts in this function. The first thing that gets done is the game update. Usually, this is where you would update all game objects in the current state (ship position, collision detection, etc.):

m_GameManager.Update();

The second part is the game rendering:

m_GameManager.Draw(pDC /* device context */ );

The game manager holds a pointer to a CGameState object. Therefore, when we call the Update function of the CGameManager object, this will simply redirect the call to the current state object:

m_pGameState->Update(this);

This call represents a big part of the State pattern. As you can see, we are calling the Update function of the current state object, but we are also giving a pointer to ourselves as a parameter. The reason is that after performing state-specific work, the Update function of the current state object will be able to change the current state of the game.

An important thing to understand is that the CGameManager object doesn’t know a thing about the game. It is the CGameState subclasses that will define the game logic and each state transition as the game goes by.

The declaration above is really important. For example, let’s say that in our game, when the user hits the space bar, the ship fires. Basically, the CStatePattern_GameView will receive a key event. The view will simply redirect the event to the game manager. The game manager does not know anything about the game logic, so it redirects this event to the current state object. If PlayState is the current state, the KeyEvent function of that state will check which key was struck. In this case, it’s going to fire. If the current state would have been IntroductionState, this event could have had a totally different effect.

Transitions

State transitions are another important part of the pattern.

For example, the Update function of the CPlayState could check if the player has any ships left. If this is not the case, this function would call the ChangeState function of the CGameManager like so:

The states are not changed by the game manager, but by the state itself.

The declaration above might look strange, but when you think about it, it’s just logic. Let’s say that the player needs to press F1 to start a game while he is in the introduction page. The introduction page knows what to do when the user presses F1. In that case, it will tell the game manager to change the current state to PlayState.

Demo Project

In my demo project, I simply demonstrate some state transitions. When the game starts, we are in Introduction state. This state will wait for the user to press a key. According to the key pressed, the Introduction state will change the CGameManager’s state. F1 will switch to the CPlayState, and F2 will switch to the CHighScoreState.

In my demo project, I have made some TRACE calls to show you the details of each transition.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

Hi, I've looked at the state pattern. And I wanted to ask a few questions:

1. I understand the state can change to another from the state itself. And I saw in the demo there's a forward declaration of GameState in GameStateManager. Is this a good practice?

2. If in each state there's a substate, what should I do? Eg. in Opening there's the AttrackState, CreditState, DemoState, etc.

3. If in each state there's a reference to the same pointer of object (e.g. the GameData pointer of object), what should I do? And also if I changed the object's member value in one state, the other state's object reference will be changed also (because I referenced it by pointer).

Thanks in advance.

"I live for my dream. And my dream is to live my life to the fullest."

UML StateWizard acts as a Visual C++ Add-in, which provides a UML state machine programming mechanism in portable standard C/C++ for either embedded systems development and simulation, or Windows/WinCE application development. Open source at http://www.intelliwizard.com/[^]

This is a really good article and very well explained for a concrete example .I have some questions also. I don't know how I can implement this pattern in two special cases:

1) If one of the state need data from another state. For example in your GameState, say you killed X ennemies, now I want to display this data into the GameOverState (it will say: "Game Over: you killed X ennemies").

2) If I require some more informations at the initialization of one State. Say for example that there is another options in your IntroductionState that will load a previously saved game. Then, when initializing the GameState, you will need to pass the name of the file where the data is stored.

Hum... Yes, I asked the question a little bit too fast (didn't take the time to think ).

Of course, we can pass information to the new state inside the active state just before calling ChangeState... So, first create the new state (Instance()) then pass some parameters, and then call ChangeState.

I have also recently used the state pattern combined with adaptor in a project. The adaptor pattern is used to manage several modes of the application1. Scroll modes,2. Zooming modes,3. Panning modes,4. Editing modes,5. etc.