Text Game Failure States: How to Tell a Setback from an Input or Delivery Problem
In a chat style text game, an unsuccessful turn does not always mean the player chose badly. The scene may have reached a valid fictional setback, the game may not support the wording, the character may lack the knowledge needed to act, or the message may have failed to arrive. These situations call for different feedback and different retry effects. Classify the cause first, then tell the player what changed and what can happen next.
Start by asking what failed
A practical first question is: did the game understand the intended action and resolve it in the fiction? If yes, the result may be a setback. If not, determine whether the issue is the input, the character’s information, or delivery by the system. This four-part distinction is a design aid inferred from how interactive fiction systems separate parsing, world rules, story flow, and undo behavior; it is not a universal technical standard. Inform’s documentation, for example, describes the parser and simulated world model as separate parts of a game, and its parser can report several different reasons why a command did not match. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Treat the message as part of the game’s response contract. It should answer three things: what happened, whether the fictional state changed, and what the player can do now. A short line such as “The paper boat tips over before reaching the far bank. The folded note is still in your hand. You can try a wider channel or choose another way across” makes the setback, retained item, and next step legible.
1. A valid fictional setback
A setback is appropriate when the game understood the action, checked it against the current scene, and intentionally produced an in-world consequence. Perhaps the player tries to carry too many library books at once and one slides onto a nearby chair. Perhaps a paper boat takes on water before it reaches the other side of a shallow stream. The outcome can be inconvenient or surprising without turning the exchange into a judgment of the player.
The defining feature is state change. If the scene says the boat sank, that outcome should be true in the story. If the player can recover it, explain how; if the boat is gone, do not imply that retrying the same text will undo that event. A retry could mean making another boat, selecting another route, or continuing from the changed scene. The exact option depends on the game’s rules.
A useful setback message names the attempted action, the consequence, and the available continuation. It should not dress a supported action up as an input error just because the result was unfavorable. Conversely, do not imply a consequence occurred if the game did not actually change the story state. That distinction lets the player understand whether they are continuing from a new situation or correcting an unprocessed command.
2. Unsupported input: the game could not resolve the wording
Unsupported input means the system cannot map the player’s message to an action it supports. The player might type “ask the baker about apricots” in a scene where the game only accepts a small set of button choices, or use a name the parser does not recognize. This says something about the interface’s coverage, not about the quality of the player’s idea.
Interactive fiction parsers illustrate why useful feedback should be specific: Inform lists separate errors for an unrecognized verb, an unclear reference, too little input, and an object that cannot be seen. Its manual also shows how a game can replace a generic parser error with a more informative message. (Inform 7 §18.35: Printing a parser error) In a chat game, a concise response might be: “I can’t resolve ‘ask about apricots’ here. You can ask about the delivery or choose a topic from the counter.”
Offer a repair route. Depending on the interface, that could mean showing recognized choices, asking one focused clarification, or inviting the player to rephrase. Do not narrate an unsupported command as a fictional failure: if no action ran, state that clearly. Keep the prior scene intact, and make clear that sending a corrected input will retry the same moment rather than rewind a story event.
3. Unavailable character knowledge: a valid question with no answer yet
Sometimes the input is understandable, but the character does not know enough to act on it. A player may ask a shopkeeper’s assistant where a parcel was delivered, before the assistant has seen the receipt. The game can recognize the question while correctly withholding a definite answer.
This differs from unsupported input: the topic or action is valid, and the limitation belongs to the character’s information in the fiction. Mark that boundary plainly. For example: “Mina hasn’t seen the delivery slip, so she can’t name the street. The parcel label is still on the counter.” If the player can inspect the label, ask someone else, or return later, name that route. If not, say what is actually known rather than inventing a hint or treating the question as malformed.
Decide whether this response advances time or changes state. If asking the question is a normal in-world action, the game may record that conversation or alter how a character responds later. If the game intends knowledge questions to be free, preserve the scene and let another question follow. The player should not have to guess whether a request for information silently spent an opportunity.
4. Technical delivery failure: the action may never have reached the story
A delivery failure happens outside the fiction: a response times out, appears twice, or stops partway through a sentence. The game cannot safely claim that the character acted or that the story advanced unless it knows the action was processed. This is distinct from an in-world message such as “the courier could not find the address,” which is a fictional result.
Use plain status wording and report the known state. If the game can verify that the turn was not processed, say so and let the player resend it. If it cannot determine whether the turn was processed, avoid inviting a blind repeat that might perform the action twice. Explain the uncertainty briefly and offer a way to check the current scene or resume from the last confirmed point. These are design recommendations inferred from the need to distinguish a failed input match from a story outcome; the cited fiction systems do not define a universal protocol for chat delivery failures.
When delivery recovers, restore the last confirmed message or show a concise recap of the scene and the most recent action known to have completed. Label a recap as a recap, not as a new story turn. If the player chooses to resend, clarify whether it will be treated as a new attempt. That small bit of transparency prevents a duplicate action from being mistaken for a deliberate repeat.
Make retry, undo, and resume mean different things
These words describe different state effects, so avoid using them interchangeably. A retry submits an action again at the current state; it should not silently erase an established consequence. An undo restores an earlier state. A resume continues from the last confirmed state after interruption. A restart begins the story over.
Twine’s Harlowe manual documents undo as returning to the prior passage and forgetting variable changes made in the current passage; it describes restart as reloading the page to begin the story again. It also notes that undo history can be limited. Those mechanics show why a control should communicate its scope instead of relying on a vague “try again” label. (Harlowe 3.3.8 Manual: undo and restart)
A compact decision sequence helps keep the interface consistent:
Did the game understand and resolve the action? If yes, report the fictional outcome and the state that remains.
Did the system fail to map the wording to a supported action? Explain what it could not resolve and show a repair path; preserve the scene.
Was the action understood, but the character lacks information? Explain the knowledge boundary and any in-world way to learn more.
Is processing or delivery uncertain? State what is confirmed, then offer a safe way to check or continue.
If the player wants to go back, label the control “Undo” and state which moment or changes it restores. Reserve “Restart” for starting over.
A short consistency check for each failure message
Before shipping a response, check it against the story state. If it describes a setback, did the world actually change? If it describes unsupported input, did the game avoid pretending the action occurred? If the character lacks knowledge, does the response distinguish that from a missing command? If delivery failed, does the player know whether the turn was processed? Finally, does the retry or resume control do what its label promises?
A text game feels fair when its feedback helps the player distinguish what the character experienced from what the interface could not do. Clear consequences preserve the story; specific input guidance makes another attempt possible; honest knowledge limits keep the fiction coherent; and a defined recovery path gives the player a reliable way forward.