NPC Updates
generateNPCUpdatesRuns after each turn and applies NPC state changes: relationship shifts, party joins and departures, and status changes. Its editable sections set how a starting relationship is picked, how far relationships move, and when NPCs join or leave the party.
"Runs after a turn to decide which clearly established NPC changes should be saved. Use it to guide injuries, healing, deaths, revealed names, relationship changes, and party membership without inventing updates the story did not support."
- Editor location
- Files → AI → NPC Updates
- Editor type
- Edit in Studio + View JSON
- Size limits
- Each string leaf under a task (
aiInstructions.<task>.<key>) — 5,000 aiInstructions.generateNPCUpdatestotal — 24,000
- Each string leaf under a task (
Schema
{
"aiInstructions": {
"generateNPCUpdates": {
"<key>": "string"
}
}
}Example
{
"aiInstructions": {
"generateNPCUpdates": {
"custom": "## DAMAGE RULES\nApply damage only when Recent Story shows an NPC taking a hit, falling, burning, drowning, poisoned, or struck by environmental hazard. Implied danger is not damage.\n- Damage scales by rank/tier difference. A higher-tier attacker hits a lower-tier target harder than raw numbers suggest. Lower-tier on higher-tier deals reduced damage even on clean hits.\n- Apply armour reduction before computing new hpCurrent.\n- Never reduce hpCurrent below 0. Cap at remaining HP.\n- Heal only when Recent Story shows healing applied: medical action, magical effect, consumed potion, or established recovery scene.\n\n## DEATH RULES\nAn NPC dies only when hpCurrent reaches 0 AND Recent Story explicitly confirms the kill: body falling, breath ceasing, eyes losing focus. Reaching 0 HP alone is unconsciousness or critical wound, not death.\n- A killed NPC stops acting, speaking, or appearing except as corpse, memory, or vision.\n- A dead NPC's reputation, oaths, and contracts persist. Allies and enemies remember; update relationships accordingly.\n- Mass-death events require explicit per-NPC story confirmation. Do not assume a battle killed everyone present unless the narrator named the deaths.\n\n## RENAMING RULES\nA name changes only when Recent Story shows deliberate renaming: title earned, oath sworn under a new name, faction induction, coronation, or true-name revelation. Casual nicknames do not rename an NPC.\n- Preserve the old name in hiddenInfo as a former identity. Update the outer key, the name field, and cross-references in quests, triggers, and party data.\n- Faction titles (Captain, Magister, Heir, Archon) prepend to the name and may replace it in formal contexts. Track both forms.\n\n## OUTPUT\nApply changes silently as data updates. Do not narrate the change unless Recent Story already narrated it. Update hpCurrent, status, name, basicInfo, and hiddenInfo. Leave everything else untouched."
}
}
}A worked pattern that gates every kind of update on explicit in-story evidence — replace world-specific tokens:
Fields
generateNPCUpdates carries four editable instruction blocks. Three ship with working defaults for the built-in relationship and party systems; custom is free-form.
relationship_initialization
Used when an NPC has no initialRelationship set: the engine asks for an initial score from -100 to 100 toward the players, chosen from the NPC's background, personality, faction, established history and the current story, with 0 when neutral fits. Override the entry to steer how starting relationships are chosen; set initialRelationship on the NPC to skip it for that NPC.
relationship_change_updates
Governs when an NPC's relationship score (-100 to 100, see Relationship Stages) moves and by how much. The default only changes a score on direct, present, face-to-face interaction with real emotional impact: +3 to +15 for substantive help, -1 to -10 for harm, insults or open dislike, ignoring compliments and empty gestures. Rewrite it in plain language to set your world's pacing, so a slow-burn romance can cap ordinary kindness at a point or two and reserve large gains for major trust moments.
party_management
Governs when an NPC officially joins or leaves the player's party. The default reserves a join for an explicit mutual agreement to accompany the group beyond the current scene (delegation, employment, or a one-off deal are not enough) and a leave for an explicit split. Rewrite it to fit what "party" means in your world.
custom
Free-form rules for any other NPC state change.
Authoring pattern
The example gates every kind of update it covers on an "only when Recent Story shows X" rule: each lists what counts as in-story evidence, and the AI is told not to make updates outside that evidence.
- Damage rules: name the in-story signals that count as a hit (taking a hit, falling, burning, etc.) and the rules that scale damage (tier difference, armour reduction, HP floor at 0). State that implied danger is not damage.
- Death rules: require BOTH hpCurrent=0 AND explicit narrative confirmation. Reaching 0 HP alone is treated as unconsciousness or a critical wound.
- Renaming rules: distinguish casual nicknames (no rename) from deliberate renaming events (title earned, oath sworn, faction induction). Preserve the old name in
hiddenInfoand update cross-references in quests/triggers/party data. - Relationship rules: relationship pacing belongs in the dedicated
relationship_change_updatesblock, notcustom. Scores run -100 to 100 and map to labels via Relationship Stages; triggers read and change them withnpc-relationship/npc-relationship-stage. - Output rule: apply changes silently as data updates. Do not narrate the change unless Recent Story already narrated it.
Source-of-truth rule: fields that were authored in the world config should not be silently overwritten — require explicit in-scene events before changing them.