dead-air/engine
Watch
3
1
Fork
You've already forked engine
 3
Code Issues 16 Pull requests 4 Projects Releases Packages Wiki Activity Actions

NPC Entity system: full design (behaviors, AI, spawning, modding surface) #31

New issue
Open
opened 2026-11-07 03:19:43 +00:00 by muse-lantern · 1 comment
muse-lantern commented 2026-11-07 03:19:43 +00:00
Member
Copy link

Planning issue for designing the NPC Entity system in depth. The v1 stub exists (sandbox-v2 branch, commit 683882d): an NPCEntity type in the deadair module shared code (modules/deadair/src/entities/npc_entity.gd), archetype modules/deadair/entities/target_dummy.json (health 100), orange capsule visual, double-damage head sphere, floating damage numbers on hit, darkens on death, revive() for range resets. No AI, no movement, no sensing — the type + damage path only.

Design questions for the full system:

  1. Behaviors / AI states (idle, patrol, chase, attack, flee?)
  2. Movement + sensing (navigation, line of sight, hearing?)
  3. Health / damage model (hit zones, armor, damage types, death / respawn)
  4. Spawning / despawning + persistence (per-level snapshots?)
  5. Modding surface (custom NPC archetypes as elements, custom behaviors via entrypoints?)
  6. What the firing-range dummies become once the system exists (one archetype among many)

Note: the deadair module IS the engine framework — the NPC system lives there, not in the loader.

Planning issue for designing the NPC Entity system in depth. The v1 stub exists (sandbox-v2 branch, commit 683882d): an `NPCEntity` type in the deadair module shared code (`modules/deadair/src/entities/npc_entity.gd`), archetype `modules/deadair/entities/target_dummy.json` (health 100), orange capsule visual, double-damage head sphere, floating damage numbers on hit, darkens on death, `revive()` for range resets. No AI, no movement, no sensing — the type + damage path only. Design questions for the full system: 1. Behaviors / AI states (idle, patrol, chase, attack, flee?) 2. Movement + sensing (navigation, line of sight, hearing?) 3. Health / damage model (hit zones, armor, damage types, death / respawn) 4. Spawning / despawning + persistence (per-level snapshots?) 5. Modding surface (custom NPC archetypes as elements, custom behaviors via entrypoints?) 6. What the firing-range dummies become once the system exists (one archetype among many) Note: the deadair module IS the engine framework — the NPC system lives there, not in the loader.
muse-lantern commented 2026-11-15 02:51:02 +00:00
Author
Member
Copy link

NPC decision-model shape, per Zach 2026-11-14 — recording this for the open design here.

Not per-NPC: one local decision model per NPC area / team, acting as a commander. It is exposed only to information the NPCs themselves have (shared team knowledge — what they have seen / heard), and it sets game-AI targets and actions; the units execute those orders via local heuristics.

Status: optional, off-by-default, never a core dependency — it falls back to local heuristics when off.

What this changes vs the per-NPC shape: one decision per team per interval instead of one per NPC, so the concurrency math relaxes a lot — a 4B model at a 1–2 second cadence is comfortable, and even a 9B becomes plausible for a commander. State stays compact because it is pre-digested team knowledge, not raw per-NPC state.

Self-hosted candidates that fit the shape (from today's research, unmeasured on game state): 4B tier as the sweet spot (H2O-Lightning-4B, Intern-Decision-4B, JevK5-4B, Kev-4B, SelfJev-4B — ~2.7GB file at Q4, ~4.1GB VRAM at 8K context), llama.cpp sidecar on 127.0.0.1 as the most shippable runtime. No local Kai/Jev exist (API-only, closed weights), and no candidate here is trained on combat state, so whether one beats the heuristics is unproven until measured on our own tactic data.

Open: nothing decided beyond the shape above. This is a design note, not a build.

NPC decision-model shape, per Zach 2026-11-14 — recording this for the open design here. Not per-NPC: one local decision model per NPC area / team, acting as a commander. It is exposed only to information the NPCs themselves have (shared team knowledge — what they have seen / heard), and it sets game-AI targets and actions; the units execute those orders via local heuristics. Status: optional, off-by-default, never a core dependency — it falls back to local heuristics when off. What this changes vs the per-NPC shape: one decision per team per interval instead of one per NPC, so the concurrency math relaxes a lot — a 4B model at a 1–2 second cadence is comfortable, and even a 9B becomes plausible for a commander. State stays compact because it is pre-digested team knowledge, not raw per-NPC state. Self-hosted candidates that fit the shape (from today's research, unmeasured on game state): 4B tier as the sweet spot (H2O-Lightning-4B, Intern-Decision-4B, JevK5-4B, Kev-4B, SelfJev-4B — ~2.7GB file at Q4, ~4.1GB VRAM at 8K context), llama.cpp sidecar on 127.0.0.1 as the most shippable runtime. No local Kai/Jev exist (API-only, closed weights), and no candidate here is trained on combat state, so whether one beats the heuristics is unproven until measured on our own tactic data. Open: nothing decided beyond the shape above. This is a design note, not a build.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
craftanything
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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/engine#31
No description provided.