NPCEntity small brain: perception + order execution #4

New issue

Open

opened 2026-11-15 01:09:56 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:09:56 +00:00

Member

The plan

The NPCEntity small brain is execution only: it takes an order and figures out HOW to carry it out — navmesh pathing, line-of-sight checks, stuck handling, basic logic. It never decides what to do. This issue builds the HOW. It depends on the order-vocabulary issue: the brain executes the settled vocabulary, and no order type gets built here that the vocabulary does not contain.

Current state

addons/daisy/src/npc_entity.gd has the seams but not the implementation: receive_order stores an order and sets STATE_EXECUTING; complete_order and report_stuck flip the state; perceive_sight / perceive_hearing build a knowledge entry and hand it upward; die marks the NPC dead and clears its order. There is no movement, no navmesh, no real sensing, and no arrival condition — an order never completes on its own.

What changes

Build the execution layer, in order:

Execution state machine. The states exist as constants (idle, executing, done, stuck). Define the transitions: what moves executing to done — arrival within a threshold? interaction complete? target lost? What moves it to stuck, and what does the brain do then — retry once, repath, or report immediately? The Commander re-plans on stuck; the brain must not spin forever.
Movement via navmesh. A move_to order produces a navmesh path and the NPC follows it. Needs a test scene with a navmesh — the simulation-scenarios issue provides the scenes; this issue defines what the brain needs from them. Repath when the path is blocked; report stuck when no path exists.
Stuck detection and recovery. No progress for N seconds means stuck. Define N, define the recovery (repath once, then report), and make sure a stuck NPC never blocks its Commander from re-tasking it.
Sensing: what counts as noticing. Sight (range, cone, line of sight — what breaks it: darkness, cover, the Quiet?) and hearing (radius, what makes a sound — gunshots, shouts, footsteps?). A perception produces a knowledge entry only when the notice threshold is met; below it, nothing is reported upward. "Finds the body" needs its own conditions: distance, line of sight, time spent near the body — an NPC walking past a corpse in the dark must not automatically know.
Per-NPC-type behaviour. A fox, light infantry, and a heavy gunner move differently — or do they? Decide whether types get different brains or the same brain with different parameters (speed, sight range, hearing). Same brain with parameters is the default assumption; a second brain needs a reason recorded here.
Tests. An NPC executes move_to across a navmesh scene and completes; a blocked NPC reports stuck; a target outside sight rules produces no entry; a body is "found" only under the settled conditions.

What done looks like

An NPC walks a move_to to completion, reports stuck when it cannot, perceives only what its sensing rules allow, and finds bodies only under the settled conditions — each proven by a test. The order-execution states transition per the settled machine, and the design doc's small-brain section matches the implementation.

Open questions

How does the brain know it arrived — a distance threshold, and what value?
Stuck timeout: how many seconds of no progress before reporting?
Different brains per NPC type, or one brain with parameters?
What does interact execute as — walk to, then a channel? What interrupts it?
What breaks line of sight — darkness, cover, fog, the Quiet?

## The plan The NPCEntity small brain is execution only: it takes an order and figures out HOW to carry it out — navmesh pathing, line-of-sight checks, stuck handling, basic logic. It never decides what to do. This issue builds the HOW. It depends on the order-vocabulary issue: the brain executes the settled vocabulary, and no order type gets built here that the vocabulary does not contain. ## Current state `addons/daisy/src/npc_entity.gd` has the seams but not the implementation: `receive_order` stores an order and sets `STATE_EXECUTING`; `complete_order` and `report_stuck` flip the state; `perceive_sight` / `perceive_hearing` build a knowledge entry and hand it upward; `die` marks the NPC dead and clears its order. There is no movement, no navmesh, no real sensing, and no arrival condition — an order never completes on its own. ## What changes Build the execution layer, in order: 1. **Execution state machine.** The states exist as constants (`idle`, `executing`, `done`, `stuck`). Define the transitions: what moves `executing` to `done` — arrival within a threshold? interaction complete? target lost? What moves it to `stuck`, and what does the brain do then — retry once, repath, or report immediately? The Commander re-plans on `stuck`; the brain must not spin forever. 2. **Movement via navmesh.** A `move_to` order produces a navmesh path and the NPC follows it. Needs a test scene with a navmesh — the simulation-scenarios issue provides the scenes; this issue defines what the brain needs from them. Repath when the path is blocked; report stuck when no path exists. 3. **Stuck detection and recovery.** No progress for N seconds means stuck. Define N, define the recovery (repath once, then report), and make sure a stuck NPC never blocks its Commander from re-tasking it. 4. **Sensing: what counts as noticing.** Sight (range, cone, line of sight — what breaks it: darkness, cover, the Quiet?) and hearing (radius, what makes a sound — gunshots, shouts, footsteps?). A perception produces a knowledge entry only when the notice threshold is met; below it, nothing is reported upward. "Finds the body" needs its own conditions: distance, line of sight, time spent near the body — an NPC walking past a corpse in the dark must not automatically know. 5. **Per-NPC-type behaviour.** A fox, light infantry, and a heavy gunner move differently — or do they? Decide whether types get different brains or the same brain with different parameters (speed, sight range, hearing). Same brain with parameters is the default assumption; a second brain needs a reason recorded here. 6. **Tests.** An NPC executes `move_to` across a navmesh scene and completes; a blocked NPC reports stuck; a target outside sight rules produces no entry; a body is "found" only under the settled conditions. ## What done looks like An NPC walks a `move_to` to completion, reports stuck when it cannot, perceives only what its sensing rules allow, and finds bodies only under the settled conditions — each proven by a test. The order-execution states transition per the settled machine, and the design doc's small-brain section matches the implementation. ## Open questions - How does the brain know it arrived — a distance threshold, and what value? - Stuck timeout: how many seconds of no progress before reporting? - Different brains per NPC type, or one brain with parameters? - What does `interact` execute as — walk to, then a channel? What interrupts it? - What breaks line of sight — darkness, cover, fog, the Quiet?

muse-lantern referenced this issue

2026-11-15 01:10:25 +00:00

Build sequence: code first, then model integration #11

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

dead-air/daisy#4

No description provided.

Rows
Columns