Workshop briefs for the larger spikes identified by the architecture review audit: knowledge graph & information boundaries, observer snapshot pipeline, NPC AI state machines, save/load architecture, and map authoring pipeline. Each includes participants, key questions, input documents, and expected outputs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4.6 KiB
NPC AI State Machines Workshop Brief
Goal: Specify the 4 Background-tier state machines (schedule, mood, relationships, job) — states, transitions, day phase integration, and tick budgets. Ticket: #353 (epic) Priority: HIGH — Sprint 3 target Participants: Gestalt (mechanics lead), Paula (narrative), Dudley (implementation), Tyre (architecture), Nigel (emergent play), Qatux (docs), Si (tickets) Source: Architecture Review Audit 2026-02-11, Tyre R-06
Context
D-026 defines four simulation tiers. Background-tier NPCs (500-2,000) run "state machine ticks" at 1/game-minute frequency. D-026 mentions "4 state machines: schedule, mood, relationships, job" but provides no specification of states, transitions, or interactions.
The NPC component model (D-024, server/src/npc/mod.rs) defines 10 axes including DailyRoutine, MoodState, RelationshipWeb, and Occupation — but these are type stubs without behavior logic.
This workshop must produce state machine specifications that are:
- Implementable — Clear states and transition rules Dudley can code
- Interesting — State interactions that produce emergent NPC behavior (Gestalt, Nigel)
- Narratively grounded — State changes that create observable drama (Paula)
- Performant — Within the 1/game-minute update budget for 500+ NPCs (Tyre)
Key Questions to Resolve
Schedule FSM
- What are the schedule states? (work, home, social, sleep, commute, errand?)
- How do day phases (D-031: morning, afternoon, evening, night) drive transitions?
- How do schedules vary by NPC type? (worker, socialite, loner, authority figure)
- What makes an NPC deviate from their routine? (Events, mood, relationship pressure)
Mood FSM
- What are the mood states? (calm, stressed, suspicious, friendly, hostile, afraid?)
- What events trigger mood transitions? (Observation, confrontation, social pressure)
- How does mood affect schedule? (Stressed NPC skips social time? Suspicious NPC changes route?)
- How does mood affect dialogue access? (D-028 tag system integration)
Relationship FSM
- What are the relationship states? (stranger, acquaintance, friend, ally, rival, enemy?)
- How do relationships change? (Repeated interaction, shared knowledge, betrayal, trust)
- How do social triangles (D-024) create relationship pressure?
- How does Q-017 (triangle pressure threshold) feed into relationship transitions?
Job FSM
- What are the job states? (idle, working, break, commute, off-duty?)
- How does job interact with schedule? (Job state constrains schedule options)
- How do different occupations (dock worker, security, merchant, bureaucrat) vary?
- How does job state affect what the NPC knows? (Location access, information exposure)
Cross-Machine Interactions
- How do the 4 machines communicate? (Shared blackboard? Event bus? Direct reads?)
- What's the priority when machines conflict? (Mood says "flee" but schedule says "work")
- How do Active-tier NPCs differ from Background-tier? (Full AI vs state machine only)
- How does tier transition preserve state? (Active NPC drops to Background — which state is kept?)
Input Documents
| Document | What to read | Why |
|---|---|---|
decisions/architecture.md |
D-026 (simulation tiers), D-031 (time/day phases) | Tier and timing constraints |
decisions/scope.md |
D-024 (NPC model), D-025 (social sites) | NPC components and locations |
decisions/content.md |
D-028 (tagged line pools), D-034 (THE FRIEND) | Content dependencies |
decisions/questions.md |
Q-016, Q-017 | Open questions about knowledge hierarchy and triangle pressure |
server/src/npc/mod.rs |
Current component stubs | What exists today |
server/src/simulation/tier.rs |
Tier system stub | Where tier logic lives |
Expected Outputs
- Decision: D-0XX — NPC State Machine Specification — States, transitions, and interaction rules for all 4 machines
- Decision: Resolution of Q-017 — Triangle pressure threshold mechanics
- State diagram: Visual state machines for each FSM (can be Mermaid diagrams)
- Transition tables: For each FSM, a table of (current_state, event) -> new_state
- Performance budget: Per-NPC update cost at Background tier frequency
- Tickets: Implementation tasks for each FSM + cross-machine integration
Workshop Format
Two rounds:
- Round 1: Each participant designs the machines from their domain (Gestalt: mechanics, Paula: narrative weight, Nigel: emergent play, Tyre: performance, Dudley: implementation feasibility)
- Round 2: Cross-review and reconcile — especially where mechanics vs narrative vs performance conflict