NPC Updates
generateNPCUpdatesFires when an existing NPC's state changes during play: damage, death, renaming, relationship score, and party membership. Ships with editable relationship-pacing and party-management defaults, and controls which fields change, how fast, and what in-scene evidence is required.
"NPC Updates Instructions"
- 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 three editable instruction blocks. Two ship with working defaults for the built-in relationship and party systems; the third is free-form.
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: positive for substantive help, negative for harm or insults, ignoring empty flattery. 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 everything else, damage, death, renaming, and any other NPC state change, each gated on explicit in-story evidence.
Authoring pattern
The dominant pattern across all four update kinds — damage, death, renaming, relationships — is the "only when Recent Story shows X" gate. Every kind of update lists what counts as in-story evidence, and the model is told not to invent updates outside that evidence. This is the strongest single defence against AI hallucination in the NPC state path.
- 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 unconsciousness or critical wound. This separation prevents the model from killing NPCs purely on math.
- 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 now lives 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.