A State Machine for Animation

Consider a 2D “endless running” game—in this style of game, the player character runs automatically, and the player must press a jump button to pass obstacles. Running and jumping have separate animations, and while running or jumping, the player’s position needs to be updated. This design can be expressed as a state machine with three states, illustrated in Figure 4-2.

Figure 4-2A State Machine for Animation

• Running. While in this state, loop the run animation. If the player presses the jump button, switch to the Jump state. If the player runs off a ledge, switch to the Falling state.

• Jumping. On entering this state, play a sound effect, and start a one-time jumping animation. While in this state, move the character up a short distance (per frame), decelerating with gravity. When upward speed reaches zero, switch to the Falling state.

• Falling. On entering this state, start a one-time falling animation. While in this state, move the character down a short distance (per frame). On reaching the ground, switch to the Running state and play a one-time landing animation and sound effect.

A State Machine for Enemy Behavior

Consider an arcade action game with enemy characters that pursue the player. The player can occasionally gain a power-up that makes the enemies temporarily vulnerable to attack, and defeated enemies are out of the game for some time before reappearing. Each enemy character can use its own state machine instance, with the following states, illustrated in Figure 4-3:

Figure 4-3A State Machine for Enemy Behavior

• Chase. On entering this state, display the enemy’s normal appearance. While in this state, change position on every frame to pursue the player. If the player gains a power-up, switch to the Flee state.

• Flee. On entering this state, display a vulnerable appearance. While in this state, change position on every frame to avoid the player. After some time has elapsed while in this state, return to the Chase state. If attacked by the player, switch to the Defeated state.

• Defeated. On entering this state, display an animation and increment the player’s score. While in this state, move what remains of the enemy to a central location where it will later reappear. Upon reaching that position, switch to the Respawn state.

• Respawn. While in this state, simply track the amount of time spent since entering. After some time has elapsed, return to the Chase state.

This state machine is further illustrated in the Building a Game with State Machines section below, as well as in the Maze sample code project.

A State Machine for Game UI

In almost any game, a user interface depends on the state of the game, and vice versa. For example, pausing a game might show a menu screen, and while the game is paused, normal gameplay code should not take effect. You can control your game’s overall user interface with a set of states like those listed below and illustrated in Figure 4-4:

Figure 4-4A State Machine for Game UI

• TitleScreen. The app opens in this state. Upon entering this state, display a title screen. While in this state, animate the title screen. Switch to the Playing state upon user input.

• Playing. While in this state, call per-frame update logic for gameplay. Switch to the Paused state upon appropriate user input.

• Paused. Upon entering this state, apply a visual effect to the game screen to indicate that gameplay is paused. Remove the effect when exiting the state. (There is no need to suspend gameplay operation during this state, as game logic is invoked only during the Playing state.) Switch back to the Playing state upon appropriate user input.

• GameOver. When entering this state, display a UI that summarizes the player’s actions and score, and respond to events for operating any interactive elements in that UI. Switch to the Playing state (starting a new game) upon appropriate user input.

This sort of state machine design can be easily extended to cover many games. For example, additional Menu states could handle a complex series of menus, or a Cutscene state could run scene animations but not handle input.

Define States and Their Behavior

Each state in the state machine is a subclass of GKState containing custom code that implements state-specific behavior. This state machine uses four state classes: AAPLEnemyChaseState, AAPLEnemyFleeState, AAPLEnemyDefeatedState, and AAPLEnemyRespawnState. All four state classes make use of general information about the game world, so all four inherit from an AAPLEnemyState class that defines properties and a common initializer used by all state classes in the game. Listing 4-1 summarizes the definitions of these classes.

Most of these state classes need no additional public properties—all information they need about the game comes from their reference to the main AAPLGame object. This reference is weak, because the state objects are owned by state machines, which in turn are owned by entities, each of which is owned by the Game object.

Each state class then defines state-specific behavior by overriding the GKState enter, exit, and update methods. For example, Listing 4-2 summarizes the implementation of the Flee state.

