In my previous dev blog post on building reusable menu systems I talked about building reusable code that isn’t specific to one game. Reusable code can be brought into any new game or project and instantly be extended to work uniquely for that scenario. Code like this is ‘toolbox code’, or handy tools that can be pulled out for use whenever they’re needed. This is excellent when it comes to game jams and needed common functionality quickly. No need to recreate the wheel, right?
Game state management is one of the first pieces of toolbox code that I ever wrote, and ever since I’ve used the same very simple setup for game state management. In this first part of two articles on game state management we will look at the general concept of game states and their usefulness.
What is a Game State?
A Game State is exactly what it sounds like, a state of the game, or a unique way a portion of the game functions. The easiest way to explain this is by looking at the menu flow of a game. Typically when you fire up your favorite video game you’re first presented with a main menu where you can select New Game, Continue, Options, etc (Main Menu state). Selecting Continue loads your game and brings you into the world (Game World state). Pressing Start pauses the game and displays the Pause screen (Pause Menu state). Each of these differing pieces of the game are a unique state of how the game processes pretty much anything. For example, the controls in the Main Menu are different than the controls within the Game World, so input is captured and used differently depending on which of those states is active.
Fun Fact: Catfishing had five different game states: MainMenu, InGame, HowToPlayMenu, MakingOfMenu, and QuitMenu. Each menu had unique controls and used a different state.
How are Game States useful?
Let’s continue with our example above by saying you’re running around in the game world, pressing left/right/up/down (or WASD) to move your character. Suddenly you press Start/Enter to pause the game and the pause menu displays. What happens when you press left/right/up/down now?
Should the character move?
No, of course not. But how would the code know that it shouldn’t update the character? Game state. The code for capturing your controls can simply say ‘if the game state is GameWorld, grab input and move character, otherwise leave the character’. This is part of the power of game states: polling the game for the current state and reacting (or in this case, not reacting) correctly. Change the state, and bam, input works in a completely different way.
Additionally, in the example above, our Pause menu code can say ‘if game state is Paused, grab input for the menu’. Amazing!
One more example…
Let’s look at Final Fantasy, a game full of menus. Here’s a screenshot of the Final Fantasy IX equipment screen:
In this case the player selected ‘Equip’ from the top menu which opened the Equipment menu on the right, and by default has ‘Ultima Weapon’ selected. Within the Equipment menu, pressing up/down should move the cursor to the next/previous piece of equipment, however the top menu shouldn’t accept up/down and should only accept left/right input. Each menu has their own state.
In the next article I’ll discuss the actual code concepts I use for game state management including code samples. One last note: I focused a lot on menus in this blog because menus are easiest to imagine opening one on top of the other and constantly having to change how the game acts. Remember, game states can cover many different ways the game can function, not only for menus.