The Wander Algorithm
In this section we’ll leverage what we’ve learned about Croutons to write a script that makes an enemy wander randomly around the board. If the enemy detects that the Player is close-by, the enemy will pursue her until she runs away, kills the enemy, or the player dies.
This Circle Collider represents how far the Enemy can “see.” In other words, when the Player’s collider crosses the Circle Collider, the Enemy can see the Player. Remember how trigger colliders work: because we’ve checked the Is Trigger box on the Circle Collider, it can pass through other objects. The Enemy will “see” the Player cross the collider, then change course and pursue her.
The Wander Coro tine
The Wander Routine() Coro tine contains all of the high-level logic from the Wander Algorithm described, aside from the pursuit logic. We’ll still need to write some of the methods called from within Wander Routine () but this Coro tine is the brains of the Wander Algorithm.
Choosing a New Endpoint
We’ve written out the starting point and the Wander Coro tine, so it’s time to start filling in the methods called by the WanderCoroutine(). The ChooseNewEndpoint() method is responsible for choosing a new endpoint at random for the Enemy to travel to.
Configure Wander Script
Select the Enemy prefab and configure the Wander script to look like Figure 8-9. Set the Pursuit Speed to a slightly faster speed than the Wander Speed. The Direction Change Interval is how often the Wander Algorithm will call ChooseNewEndpoint() to choose a new direction to wander in.
So we’ve implemented nearly all of the Wander algorithm except for the Pursuit logic. In this section we’ll write some simple logic to plug into the Wander algorithm to make the Enemy pursue the Player. The Pursuit logic hinges on the OnTriggerEnter2D () method, which is provided with every MonoBehaviour. As we learned, Trigger Colliders (colliders with the Is Trigger property set) can be used to detect that another Game Object has entered the collider. When this occurs, the OnTriggerEnter2D () method is called on the MonoBehaviours involved in the collision.
Provided the Enemy pursuit Speed is less than the Player movement Speed, the Player can outrun any Enemy. As the Player runs away from the Enemy, she will exit the Enemy Trigger Collider, causing the OnTriggerExit2D () to be called. When this occurs, the Enemy effectively loses sight of the Player and resumes wandering aimlessly. This method is nearly identical to OnTriggerEnter2D () with just a few tweaks.
At the moment, we want the Ammo in our game to only damage Enemies, but you could just as easily extend the functionality in the future to damage other things as well. Each Ammo Object will expose a property in the Unity Editor describing the amount of damage it causes. We’ll turn the Ammo Object into a prefab. If you ever wanted to provide the player with Artificial Intelligence and Slingshots 304 two different types of Ammo, it’s a simple task to create a second Ammo prefab, change the Sprite on it and the damage done. Create a new Game Object in the Project hierarchy and rename it, “Ammo Object”. We’re going to create the Ammo Object, configure it, write the script, and then turn it into a prefab.
You’ve used Croutons to build intelligent chasing behavior and in doing so, constructed the first real challenge for the gamer. The player can die now and needs to be able to defend herself, so we built a slingshot that fires ammunition at the Enemies. The slingshot utilizes a widely used optimization technique called Object Pooling. We took advantage of some high-school level trigonometry for the trajectory arc. We learned about Blend Trees and how they can help us to better organize our game architecture and streamline the state machine if we want to add additional animations in the future. We also learned how simple it is to build our game for the PC or Mac and run it outside of Unity.