The state machine calls a state object’s didEnterWithPreviousState: method when that state becomes the machine’s current state. In the Flee state, this method uses the game’s SpriteComponent class to change the appearance of the enemy character. (See the Entities and Components chapter for discussion of this class.) This method also chooses a random location in the game level for the enemy to flee toward.

The updateWithDeltaTime: method is called for every frame of animation (ultimately, from the update: method of the SpriteKit scene displaying the game). In this method, the Flee state continually recalculates a route to its target location and sets the enemy character moving along that route. (For a deeper discussion of this method’s implementation, see the Pathfinding chapter.)

You can enforce preconditions or invariants in your state classes by having each class override the isValidNextState: method. In this game, the Respawn state is a valid next state only for the Defeated state—not the Chase or Flee state. Therefore, the code in the EnemyRespawnState class can safely assume that any side effects of the Defeated state have already occurred.

Create and Drive a State Machine

After you define GKState subclasses, you can use them to create a state machine. In the Maze game, an AAPLIntelligenceComponent object manages a state machine for each enemy character. (To learn more about the component-based architecture in this game, see the Entities and Components chapter.) Setting up a state machine is simply a matter of creating and configuring an instance of each state class, then creating a GKStateMachine instance that uses those objects, as shown in Listing 4-3.

The game then creates an instance of the AAPLIntelligenceComponent class for each enemy character in the game. To support running per-frame update logic in each state class, the AAPLIntelligenceComponent class uses its updateWithDeltaTime: method to call the corresponding method on its state machine. In turn, the state machine calls the update method for whichever state object is its current state—so, for example, the per-frame update logic for the Chase state runs only when the Chase state is active.

To run the state machine through its sequence of states, call its enterState: method whenever a state change is appropriate in your game. In this example, each enemy character’s state machine starts in the Chase state. The Maze game changes states in several places:

• The main AAPLGame object keeps track of whether the player has the power to defeat enemy characters. When the player gains or loses this power, the setHasPowerup: method changes all enemies’ current state to the Flee or Chase state, respectively, as shown below:

  1. - (void)setHasPowerup:(BOOL)hasPowerup {
  2. static const NSTimeInterval powerupDuration = 10;
  3. if (hasPowerup != _hasPowerup) {
  4. // Choose the Flee or Chase state depending on whether the player has a powerup.
  5. Class nextState;
  6. if (!_hasPowerup) {
  7. nextState = [AAPLEnemyFleeState class];
  8. } else {
  9. nextState = [AAPLEnemyChaseState class];
  10. }
  11. // Make all enemies enter the chosen state.
  12. for (AAPLIntelligenceComponent *component in self.intelligenceSystem) {
  13. [component.stateMachine enterState:nextState];
  14. }
  15. self.powerupTimeRemaining = powerupDuration;
  16. }
  17. _hasPowerup = hasPowerup;
  18. }

• The AAPLGame object also handles physics contacts reported by SpriteKit. When the player character collides with an enemy character, the game first uses that enemy’s current state to determine the outcome of their interaction. If the enemy is in the Flee state, the player defeats that enemy, which transitions into its Defeated state.

• The AAPLEnemyDefeatedState class moves a defeated enemy back to its starting position, then switches to the Respawn state. To accomplish these tasks, the Defeated state finds a path to the starting position, then uses the game’s AAPLSpriteComponent class to generate an SKAction sequence. This sequence moves the enemy character along the path, and after all of its move actions are complete—that is, the character is at the end of the path—it switches to the Respawn state.

  For details on pathfinding and this game’s AAPLSpriteComponent class, see the Pathfinding and Entities and Components chapters.

• The AAPLEnemyRespawnState class handles the wait time for each defeated enemy before it returns to play. This state class uses its updateWithDeltaTime: method to test an elapsed time property and switch to the Chase state accordingly:

  1. - (void)updateWithDeltaTime:(NSTimeInterval)seconds {
  2. self.timeRemaining -= seconds;
  3. if (self.timeRemaining < 0) {
  4. [self.stateMachine enterState:[AAPLEnemyChaseState class]];
  5. }
  6. }