4.3 — Chase: The Aggro Radius

Patrol is calm. One distance check turns a guard into a hunter — and you wrote that check in 3.1. What is new is not the maths: the target moves.

Break It Down~10 minSolo build

An enemy that comes for me when I get close. That is the whole feature, and like every feature in this course it is not one problem — it is several standing in a line, one of which you have never solved before.

First, before any code: cut that into parts small enough that you could look each one up on its own.

No parts listed here on purpose. Splitting the problem up is the work of this lesson — write your list before you open the file.

Most of the parts inside this feature are things you have already built somewhere else: a distance check written for a turret, a movement toward a target written for a guard, an animator value driven from a direction, a tuning knob, a null guard. Only one part has no earlier version, and it is the one to slow down on — a direction worked out from two positions, one of which you do not control, recomputed every frame. That is what a well-sequenced course feels like from the inside: the same parts, standing in a new order, with one genuinely new one among them.

The test for a finished split: could you look this part up on its own, right now, in one search? "Make the enemy chase me" cannot be looked up. "Subtract two positions to get a direction" can. If a part is still too big to search for, it is two parts.

Your turn

List the parts of this problem, in the order you would build them.

Your answer

Write the rule down before you code it: name the value this lesson recomputes every frame, why computing it once is not enough, and what the enemy's speed depends on without length one.

Your answer

In the Editor ~15 min

Scene view → save the Overworld before you touch anything, then Hierarchy → the four MobileEnemy instances, then Project window → Assets/Prefabs/MobileEnemy. All four share one prefab, so one serialized aggro field is one number for all four. Decide whether that is what you want before you write the field.
Inspector → the prefab root: the EnemyController from 4.1, with the collider and body you gave it. A chase needs a body a wall can stop, and 4.1 already made that true.
Inspector → the child named Sprite, then Window → Animation → Animator. Re-read the four Direction values from 4.2: a hunter that keeps the guard's facing reads as a bug, and those four integers are how you fix it.
Game view → press Play and walk near an enemy with the Console open. It ignores you and walks its beat. That is the "before" you are about to change.

In the Code ~30 min

No API table: every call today is one you have already made. One file — Assets/Scripts/EnemyController.cs, your patrol from 4.1.

Slow down on one part: working out the direction. Every direction you have written so far came from something you were handed — keys you pressed in 1.4, a target you placed in 4.1, a muzzle you aimed at the instant of firing in 3.2. This time both ends move, and it is worked out again from the two positions, every frame. That is where the bugs will be.

The one fact I will hand you: the vector from the enemy to the player is the player's position minus the enemy's, in that order. Swap the operands and you have built something that runs away instead. Give it length one before you multiply it by a speed — otherwise the enemy's speed depends on how far away you are, and it crawls the moment it reaches you.

The second decision is not about maths. Your Update() patrols unconditionally and now has to chase as well — two behaviours that want the same object, with no earlier lesson to copy from. Pick one of these three on purpose:

How the two behaviours coexist	What the code does each frame	What the player sees	The risk
Chase is an `if`; patrol is the `else`	Exactly one of the two runs.	A clean switch: the moment you cross the line, the enemy turns and comes for you.	Nothing holds the answer to "am I chasing?", so no other part of your code can ask. It also forces you to decide which wins when you are inside the patrol beat and the radius at once.
Chase is an `if`; the patrol keeps running anyway	Both write to the enemy's position in the same frame.	A stutter, or an enemy that drifts toward you while still dutifully flipping at the end of its beat.	Two systems moving one object, and their sum is a third movement nobody designed. With the 4.1 leash this is easy to miss: the patrol's flip check still measures from the spawn anchor, so it reverses your chase mid-pursuit.
Chase is an `if`; the patrol is switched off by a flag	The flag records the mode, and the patrol checks it.	Same as the first row, at first.	One extra field, and one extra thing to keep true — and the moment you have a third behaviour, one more clause in every check. Keep this thought for 4.5.

Architectural specification for the chase.

Which of the two targeting options from 3.1 did you choose, what does that choice cost across four enemy instances, and what does GameObject.FindWithTag(String tag) hand back when nothing matches? Which lifecycle method holds that lookup so it runs once — and does the guard clause after it stop the whole update, or only the chase half, given what the enemy still has to do with no player in the scene?
Which serialized float lets a designer say how close you must get, and what do you name it so that a stranger reading the Inspector sees its relationship to the patrol knob beside it?
Which movement call moves the enemy — the one your patrol uses, or a different one? If they differ, what does the Rigidbody2D have to satisfy for both to work?
Should the patrol's own memory — its target and its anchor — be reset or preserved when the chase ends? Say what the player sees either way.
How do you print the current mode to the Console so you can watch the transition happen, and which animator Direction value does the enemy carry while chasing? (Re-read your 4.2 notes rather than guessing.)

Socratic: States, Transitions and Two Writers

You gave the turret a distance check in 3.1 and it opened fire. What does the enemy do with that same answer that the turret did not do — and why does that make the enemy harder to build?Your answer
Your enemy is inside its patrol beat and inside the aggro radius at the same time. Which behaviour must win? Describe exactly what the player sees if you pick the other one.Your answer
If both behaviours move the transform in one frame, what is the sum of "walk right at 2 units per second" and "walk toward the player at 2 units per second"? Why is that sum not a chase — and which direction does the enemy actually travel?Your answer

Checkpoint — before moving on, you must be able to:

Break the chase into parts, and say in one line what each part does and where you built it before
Compare Vector3.Distance(a, b) against sqrMagnitude, and say which you chose for the enemy and why
Compare GameObject.FindWithTag(String tag) against a serialized reference, and account for the four enemy instances
Explain your patrol-to-chase transition, point at the construct that stops both behaviours running at once, and say why two writers on one transform produce motion nobody designed
Design an aggro radius that reads as fair next to the turret's detection range, and say which of the two the player should meet first
Commit and push

Reference Docs

Need a deeper explanation? These pages cover the same concepts:

How do I…? index — find this lesson again by the question you were asking
Unit 4: The Enemy — chase and pursuit in depth
Unity + C# Quick Reference — normalizing, GameObject.FindWithTag(String tag) and vector maths

Next: 4.4 — Attack: Close-Range Contact Damage, where catching you finally has a consequence.

Student name0/5 answered

Answers save on this device as you type. At the end of class, click Download and upload the file to the Canvas assignment.

I finished this lesson

Saved on this device only — the Dashboard tracks your progress.