Episode 5: States

admin Episodes

I never realized this before working on this project, but there’s more to a game than just the part where you move your character around and shoot stuff. What I mean is that interacting with a game means traversing a number of different modes, menus, and interfaces. Let’s use Rare’s legendary first-person shooter, GoldenEye, as an example. Here’s how a player gets from powering on the system to completing a mission:

  • A number of logo images are shown
  • An animation is played (along with music)
  • The main menu is shown
  • The mission selection menu is shown
  • The mission is loaded and gameplay begins
  • The mission completion menu is shown
  • The main menu is shown

As you can see, the experience of playing GoldenEye is comprised of much more than just the gameplay. And although the gameplay is by far the most complex and important component, the rest of the game is certainly worthy of attention.

All this is to say I realized that I was going to have to create these different components and that I should probably keep them separate. It turns out that Phaser has a system for doing just that, and it calls these components states.

What Are States?

States are cool. In addition to separating the different phases of the game, states allow you to load stuff when it’s needed. Players generally don’t like waiting for their games to load, and states let you be strategic about when and where you load assets.

For example, the menu probably doesn’t need all of the sprites and sounds that are used during gameplay, so you can avoid loading them until you actually launch the gameplay state. However, you don’t want to start loading everything only after the player decides to start the game, so it would probably be smart to start preloading assets in advance. The strategy can be tricky, but the code is pretty straightforward.

States can be quickly and easily created…

1
2
// Create a state for booting the game
game.state.add('boot', bootState);

And starting them is a breeze…

1
2
// Start the boot state
game.state.start('boot');

Phaser’s states come with some functions that will automatically be called at various stages of the game. These include init, preload, create, render, and update. If you define these functions in the state, then Phaser will execute the code at the appropriate time.

We saw this in Episode 3 when we used the preload function to load an image asset…

1
2
3
4
// Preload image asset
function preload() {
  game.load.image('ship', 'ship.png');
}

The create function to enable the keyboard…

1
2
3
4
5
6
7
8
// Create in-game objects
function create() {
  // Create the player's sprite
  var player = Game.add.sprite(400, 300, 'ship');
 
  // Create keyboard cursor objects
  var cursors = game.input.keyboard.createCursorKeys();
}

And the update function to check for input…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Detect input from the user and update in-game objects
function update() {
  // Reset movement
  player.body.velocity.x = 0;
  player.body.velocity.y = 0;
 
  // Check if we should move left or right
  if (cursors.left.isDown) {
    player.body.velocity.x = -25;
  } else if (cursors.right.isDown) {
    player.body.velocity.x = 25;
  }
 
  // Check if we should move up or down
  if (cursors.up.isDown) {
    player.body.velocity.y = -25;
  } else if (cursors.down.isDown) {
    player.body.velocity.y = 25;
  }
}

So if we were to start whatever state these functions belong to, the preload and create functions would run as the state started, and the update function would be repeatedly called during the game loop until we started another state. Neat!

My States

I decided to use four states in Zyrian:

  1. Boot: initializes the Phaser engine, creates the game object, and launches the Preload state
  2. Preload: loads game settings, fonts, and all the assets for the Menu state, then launches the Menu state
  3. Menu: loads the menu interface, captures user input, loads all the assets for the Play state, and allows the player to launch the Play state
  4. Play: loads mission data, creates sprites, captures user input, and launches the Menu state if the player aborts or completes the mission

I initially thought of using a fifth state to handle the end of a mission (indicate success or failure, display the player’s score, give some menu options, etc.), but I decided that to just use the Menu state.

In the next episode I’ll talk about factories and how I separated the internal workings of the game from the states.

Leave a Reply