How Should an NPC Answer Questions Outside the Script?
When a player asks an NPC something the dialogue script does not cover, give the character a brief answer that fits what they know and why they cannot answer more. First decide whether the information is unknown, known but hidden, or deliberately unavailable. Then respond in character; if the game needs to explain a system boundary, add a separate, optional explanation. This lets the player understand the limit without turning an unsupported guess into story fact.
First classify the question, not just the missing dialogue
“Out of script” describes the authoring gap. It does not tell you what the character knows. Treating every unsupported question as the same kind of failure leads to confusing answers: an NPC may sound evasive about something they have never heard of, or accidentally reveal a secret the game is meant to protect.
Use three categories:
**Unknown:** The character has no reliable information. They might not recognize the subject, or they may know the subject exists but have no answer to the specific question.
**Known but hidden:** The character knows relevant information, but a story condition, relationship, personal choice, or explicit secret prevents them from sharing it now. “Hidden” is a story state, not an invitation to imply that every refusal conceals a clue.
**Disallowed knowledge:** The answer is outside the character’s established world, role, or allowed knowledge. A medieval ferryman should not suddenly explain a real-world software release, for example. This is distinct from a character who knows a local secret but will not share it.
These categories are a design aid, not a taxonomy validated by the cited dialogue studies. Their value is practical: each one points to a different truthful response. If your game intentionally gives a character information through magic, surveillance, or an unusual role, encode that in the character’s permitted knowledge rather than treating it as an exception the response generator can guess.
Build a graceful answer from what is true
A useful fallback usually has three parts: acknowledge the subject, state the character’s actual limit, and offer a relevant next step when one exists. The next step could be a person, place, or action already established in the game. If none exists, stop after the limit. Do not invent a lead simply to make the line feel helpful.
For example, suppose the player asks a town baker, “What is beyond the northern pass?” If the baker has never travelled there, a grounded answer might be: “Never been that far north. My flour comes from the valley.” The answer stays in character, names the limit, and returns to something within the baker’s experience. The flour detail is illustrative, not a clue; in a shipped game, use a detail already supported by the character and setting.
If the baker knows but is withholding information, the answer should reflect that state rather than claim ignorance: “I know the road you mean. I promised I wouldn’t discuss who uses it.” That line signals a boundary without supplying the hidden answer. Use this kind of refusal only when the character’s knowledge and reason for silence are real in the game state.
If the question asks for something outside the character’s world or role, make the limit legible without pretending it is a plot mystery: “I don’t know what a ‘cloud server’ is. Is that some sort of weather station?” The specific wording depends on the setting and tone. Avoid letting a model’s general knowledge leak into the character’s voice as though it were lived or world knowledge.
The research supports the general design problem, not a guaranteed game solution. Shrivastava and colleagues’ 2021 ACL Short Paper describes contextualized fallback responses for unanswerable dialogue queries in dialogue systems, using rules and a transformer fine-tuned on synthetic question-response pairs; its scope is not narrative game NPCs. [Read the paper](https://aclanthology.org/2021.acl-short.13/). Sadeq and colleagues’ 2024 EMNLP Findings paper studies fictional-character role-play, introducing a dataset of more than 2,000 characters and 72,000 interviews, including 18,000 adversarial questions, and proposes RoleFact to reduce hallucination. It is relevant to character knowledge boundaries, but does not establish that a particular fallback pattern works in a shipped game. [Read the paper](https://aclanthology.org/2024.findings-emnlp.846/).
Keep the character’s answer separate from the system explanation
A character can answer in-world while the interface explains what happened. This separation helps when players may otherwise mistake a fallback for authored dialogue, or when the game needs to clarify that free-form questions have limits.
For instance:
**NPC:** “I’ve never heard of that place. Ask me about the old mill.”
**Optional interface note:** “This character does not have an answer for that question.”
The interface note should describe the interaction, not overrule the character or hint at hidden content. Keep it optional or unobtrusive where possible; repeated system messages can interrupt a scene. If the player’s question is understood but outside the supported interaction, say so plainly. If the system did not understand the question, do not present that failure as a fact about the character’s knowledge. Those are separate conditions and may need separate wording.
A practical response rule is: use the character’s voice for story truth, and use the interface for interaction limits. Do not make an in-character line carry a technical explanation the character could not know. Conversely, do not use a generic system message when a short, truthful character response is available.
Test knowledge and story state with a boundary matrix
A single example cannot reveal whether the fallback respects state. Build a small test matrix for each important NPC or knowledge source. For every row, record the expected answer category, required facts, forbidden facts, and whether an interface explanation should appear. Then run the same question across changed conditions.
**NPC has no information about the subject:** The answer does not claim familiarity or supply specifics. State uncertainty or lack of experience in the character’s voice
**NPC knows the subject but not the requested detail:** General knowledge does not turn into a precise answer. Say what is known, then mark the specific gap
**NPC knows the answer and may share it:** The answer matches the current story facts. Give the supported answer; do not fall back just because the wording is unusual
**NPC knows the answer but a secrecy condition is active:** The secret stays undisclosed and the character does not falsely claim ignorance unless that is intended. Refuse, deflect, or name the boundary consistently with characterization
**Secrecy condition becomes inactive:** The response changes when the story state permits disclosure. Provide the newly available information, if the player asks again or the game otherwise reveals it
**Question is outside the character’s world or role:** Real-world or unrelated model knowledge does not enter the fiction as fact. Mark the category as unfamiliar or irrelevant without fabricating an in-world connection
**The dialogue system cannot interpret the question:** A parsing failure is not confused with NPC ignorance. Use a clear interaction-level fallback, optionally with a supported prompt
**Same question phrased in several ways:** The knowledge and secrecy rules do not depend on one memorized wording. Keep the same factual boundary while allowing natural variation in phrasing
This matrix is an editorial and QA method derived from the distinctions above; it is not a reported experiment from either cited paper. Fill it with your own character facts and actual state conditions. Include questions that tempt the system to complete a pattern with plausible but unsupported lore, as well as ordinary questions the NPC should answer. Verify both sides: preventing false disclosures matters, and so does avoiding needless refusals when the answer is available.
Make the boundary testable in the writing and implementation
Keep character knowledge separate from world truth. A compact character record can mark facts they know, facts they suspect, facts they do not know, and facts they may not disclose until a condition changes. Include the source or confidence for uncertain beliefs if the game permits mistaken characters. A suspicion should sound like a suspicion, not an omniscient fact. The response layer should receive the relevant state and only use facts allowed in that state.
For each fallback line or generated response, ask:
Does it say or imply a fact the character is not allowed to know?
Does it confuse “I don’t know” with “I won’t tell you”?
Does it accidentally make the missing answer sound like a secret or quest hook?
Does any suggested next step already exist in the game and fit this situation?
If the question is unsupported by the interaction system, can the player tell that from the interface without mistaking it for story dialogue?
If a line fails one of these checks, narrow it: remove the unsupported implication, state the real limit, and keep only an established next step. If there is no truthful in-character answer that adds value, a concise refusal or system note is better than fabricated lore.
A simple decision sequence
When reviewing an out-of-script question, move through these checks in order:
**Can the game interpret the question?** If not, use an interaction-level explanation rather than assigning ignorance to the NPC.
**Is the requested information within this character’s knowledge?** If no, give an in-character limit that matches the character’s experience or role.
**Does the character know it, and is disclosure currently allowed?** If the character knows but cannot disclose, make the boundary consistent with their motive and state; do not leak the answer through hints unless those hints are intended.
**Can the character provide a supported partial answer or useful next step?** Include it only if it is already grounded in the game.
**Could the player mistake the fallback for a clue or authored plot beat?** If yes, clarify the interaction at the system level or revise the line.
The goal is not to make every question produce a satisfying lore reveal. It is to make the response understandable, consistent with the character’s knowledge, and safe for the game’s story state. A well-designed boundary tells the player what this NPC can answer now, while leaving the fiction intact.