Chapter 5. Handling Game States

When we first start up a game, we expect to see a splash screen showing any branding for publishers and developers, followed by a loading screen as the game does its initial setup. After this, we are usually faced with a menu screen; here, we can change settings and start the game. Starting the game leads us to another loading screen, possibly followed by a cut scene, and finally, we are in the game. When we are in the game, we can pause our play (allowing us to change any settings), exit the game, restart the level, and so on. If we fail the level, we are shown either an animation or a game over screen depending on how the game is set up. All of these different sections of a game are called Game States. It is very important that we make the transition between these states as easy as possible.

In this chapter we will cover:

• Two different ways of handling states, starting with a really simple implementation and gradually building our framework implementation...

A simple way for switching states

One of the simplest ways to handle states is to load everything we want at the game's initialization stage, but only draw and update the objects specific to each state. Let's look at an example of how this could work. First, we can define a set of states we are going to use:

enum game_states
{
  MENU = 0,
  PLAY = 1,
  GAMEOVER = 2
};

We can then use the Game::init function to create the objects:

// create menu objects
m_pMenuObj1 = new MenuObject();
m_pMenuObj1 = new MenuObject();

// create play objects
m_pPlayer = new Player();
m_pEnemy = new Enemy();

// create game over objects…

Then, set our initial state:

m_currentGameState = MENU;

Next, we can change our update function to only use the things we want when in a specific state:

void Game::update()
{
  switch(m_currentGameState)
  {
    case MENU:
      m_menuObj1->update();
      m_menuObj2->update();
      break;

    case PLAY:
      m_pPlayer->update();
      m_pEnemy->update();

    case GAMEOVER...

Implementing finite state machines

What we really need is the ability to define our states outside the game class, and have the state itself take care of what it needs to load, render, and update. For this we can create what is known as an FSM. The definition of FSM, as we will use it, is a machine that can exist in a finite number of states, can exist in only one state at a time (known as the current state), and can change from one state to another (known as a transition).

A base class for game states

Let's start our implementation by creating a base class for all of our states; create a header file called GameState.h:

#include<string>
class GameState
{
public:
  virtual void update() = 0;
  virtual void render() = 0;

  virtual bool onEnter() = 0;
  virtual bool onExit() = 0;

  virtual std::string getStateID() const = 0;
};

Just like our GameObject class, this is an abstract base class; we aren't actually putting any functionality into it, we just want all of our derived classes to...

Implementing menu states

We will now move on to creating a simple menu state with visuals and mouse handling. We will use two new screenshots for our buttons, which are available with the source code downloads:

The following screenshot shows the exit feature:

These are essentially sprite sheets with the three states of our button. Let's create a new class for these buttons, which we will call MenuButton. Go ahead and create MenuButton.h and MenuButton.cpp. We will start with the header file:

class MenuButton : public SDLGameObject
{
public:

  MenuButton(const LoaderParams* pParams);

  virtual void draw();
  virtual void update();
  virtual void clean();
};

By now this should look very familiar and it should feel straightforward to create new types. We will also define our button states as an enumerated type so that our code becomes more readable; put this in the header file under private:

enum button_state
{
  MOUSE_OUT = 0,
  MOUSE_OVER = 1,
  CLICKED = 2
};

Open up the MenuButton.cpp file...

Summary

This chapter has left us with something a lot more like a game than in previous chapters. We have created states for menus, pause, play, and game over with each state having its own functionality and being handled using FSM. The Game class now uses FSM to render and update game objects and it does not now handle objects directly, as each individual state handles its own objects. We have also created simple callback functions for our buttons using function pointers and static functions.