Executive Recommendation

Full report

On this page

Design each NPC as a self-contained agent that obeys the same movement and puzzle rules as players. Use a state machine and simple rules to drive movement decisions, rather than calling an AI model every time. In practice, an NPC remains authoritatively located at some map node at all times, but may be “dormant” (inactive) until needed. Active NPCs in a room update frequently; NPCs offscreen (in empty rooms) update rarely or not at all. NPCs should only move by valid paths (using the game’s door-and-lock logic) with realistic travel time; they must not teleport or bypass locked puzzles. Invitations (player requests by exact name) or timers trigger movement. Each NPC should stay idle for a brief period after arriving to avoid oscillation. Locked doors act as impassable obstacles: an NPC encountering a lock should give up or choose a different route rather than auto-solve puzzles. When all humans leave a room, NPCs in it quietly go idle or eventually depart to a default location, but no AI model calls are made while fully unobserved. Conversations (and any model-driven text generation) only occur when a human is present and addresses the NPC.

Overall, a lightweight, deterministic logic (e.g. a simple behavior tree or rule list) can govern NPC roaming and responses. This ensures predictability and avoids overuse of AI services. In later iterations, a language model could propose higher-level goals or dialogue intentions that are then validated by the game rules. But in all cases, NPCs’ actions and audit logs must not betray whether they are human-controlled or AI – treat them uniformly.

NPC State Machine

Model each NPC with a few discrete states and clear transitions:

• Dormant/Idle (offscreen) – NPC is in some room with no players present. They perform no active AI (no model calls). They may have an internal timer or flag for planned movement but otherwise stand still.
• Ready (idle with players around) – NPC is in a room with humans but not currently speaking. They can begin conversation if addressed or react to events.
• Moving/Traveling – NPC is en route from one location to another along a valid path. During this state, the game advances their position step-by-step (possibly hidden if offscreen).
• Waiting at Door – A sub-state if an NPC reaches a locked door: the NPC decides a response (e.g. wait, abandon, or ask for help).
• Engaged/Conversing – NPC is actively chatting or assisting in a room. After finishing, they return to Ready or Idle.

Transitions are triggered by events: e.g. a timer (roam interval expires), a player invite (NPC is summoned by name), or a state change (players enter/leave the room). For example: On invitation, NPC transitions from Idle/Dormant → Moving to the player’s room. Upon arrival, they transition to Ready/Engaged. After a pause or conversation, they may transition back to Idle or Moving as next destination. Behavior trees or priority rules can implement this: e.g. Selector nodes choose whether to honor an invite, complete a current task, or pick a roaming destination.

Movement Admission Rules & Timing

• Room Capacity: Enforce at most 6 active NPCs per room. If an NPC attempts to enter a room that already has 6 NPCs, they must wait or choose another room. (No cap on human count.)
• Entry/Exit Cooldown: After an NPC enters or leaves a room, impose a brief cooldown (e.g. 5–10 seconds) before any NPC can move again through that door. This prevents crowding and oscillation.
• Randomized Intervals: Each idle NPC should wait a randomized interval (e.g. 30–60 seconds) before considering a move. This spreads out movements.
• Trigger Events: In addition to timers, NPCs move when invited by a player. Invitations are only honored if the NPC is idle or not otherwise busy. If already traveling or engaged, they can acknowledge but delay.
• Locked Door Handling: If en route to a target and a door is locked, treat it as an impassable barrier. The NPC should not “solve” it – instead they may abort that move, wait (up to a limit), or pick a different destination. For example, after 10 seconds waiting at a locked door, the NPC abandons that goal. This avoids NPCs obtaining undue puzzle knowledge or halting gameplay.
• Pathfinding & Travel Time: Use the game’s normal pathfinding so that NPCs take realistic routes and time to travel. They cannot teleport. For audit, log departure and arrival times to reconstruct movement.

Numerical defaults (tunable per game pacing): e.g. NPC roam cooldown ≈ 45±15s, door-wait ≈ 10s, post-arrival idle ≈ 15s. Players are free to invite at any time, which overrides cooldowns (an invite is treated as highest priority event).

Example Scenarios

• Normal Route (Unlocked Path): Alice is in Library A and a 40-second idle timer expires. She selects “Garden B” as her next location. The door to B is unlocked. Alice transitions to Moving, pathfinding through the connecting hallway. Travel takes ~5 seconds. Alice enters Garden B (logging an “NPC_ENTER_ROOM” audit event). She pauses 15s to greet anyone. If a player addresses “Alice Coan,” she replies (entering Engaged) using conversation logic.
• Locked Route Encounter: Bob is in Foyer X and his timer says go to Study Y. He reaches the door and finds it locked (puzzle unsolved). Bob waits 10 seconds (Waiting at Door). No solution appears, so Bob aborts. He logs “NPC_WAITED_LOCKED_DOOR” then returns to idle, perhaps choosing a different location (e.g. Dining Room) on a new timer. He does not magically solve or pass through.
• No-Human Room (Dormancy): Carol ends up alone in Hall Z after players exit. In Idle/Dormant state, she makes no AI calls. After a longer delay (e.g. 60s), a simple behavior triggers: if she has a social goal, she might move toward where players usually gather (or return to an “entrance lobby” room). Alternatively, she stays put quietly. If another NPC wanders in (unlikely offscreen, but if pre-scheduled), Carol can acknowledge them. However, while fully isolated, Carol does not generate any new dialogue or actions (no model calls). She remains “authoritatively” in Hall Z in the save state until humans return or another trigger activates her.

Believability & Failure Modes (with Mitigations)

