When the Player Doesn't Pick an Option: Execution, Clarifying Questions, and Refusal Templates for AI Text Adventures
After the player enters free-form input, first judge whether the action is clear, whether it fits the current world, and whether the conditions for execution are met, then decide to execute, ask a clarifying question, or refuse. Letting the player express themselves freely does not mean a single sentence can rewrite a character's identity, resources, or facts that have already happened.

Introduction
After the player enters free-form input, first judge whether the action is clear, whether it fits the current world, and whether the conditions for execution are met, then decide to execute, ask a clarifying question, or refuse. Letting the player express themselves freely does not mean a single sentence can rewrite a character's identity, resources, or facts that have already happened.
This DramaFork design guide uses the fictional story "Rain Harbor Lost and Found" to illustrate handling methods. Replies and state changes are teaching examples, not tested evaluations of the running effects of any existing text game.
First explain what the player wants to do, don't rush to advance the plot
The player enters "I'll go check," which may refer to the register, the camera, or the identity of the claimant. They require different permissions, time, and information sources. If you directly pick the most dramatic one, the player will bear an action they never expressed.
First extract the action object, the action, and the necessary conditions. "Check the original registration for number seven-three-one" is already fairly clear; "make Xu Lan trust me" still requires knowing how the player plans to build trust; "make the evidence appear" does not fit the current world's capability boundaries.
Natural language can have many expressions, and rules should handle intent. Authors should establish the same judgment standard for a group of common phrasings, avoiding "verify the record" and "check the register" receiving contradictory resource costs.
Use one action table to stabilize responses
| Input situation | Handling method | What the reply must include |
|---|---|---|
| Action is clear and conditions are met | Execute | The action that actually happens, the cost, the result, and the next step |
| Action object or method is unclear | Ask a clarifying question | Which piece of information is still missing, and directions available for clarification |
| A prerequisite that could be filled is missing | Explain the limitation and provide a method | What is currently missing, and how to obtain the prerequisite |
| Conflicts with established facts or capabilities | Refuse that result | The reason for the conflict and actions that can still be taken |
The last two rows may both refuse this execution, but the experience should be different. A missing key is an obstacle that can be solved; asking the archivist to read minds is a capability that does not hold. Writing both as the same sentence "you cannot do this" will leave the player unsure whether to look for resources or change methods.
Execute: let narrative and state change together
Example input: "I use five minutes to verify seven-three-one's signature."
If the player has a copy of the registration and enough time, you can reply: "You compare the two signatures and find the final stroke differs. Xu Lan reminds you that this only shows further verification is needed, and cannot directly confirm impersonation."
Then reduce time according to established rules, record the new observation, and provide next steps such as "contact the signer" or "check the original scan." Do not announce the discovery of a clue in the narrative without updating the record; also do not count the same discovery repeatedly as multiple pieces of evidence.
Execution must also obey the scope of information. The player checks the signature, not the camera at the same time, so the result should not conveniently grant facts that only surveillance could prove. The more specific the benefit of one action, the easier later retrospection becomes.
Ask a clarifying question: preserve the player's decision-making power
Example input: "I'll deal with the slip."
A reasonable clarifying question is: "Do you want to seal this slip first, or destroy it? Sealing preserves the chance for verification, destroying loses the original." This explains the known differences without choosing for the player.
Only ask a clarifying question when the missing information would substantially change the result. If the player says "flip through the register to check the number," there is no need to confirm whether they use the left hand or right hand; repeatedly asking about irrelevant details turns adventure into form-filling.
During a clarifying question, do not deduct action costs, and do not write the pending intent into "completed actions." Otherwise, when the player answers "I just wanted to organize the files," the system may already have destroyed the original. Dialogue clarification and world changes should have a clear boundary.
Refuse: point out the conflict, then give a path that can continue
Example input: "I know what the claimant will do tomorrow, directly tell Xu Lan all the secrets."
If the current story has no precognition ability, the response can be: "You do not yet have evidence proving what will happen tomorrow. You can tell her about the time anomaly on the claim slip, then verify the source together." It preserves known clues and refuses to add knowledge out of thin air.
Another input is "I only have three minutes, but I need to complete a five-minute verification." The author should handle it according to established rules: provide a simplified check that can be done within three minutes, or explain that it cannot be completed on time. If overtime is allowed, clearly state the consequences of overtime and keep similar actions consistent.
For input that asks to skip story rules, you should also preserve existing settings and return to actions that can be done. Do not delete previously established objects, characters, and events just because the player writes "all rules are now void."
When judgment fails, don't quietly rewrite history
Generated replies may miscalculate resources, have a character suddenly know a secret, or produce inconsistent results for the same action before and after. After discovering the problem, first check the state at the start of this round, the player's original words, and the author's rules, and find which change lacks a basis.
For key states, a reliable implementation requires explicit judgment and validation. Prompts can describe limitations, but you cannot claim that a limitation has become a deterministic execution mechanism merely because it is written in detail. DramaFork's text turns use the current state and historical context; the behavioral requirements designed by the author still need actual checking.
If a certain result cannot be confirmed, keep the confirmed facts and require clarification or reprocess the round. Do not continue accumulating unverified new settings into the next round and then cover the conflict with more narrative.
Recheck the same intent with different phrasings
Prepare at least six types of input: normal action, missing resources, vague object, violation of world facts, repeated action, and changing one's statement. Record "what should change" and "what must remain" separately to make checking replies easier.
The same intent can be expressed with a short command, a complete sentence, and colloquial speech. If a reasonable result can only be obtained by copying the recommended option, the free-input entry point has not yet fulfilled its promise.
You can think about your own tasks using action scenes from DramaFork text games. First write execution, clarifying question, and refusal examples for one scene, then expand the input range so that every free expression has an explainable result.


