Guard Patrol & Hire: Driving the Guard Spawner from Verse

In Part 1 the NPC Spawner gave us bodies — but those bodies needed us to script their every move. Guards are different. A guard is the one NPC type that ships with a combat brain already wired in. It idles, patrols, grows suspicious, goes alert, chases, and attacks — all on its own. Our job in Verse is to tune that brain and react to it.

The guard's built-in state machine

<!-- section-art:the-guard-s-built-in-state-machine -->

Autonomous State Cycle

Every guard runs a finite-state machine you get for free:

Idle → Patrolling → Suspicious → Alert → Attacking → (target lost) → back to Patrolling

You don't write that loop. The guard_spawner_device exposes knobs to shape it and a fat set of events to listen in on it.

The guard spawner's surface (it's big)

Unlike the plain NPC spawner, the guard spawner is loaded with combat-specific controls:

# Lifecycle
GuardSpawner.Enable() / .Disable() / .Spawn() / .Despawn() / .Reset()

# Tuning the brain (editable vars)
set GuardSpawner.PatrolRange = 1500.0       # how far it roams (cm)
set GuardSpawner.VisibilityRange = 8000.0   # how far it can spot
set GuardSpawner.InitialHealth = 200.0
var GuardSpawner.CanBeHired : logic

# Commanding
GuardSpawner.ForceAttackTarget(Target, ?ForgetTime, ?ForgetDistance)
GuardSpawner.Hire(Instigator)
GuardSpawner.SetGuardsHireable() / .SetGuardsNotHireable()

# Listening to the FSM
GuardSpawner.SuspiciousEvent   # listenable(agent)
GuardSpawner.AlertedEvent      # listenable(device_ai_interaction_result)
GuardSpawner.TargetLostEvent   # listenable(device_ai_interaction_result)
GuardSpawner.HiredEvent / .DismissedEvent / .EliminatedEvent / .EliminatingEvent

Deploy, command, and recruit

<!-- section-art:deploy-command-and-recruit -->

Guard Deployment

Here one button deploys the squad and tightens its senses, a second button hires the living guards to whoever pressed it, and we hook the FSM events so a guard that goes alert is locked straight onto its target:

What's happening:

• Tuning vars with set — PatrolRange, VisibilityRange, and CanBeHired are all var fields on the device. You shape the built-in brain by writing to them; no extra devices needed.
• AlertedEvent hands us a device_ai_interaction_result. Its Source? is the guard, its Target? is who alerted them. We unwrap both with ? and then call ForceAttackTarget to bypass perception and commit the guard to the kill — with a 20-second ?ForgetTime so it gives up if it loses them.
• Hire(Presser) recruits every hireable guard to the presser's team. We called SetGuardsHireable() at deploy so the option is live.
• SuspiciousEvent (a bare listenable(agent)) lets us narrate the Suspicious state before it escalates to Alert.

This device is compile-verified in UEFN 5.8 (0 errors). Drop a Guard Spawner and two Buttons, give the spawner a guard character, and wire the slots.

Recap

• A guard is the only NPC that comes with a full combat FSM (Idle→Patrol→Suspicious→Alert→Attack) built in — you tune and react, you don't script the loop.
• Shape the brain with var fields like PatrolRange and VisibilityRange (set with set).
• ForceAttackTarget overrides perception and commits a guard to an agent, with optional ?ForgetTime/?ForgetDistance.
• Hire / SetGuardsHireable turn guards into recruitable allies; the rich event set (AlertedEvent, SuspiciousEvent, TargetLostEvent, …) lets you watch the FSM tick.

Next — Part 3: Custom NPC Behavior — we stop driving NPCs from a device and instead author a behavior that rides inside the character itself.