1. Teleportation Glitch: NPC instantly appears far from last location. Mitigation: Always require valid pathfinding. Log travel so players see gradual movement. (No “blink” jumps.)
2. Impossible Knowledge: NPC reacts to puzzle solutions they couldn’t know. Mitigation: NPCs learn only what the game state allows (they “see” doors open or puzzles solved only when present). Never allow AI to conjure unseen clues.
3. Crowd Oscillation: NPCs repeatedly swap rooms (A→B→A→…). Mitigation: Use entry cooldowns and require a minimum stay time. Once an NPC leaves a room, lock that door from re-entry for that NPC for some time (or require a new timer).
4. All NPCs Shadowing One Player: Every NPC follows the same player. Mitigation: Limit each NPC’s “interest” to one player at a time. If multiple players call an NPC, only one is honored; others see “busy.” Vary NPC destinations so they naturally divide across the space.
5. NPC Steals Puzzle Items: NPC picks up key or object needed for puzzle. Mitigation: Disallow NPCs from carrying unique puzzle items unless the game logic explicitly permits it. If an NPC has a “tool” inventory, ensure puzzle-critical objects are off-limits or return to place if moved.
6. Stuck at Locked Door (Deadlock): NPC waits forever at a lock. Mitigation: After a short wait (e.g. 10s), NPC abandons the route (with an audit event) and picks a different goal. This avoids indefinite stall.
7. Idle Desertion: NPC vanishes without explanation. Mitigation: Log a “NPC_EXIT_ROOM” event with reason (e.g. “no humans left”). If dormant, record their last known location. Upon players’ return, NPCs reappear at that location.
8. Surprise Offscreen Behavior: NPC does something offscreen (e.g. conversations between NPCs or unexplained disappearance of an object). Mitigation: Offscreen NPCs do minimal actions (no new conversations, no object manipulation). Any important offscreen change (like NPC moving) should generate an audit log entry so designers can trace it.
9. Overpowered NPC Puzzle Solving: NPC solves a puzzle too quickly by exploiting knowledge or resources. Mitigation: Generally, NPCs should not auto-solve puzzles unless explicitly scripted. If an NPC is meant to solve something, require it to possess appropriate in-game tools or clues and treat it as a normal solve. Otherwise, they should wait for players or hint system.
10. Behavior Predictability / Repetition: NPC follows a dull, fixed routine. Mitigation: Introduce randomized choices in schedule or destination selection so NPCs seem less “robotic.” For instance, if two target rooms are valid, pick randomly (with weighting). Use small randomness in timing and path (if alternatives exist) to avoid a perfect loop.

Each mitigation ensures NPCs remain believable and do not break game rules or immersion.

MVP (Deterministic) vs Model Enhancements

MVP (Cost-Free, Rule-Based): Implement NPC logic via finite state machines or behavior trees with fixed rules. For example, each NPC has a weekly “schedule” of target rooms (possibly random order) and simple transitions. Offscreen, no AI is run – the NPC’s next move is only calculated when triggered by a timer or event. This is fast and transparent. Minimal storage is needed (just location, next-timer). For dialogue, use canned responses or a simple script. This baseline requires no additional model/API costs.

Enhanced (Model-Assisted): As a second phase, one could use an AI model to propose NPC intentions or status. For example, a language model might generate “The NPC Alice is concerned about the locked Study” or suggest a new conversation hook. However, any model suggestion must be checked by the game. For instance, an AI might pick a destination, but the game must verify the path is legal and not locked. Other enhancements: NPCs could recall past events (via MemoryEndpoints) more richly in conversation, or use AI-driven sentiment to change behavior (e.g. become upset if ignored). Even with models, the movement rules above remain authoritative: an AI cannot simply say “teleport to room” or “open the door” without following game mechanics.

Notably, Sean Middleditch’s approach to offscreen NPCs applies here: update NPCs only as often as needed. In an MVP, “offscreen” means no updates at all (NPC state frozen), which is safe but less dynamic. The model-enhanced version might simulate offscreen plans at low fidelity (like scheduling an NPC to arrive at a room at a future time) but still without frequent computation.

Audit Trail Requirements

Log events whenever an NPC changes location or state (but never label them by controller). Useful audit events include:

• NPC_MOVED: Record NPC name, from-room, to-room, timestamp. (Always via a valid route.)
• NPC_ENTERED_ROOM / NPC_EXITED_ROOM: Specifically mark entry or exit, with reason (invited, scheduled move, returning, etc.).
• NPC_INVITED: When a player invites an NPC by name, log “NPC_INVITED” with NPC name, player name, and target room.
• NPC_WAITING_LOCKED_DOOR: If an NPC waits at a locked door, log door ID and how long waited.
• NPC_DESTINATION_CHANGED: When an NPC picks a new goal (e.g. after canceling a locked-route), log old and new targets.
• NPC_IDLE: Periodically (or on state change) log that NPC is idling in a room.
• NPC_CONVERSATION_START/END: (optional) Mark when NPC starts or ends talking, which can explain why they stayed.

Each event should state what happened and why (e.g. “arrived due to invitation by Player X” or “left – no players in room”). Crucially, logs should not indicate whether the NPC’s decisions were AI-driven; all actions must appear as innate NPC behavior. This audit will help developers trace an NPC’s path (“The audit shows Frank went from A→B at time T and waited at door until T+10s”) without revealing if Frank is a human or chatbot.

Sources: Standard game-AI practice favors behavior trees or similar rule-based controllers for NPCs, and the concept of AI Level-of-Detail suggests updating close/visible NPCs frequently while letting distant/offscreen ones update sparsely or not at all. These principles guided the above recommendations.