Patrols, Spawners, and Persistence

DuckShell treats patrols and spawners as first-class systems. That is the correct design choice because a route and a persistent spawn point are related, but they are not the same thing.

Patrols are route content

Patrol data lives in patrols.yml. A patrol is the right tool when:

• an NPC should follow a waypoint route while idle
• combat can interrupt the route
• the NPC should later return to the route
• a boundary leash should keep the patrol in a believable area

Patrols are encounter choreography.

Spawners are world-presence content

Spawner data lives in spawners.yml. A spawner is the right tool when:

• a location should maintain a target alive count
• mobs should repopulate after deaths
• activation should depend on nearby players
• admins need teleport, visualize, and quick editor tools

Spawners are persistence infrastructure.

Why the split matters

A good content setup usually combines them instead of forcing one system to impersonate the other.

Examples:

• use a spawner to keep a checkpoint populated
• use a patrol to make one guard circle the checkpoint
• use both when a landmark should recover after players leave and return later

That is much easier to maintain than trying to stuff routing logic into one giant spawn entry.

Persistence and save behavior

Both systems are intended to survive restarts cleanly:

• patrol edits save back to patrols.yml
• spawner edits save back to spawners.yml

This makes them safe authoring surfaces for long-running servers instead of temporary testing tools only.

The practical design rule

Ask one question first:

• "Is this content about where NPCs come from?"
• or "Is this content about where NPCs move when idle?"

If it is the first, start with a spawner.
If it is the second, start with a patrol.

Recommended next pages

• patrol Editor and Spawner Workflows
• debug, Performance, Corpses, and Live Ops