What if your game enemies could think and react on their own, without you coding every tiny step?
Why Enemy patrol and chase patterns in Unity? - Purpose & Use Cases
Imagine you are making a game where enemies walk back and forth on a path and chase the player when seen. Without patterns, you have to move each enemy step-by-step by hand, checking every moment if the player is close.
Doing this manually means writing lots of repeated code for each enemy. It's slow to update, easy to make mistakes, and hard to add new behaviors. You might forget to check if the enemy should turn or chase, causing bugs.
Using enemy patrol and chase patterns lets you write clear rules for how enemies move and react. The enemy automatically walks a path and switches to chasing when the player is near. This saves time and makes your game feel alive and smart.
if(playerClose) { moveTowardsPlayer(); } else { moveForward(); if(hitWall) { turnAround(); } }
state = playerClose ? Chase : Patrol; if(state == Patrol) { walkPath(); } else { chasePlayer(); }
This lets you create dynamic enemies that react naturally, making your game more fun and challenging without extra work.
Think of a guard in a castle game who walks a hallway and suddenly runs after the player when spotted, adding excitement and strategy.
Manual enemy movement is slow and error-prone.
Patterns automate patrol and chase behaviors clearly.
They make enemies smarter and games more engaging.
Practice
Solution
Step 1: Understand enemy patrol behavior
Enemy patrol means moving the enemy between fixed points in a loop to simulate guarding or searching.Step 2: Identify correct behavior from options
Only moving between set points repeatedly matches patrol behavior.Final Answer:
To move the enemy between set points repeatedly -> Option BQuick Check:
Enemy patrol = moving between points [OK]
- Confusing patrol with attack or random movement
- Thinking patrol involves shooting or disappearing
Solution
Step 1: Recall Vector3.Distance syntax
The correct method to get distance between two Vector3 points is Vector3.Distance(point1, point2).Step 2: Check each option
float dist = Vector3.Distance(enemy.position, player.position); uses Vector3.Distance with positions, which is correct. Others have syntax errors or wrong usage.Final Answer:
float dist = Vector3.Distance(enemy.position, player.position); -> Option DQuick Check:
Use Vector3.Distance(point1, point2) for distance [OK]
- Subtracting vectors without calling Distance method
- Calling Distance on a Vector3 instance incorrectly
- Passing transforms instead of positions
if (Vector3.Distance(transform.position, player.position) < chaseDistance) {
Debug.Log("Chasing player");
} else {
Debug.Log("Patrolling");
}Solution
Step 1: Calculate distance and compare
Distance is 3, chaseDistance is 5, so 3 < 5 is true.Step 2: Determine which branch runs
Since condition is true, "Chasing player" is printed.Final Answer:
Chasing player -> Option CQuick Check:
Distance 3 < 5 triggers chase [OK]
- Confusing less than with greater than
- Assuming no output if condition true
- Thinking code causes error
void Patrol() {
int currentPoint = 0;
transform.position = Vector3.MoveTowards(transform.position, patrolPoints[currentPoint].position, speed * Time.deltaTime);
if (transform.position == patrolPoints[currentPoint].position) {
currentPoint++;
if (currentPoint >= patrolPoints.Length) {
currentPoint = 0;
}
}
}Solution
Step 1: Check variable scope for currentPoint
currentPoint is reset to 0 every time Patrol() runs, so it never increments properly.Step 2: Understand how to fix the scope issue
Declaring currentPoint outside the method (as a class variable) preserves its value between calls.Final Answer:
currentPoint should be declared outside the method to keep its value -> Option AQuick Check:
Keep patrol index outside method to track progress [OK]
- Thinking MoveTowards usage is wrong
- Confusing comparison operators in if
- Misunderstanding Time.deltaTime usage
Solution
Step 1: Understand behavior switching logic
The enemy needs to switch between patrol and chase based on player distance dynamically.Step 2: Use a state variable to track current behavior
A state variable (like enum or bool) can control which method runs each frame depending on distance.Step 3: Implement distance check to update state
If player is closer than 4 units, set state to chase; else set to patrol.Final Answer:
Use a state variable to switch between patrol and chase based on distance checks -> Option AQuick Check:
State variable + distance check = behavior switch [OK]
- Running patrol and chase at the same time causing conflicts
- Ignoring player distance for switching
- Using timers instead of distance checks
Ready to prove it?
Pass the test and this pattern moves unknown
