Diverting the Game Flow – State Stack

We can look at a state as an independent screen in the gaming software, an object that encapsulates the logic and graphics of a determined group of functionality and information.

Nothing stops us from creating a state that behaves in any way we'd like; however, there are some usual guidelines into what belongs to the same state. Let's try to prove this shallowly by looking at the commercial games of our time. We will often see most games showing introduction videos, from the trailer of the game to

company brand logos. We can look at each of these screens as states. In fact, having a VideoState that would simply playback a video and proceed to the next state would fit this model perfectly!

Then, we usually see a title screen, which is all about fancy artwork and minor information. That would be another state. Usually, by pressing a key, we would enter into the main menu, which itself is another effective state. If we look closely at any game, we can more or less define what belongs to each state, and that is the exact point so you can understand the concept better. There are countless ways you can separate your game into multiple states, but practicing always makes you achieve cleaner and more efficient designs!

Using such a system is of extreme importance. The combination of all these screens working together as one final product always makes a game feel more professional and rich in features.

However, not all the states are the same. While some states take over the whole screen and are running individually, others will work together, in parallel, rendering to the same screen, to achieve a variety of effects such as the very common pause screen, which still shows the game in background without motion.

To manage states efficiently and in an easy way, we create the stack!

The state stack

One way to visualize the flow of the game screens would be to picture a finite state machine of all the screens and how they trigger each other's appearance. However, while that works and is logically accurate, we broaden the concept of the active state into a stack.

[ 114 ]

www.it-ebooks.info

Chapter 5

Finite State Machine (FSM): While this is a well known concept across the world of computation, we will shortly describe the state machine as a collection of states that ensures that only one state is active at any given time. The transition of the current state into a new one is always triggered by a condition or a timer. So, for any state of the FSM, there will be a determined set of triggers that will activate new states when appropriate.

Now, turning the active state into a stack essentially means that the current state is not an individual piece anymore, but rather a stacked group of pieces, when necessary. Usually, the state mechanism will only have one state active at a time,

and while this is true, we effectively have a finite state machine as it is known by the computer science community. In other situations, however, such as the infamous pause screen, we will break the concept of FSM a little and have states on top of states, representing the active state all together.

As you can see in the following figure, a usual game flow can be represented like this:

[ 115 ]

www.it-ebooks.info

Diverting the Game Flow – State Stack

To manage all these screens and transitions, we create the StateStack class:

class StateStack : private sf::NonCopyable

{

public:

enum Action

{

Push,

Pop,

Clear,

private:

struct PendingChange

{

...

Action action; States::ID stateID;

};

private:

std::vector<State::Ptr> mStack; std::vector<PendingChange> mPendingList; State::Context mContext; std::map<States::ID,

std::function<State::Ptr()>> mFactories;

};

[ 116 ]

www.it-ebooks.info

Chapter 5

We also create the so called State class:

class State

{

public:

typedef std::unique_ptr<State> Ptr; struct Context { ... };

};

Adding states to StateStack

All states in the game have a unique identifier declared in an enum States, located in the StateIdentifiers.hpp file. For example, ID States::Game refers to the GameState class.

Initially, we register inside the stack all the states we may use. We do not create all the state objects from the beginning, since some of them may never exist, therefore we avoid loading resources of never-used states. Instead, we have factory functions that create a new state on-demand, represented by std::function. The member variable StateStack::mFactories maps state IDs to those factory functions.

[ 117 ]

www.it-ebooks.info