Create the Player States
Val has a lot going on—keeping the dungeon free and clear of monsters isn’t easy, ya know? The least you can do is help her keep track of her keys.
To begin, open the valsrevenge project in Xcode.
In the Project Navigator, select the valsrevenge group and create a new group (⌥⌘N). Name this new group States and move it above the Entities group.
Inside of the newly created States group, create a new file (⌘N) using the iOS Swift File template. Name the new file PlayerStates.swift.
For this project, and to keep things somewhat simplified, you will use a single file to store the player states. As you add more states to your game or build states that contain a lot of code, you may decide to create a separate file for each one. Replace the contents of the PlayerStates.swift file with the following code:
| | import GameplayKit |
| | |
| | class PlayerHasKeyState: GKState { |
| | |
| | } |
| | |
| | class PlayerHasNoKeyState: GKState { |
| | |
| | } |
Here, you are declaring two separate states using the GKState superclass, each representing a possible game state for the player: one for when Val has a key in her possession, and one for when she does not. With these two states, you will have more precise control over the state-dependent game logic.
With the two player states stubbed out, you’re ready to add the rest of the code. Update the code in the PlayerStates.swift file to match the following:
| | import GameplayKit |
| | |
| | class PlayerHasKeyState: GKState { |
| | |
| | override func isValidNextState(_ stateClass: AnyClass) -> Bool { |
| | return stateClass == PlayerHasKeyState.self || |
| | stateClass == PlayerHasNoKeyState.self |
| | } |
| | |
| | override func didEnter(from previousState: GKState?) { |
| | print(" Entering PlayerHasKeyState") |
| | } |
| | |
| | override func willExit(to nextState: GKState) { |
| | // print("Exiting PlayerHasKeyState") |
| | } |
| | |
| | override func update(deltaTime seconds: TimeInterval) { |
| | // print("Updating PlayerHasKeyState") |
| | } |
| | } |
| | |
| | class PlayerHasNoKeyState: GKState { |
| | |
| | override func isValidNextState(_ stateClass: AnyClass) -> Bool { |
| | return stateClass == PlayerHasKeyState.self || |
| | stateClass == PlayerHasNoKeyState.self |
| | } |
| | |
| | override func didEnter(from previousState: GKState?) { |
| | print("Entering PlayerHasNoKeyState") |
| | } |
| | |
| | |
| | override func willExit(to nextState: GKState) { |
| | // print("Exiting PlayerHasNoKeyState") |
| | } |
| | |
| | override func update(deltaTime seconds: TimeInterval) { |
| | // print("Updating PlayerHasNoKeyState") |
| | } |
| | } |
There’s quite a bit of code here, so let’s break it down:
The isValidNextState(_:) method in each state tells the state machine whether or not the state it’s trying to enter is valid. In this case, a player going from either state into the other (or itself) is allowed, so you return both states in each method.
Although you’re not doing much with the didEnter(from:) and willExit(to:) methods, you can use these to run state-dependent game logic when entering and/or exiting a specific state. For example, let’s say players can only keep keys for a certain length of time. In that case, you may want to start a timer in the didEnter(from: method that automatically exits the PlayerHasKeyState after that time expires. That’s not the plan for this game, but it is possible. Instead, you’re just printing a message to the console when entering the different states. (You normally wouldn’t override these methods if you weren’t using them.)
Finally, there’s the update(deltaTime:) method. With this method, you can execute per-frame, state-dependent game logic while the state machine is in this state—whatever the state may be at the time of the update. For example, using the same example from earlier, you could use this method to track the elapsed time since entering the PlayerHasKeyState state to automatically exit to the PlayerHasNoKeyState state after a specific amount of time has passed. (Again, you normally wouldn’t override this method if you weren’t using it.)
With the player states ready and waiting, it’s time to set up a state machine to handle them.