👁️ Lesson 6.4: Sensing the Player — A Patrolling Guard (Mini-Project)

What "Seeing" Really Means

To a human, "the guard can see the player" is obvious. To code, it's three separate questions that must all be yes:

1. Is the player close enough? — within the guard's sight range. (A distance check.)
2. Is the player in front of the guard? — inside the field-of-view cone, not behind its head. (An angle check.)
3. Is the view unobstructed? — no wall or crate between them. (A raycast.)

Miss any one and the AI feels broken: skip the angle and the guard has eyes in the back of its head; skip the raycast and it sees through solid walls. Together, these three give the fair, readable stealth behaviour players expect.

The Vision Cone

Picture the guard from above. Its vision is a wedge: a maximum radius (the range) and an angular spread (the FOV), pointing wherever the guard faces. The player is only "seen" when they're inside that wedge and a straight line to them isn't blocked. Here's the whole idea in one top-down diagram:

Building the Sensor

Now the code. Run the checks cheapest-first: a distance compare is nearly free, the angle is cheap, and the Raycast is the most expensive — so bail out early before you ever fire a ray.

using UnityEngine;

public class VisionSensor : MonoBehaviour
{
    [SerializeField] Transform player;
    [SerializeField] float sightRange = 12f;
    [SerializeField] float fieldOfView = 90f;      // total cone angle in degrees
    [SerializeField] float eyeHeight = 1.6f;       // raise the ray to "eye" level
    [SerializeField] LayerMask obstacleMask;       // what counts as a sight blocker

    public bool CanSeePlayer()
    {
        if (player == null) return false;

        Vector3 toPlayer = player.position - transform.position;

        // 1) Distance — cheapest. Compare squared to skip a sqrt.
        if (toPlayer.sqrMagnitude > sightRange * sightRange) return false;

        // 2) Angle — is the player inside the FOV cone?
        //    Vector3.Angle returns 0..180 between forward and the direction to the player.
        float angle = Vector3.Angle(transform.forward, toPlayer);
        if (angle > fieldOfView * 0.5f) return false;

        // 3) Line of sight — raycast from eye level; anything on obstacleMask blocks.
        Vector3 eye = transform.position + Vector3.up * eyeHeight;
        Vector3 dir = (player.position + Vector3.up * eyeHeight) - eye;
        if (Physics.Raycast(eye, dir.normalized, out RaycastHit hit, sightRange, obstacleMask | (1 << player.gameObject.layer)))
        {
            // we saw the player only if the ray hit the player first (nothing in the way)
            return hit.transform == player;
        }
        return false;
    }
}

Walk through the three gates. The distance check uses sqrMagnitude against sightRange squared — no square root needed. The angle check uses Vector3.Angle between the guard's forward and the direction to the player; if that exceeds half the FOV, the player is off to the side or behind. Only if both pass do we fire the Raycast from eye height; if the first thing it hits is the player, the view is clear.

Optional: Hearing

Sight alone can feel unfair when the player sneaks directly behind a guard. A cheap second sense fixes it: hearing. The player emits a "noise" (louder when sprinting, near-silent when crouching); the guard notices if that noise is within a hearing radius, regardless of angle or walls.

[SerializeField] float hearingRange = 6f;

// Called by the player (or a movement script) when it makes noise.
// loudness 0..1 scales how far the sound carries.
public bool CanHearPlayer(float loudness)
{
    if (player == null) return false;
    float range = hearingRange * loudness;
    float sqrDist = (player.position - transform.position).sqrMagnitude;
    return sqrDist <= range * range;
}

Hearing doesn't need an angle or a ray — sound goes around corners. Treat it as an alternative trigger into Chase (or into an intermediate "Investigate" state that walks toward the last-heard position). It's optional for this mini-project, but it's what turns a guard from "sees you" into "notices you," which feels much smarter.

Wiring It Into the FSM

Here's the payoff. In Lesson 6.3 you called a stubbed CanSeePlayer(). Now you delete the stub and delegate to the real sensor. Two small edits to EnemyAI:

[RequireComponent(typeof(NavMeshAgent), typeof(VisionSensor))]
public class EnemyAI : MonoBehaviour
{
    VisionSensor vision;

    void Awake()
    {
        agent   = GetComponent<NavMeshAgent>();
        animator = GetComponent<Animator>();
        vision  = GetComponent<VisionSensor>();   // NEW
    }

    // Replace the old stub with the real thing.
    bool CanSeePlayer() => vision.CanSeePlayer();   // (add "|| vision.CanHearPlayer(...)" for hearing)
}

That's the entire integration. Because the FSM was written against a CanSeePlayer() method from the start, swapping a fake implementation for a real one changes nothing else. This is the decoupling lesson from Module 2 paying off in miniature: the FSM depends on the question ("can I see the player?"), not on how it's answered.

💡 The give-up timer now makes sense. With real vision, CanSeePlayer() flicks to false the instant the player ducks behind a wall. The giveUpTime from Lesson 6.3 is what keeps the guard chasing for a few seconds after losing sight — hunting toward where you were — instead of instantly forgetting you. That short memory is the difference between a dumb guard and a tense one.

The Sense → Decide → Act Loop

Zooming out, every frame the guard runs the same three-beat loop. The sensor is the sense step; the FSM's Decide and Act are the other two. Seeing it whole clarifies where each piece of code lives:

Figure 2: The full sense → decide → act loop. The VisionSensor produces canSee; the FSM consumes it to pick transitions, then acts by driving the NavMeshAgent and Animator.

Mini-Project: The Patrolling Guard

Time to bring the whole module together into one deliverable. You'll assemble a guard that patrols a route, catches the player with a real vision cone, chases, attacks at close range, and returns to its patrol when it loses you.

Summary

🚀 What's Next?

Your guard can catch the player and swing at them — but nothing happens on a hit yet. Module 6 gave enemies a brain; Module 7 gives the whole cast consequences. In Lesson 7.1: Health & Damage with Interfaces you'll build an IDamageable interface so the guard's attack (and the player's) can hurt anything that implements it — the clean, decoupled way to do combat.