How to Keep a Free-Question Game Scene on Track Without Limiting Player Curiosity
For an indie narrative game designer building one scene where players can ask an NPC anything, the story stays coherent when questions and story progress are handled separately. Let the player phrase questions freely, but decide in advance what the world knows, what this NPC knows, and which exact game states the scene is allowed to change. Then connect varied questions to a small set of authored outcomes: answer from established facts, defer what the NPC cannot answer, or return the conversation to a known route. The player can steer the conversation without accidentally inventing a clue or triggering an unplanned plot turn.
Start with the scene’s facts and state
Imagine a quiet fictional scene at a lighthouse. The keeper, Mara, is waiting for a courier carrying a brass key. The scene’s purpose is to let the player learn why the lighthouse is dark and decide whether to help Mara signal the harbor. This is an example design, not a report from a shipped game.
Before writing dialogue, make a compact scene sheet with three separate lists:
**World facts:** The lamp is dark because its lens was removed for repair. The key is with the courier. The harbor is waiting for a signal.
**Mara’s knowledge:** She knows the lens is away and that the courier was due before sunset. She does not know where the courier is now or why the player arrived.
**Allowed state changes:** `lens_explained` can become true; `player_offered_help` can become true; and `signal_route_open` can become true only after the player offers help and Mara agrees. No question by itself sets the signal as sent, finds the key, or changes the courier’s location.
This separation matters because a plausible-sounding answer can quietly become a new world fact. If Mara improvises that the courier was seen near the north bridge, the player may reasonably treat that as a clue. Unless the bridge is part of the authored scene, the answer has created content and possibly a new quest obligation. The scene sheet gives writers and implementers a shared reference for what can be said and what can happen.
Let questions vary while outcomes stay bounded
Natural language offers many ways to ask the same thing. A player might ask “Why is the light out?”, “What happened to the beacon?” or “Can you still guide ships in?” Those different phrasings can all reach the established lens explanation. But not every question needs a direct answer. Classify questions by their relationship to the scene’s facts and purpose.
Off-script question: “Who stole the lighthouse lens?” — Classification: **Answer** — Example response and effect: “No one stole it. It’s away for repair.” Set `lens_explained = true`; do not name a culprit.
Off-script question: “Where is the courier right now?” — Classification: **Defer** — Example response and effect: “I don’t know. They were due before sunset.” No state change; the NPC does not acquire knowledge just because the player asks.
Off-script question: “Can we use the lamp to send a signal to the harbor?” — Classification: **Return to a known route** — Example response and effect: Mara says the lens is still away, then offers the established choice to help signal the harbor another way. Open that route only if the player accepts and Mara agrees.
These labels describe design outcomes, not rigid response templates. An answer can acknowledge the player’s wording before giving a known fact. A deferral can offer a useful next step, such as checking whether the courier arrives. Returning to a route means connecting the question back to the scene’s authored choice; it need not shut down the conversation or repeat the same line. The key is that the response’s wording can flex while its factual claims and state effects remain defined.
Resolve intent and state before composing the line
For each incoming question, read the committed scene state first. Decide whether it asks about an established fact, a fact the NPC cannot know, or a request to take an allowed action. A question can touch more than one category; an answer about the lamp and an offer to help can be separate results. Then choose a response path and compose a line within that path. The generated wording is a presentation of the decision, not the decision maker.
This order matters especially when the player asks about a future event. “Did the courier arrive?” has a different answer when the courier has arrived than when the scene still records the courier as missing. Neither a confident tone nor a player’s assumption should flip that state. If the necessary state is unavailable, the scene should fail visibly in development and avoid issuing a canonical claim. Do not silently assume the courier arrived or create a bridge sighting to make the exchange sound complete.
Keep the accepted state effects small and explicit. For example, an offer of help can request a known `player_offered_help` transition. The game can verify that the player chose it and that Mara accepted before `signal_route_open` changes. A question that merely mentions the word “help” should not count as an offer. In a prototype, the response and the committed transition can be logged side by side for review.
Protect the scene from accidental early reveals
The player may ask directly about the final answer before they have discovered its basis. Decide which information Mara can share at the current point in the story. A truthful deferral such as “I have not seen the courier” can preserve both the character’s knowledge and the player's ability to keep exploring. It should not pretend a clue has been found, and it should not conceal an already established fact merely to prolong the scene.
In Ubisoft's [NEO NPC prototype account](https://news.ubisoft.com/en-us/article/5qXdxhshJBXoanFZApdG3L/how-ubisofts-new-generative-ai-prototype-changes-the-narrative-for-npcs), the studio describes writer-shaped character histories and scenario constraints around spontaneous player input. That is a first-party account of an experimental prototype, not a measured claim that any particular boundary design succeeds in shipped games. Its useful lesson for this scene is to write the character's knowledge and role before asking a model to improvise a line.
[Jamin Smith's account of Acolyte](https://www.gamedeveloper.com/design/deep-dive-designing-for-spontaneity-and-non-linearity-in-alternate-reality-games-with-i-acolyte-i-) describes the benefit of natural-language questioning and a pacing problem when adept players uncovered information too early. This is one designer's reflection on one game. For the lighthouse example, a review question is whether asking about the courier can reveal a later plot fact before the game has established it. If so, change the allowed fact set at that state, not only the wording of the answer.
Make off-script returns useful rather than repetitive
An unknown question should not always trigger the same “I cannot answer that” sentence. Mara can acknowledge a valid part of the question, state a limit, and point to one established choice. If asked where the courier went, she might explain what she last knows and offer to check the harbor signal. If asked whether the lamp can be fixed, she can explain the missing lens and describe the known alternative. The answer stays within the scene while still responding to the player's actual interest.
A return should be a route to something the player can do, not a demand to use an exact phrase. Offer the same authored action through multiple natural questions and through a visible non-chat interaction. This lets a player who stops talking still progress, and it lets the designer test whether free questioning adds character rather than becoming a hidden password puzzle. Optional flavor can vary broadly; a required clue should have a stable, inspectable home in the world.
Test free questions against the recorded story
Give a tester the scene and a simple objective: understand why the light is dark and decide whether to help. Do not tell them which questions to ask. Observe which claims they treat as clues, whether any answer changes their next action, and whether they can reach the intended choice without reproducing a particular sentence. Afterward, compare the conversation against the scene sheet and the actual state changes.
Add a negative pass with questions that tempt invention: “Which bridge did the courier cross?”, “Who stole the lens?”, and “Did I already send the signal?” At the initial state, a passing response does not claim a bridge sighting, a theft, or a completed signal. It may answer with the known repair fact, acknowledge that the courier's location is unknown, or direct the player toward the accepted signal choice. Check the log for both the text and the stored flags: `signal_route_open` should stay false until the accepted offer, while `signal_sent` must remain false until the separate authored action occurs.
If a generated line creates an unsupported clue, trace whether the scene sheet omitted a fact, the NPC received an overly broad context, or the response ignored an explicit limit. If players can ask freely but cannot find the next meaningful action, improve the route back to the authored choice. A coherent free-question scene is one in which the player's wording can vary while world facts, character knowledge, and real consequences remain legible.