Handling Typos in Interactive Fiction: Don’t Change Commands for Players

When interactive fiction encounters a possible typo, the prompt should preserve the original input, identify the uncertain passage, and offer suggestions the player can confirm alongside a way to enter a new command. If a correction could change the action or its target, it must not execute silently. What the author needs to establish is not “the right answer,” but “how this input would be interpreted, and when the player agrees to that interpretation.”

The following is a fully fictional teaching example. It does not describe real users, measured results, hands-on testing, or DramaFork product features. Suppose a story scene contains a copper bell (铜铃) and a copper collar ornament (铜领饰) on a table, and both objects have already been introduced to the player. The examples retain the Chinese object labels because the uncertainty depends on their characters. The player enters “inspect 铜玲.”

“Inspect” specifies an action, but “铜玲” does not reliably identify an object. It might be a mistyped reference to “铜铃,” the copper bell, or an incomplete recollection of “铜领饰,” the copper collar ornament. Mark the entire phrase “铜玲” as uncertain. Do not simply replace “玲” with “铃” and declare the whole command repaired.

This example uses one editorial test: can the action and target still be identified as the same ones before and after the correction? If not, offer suggestions only. Similar-looking characters can support a suggestion; they cannot establish intent. Even if just one candidate seems plausible in the scene, that does not mean the player has agreed to it.

Conversely, if the input is already a valid alternative name, handle it through the rules for synonymous expressions. If two objects are both called “铜铃,” the issue is a duplicate target name. Do not label every input that cannot be executed a “typo.”

Start with three inputs for the same tabletop scene. The suggestions below use only objects the player already knows about. “No reasonable suggestion” means the author lacks sufficient grounds to propose a correction, not that the object cannot possibly exist in the story world.

This table is an author’s draft of repair prompts, not a guarantee of accurate automatic recognition. The first row offers two interpretations and the second only one, but both let the player decline. In the third, it is better to acknowledge that no match can be made than to choose an arbitrary object just to fill the suggestion column.

The actual prompt need not display the whole table, but the editorial draft must include all five columns. The execution point is especially important. If a draft merely says “confirm” without specifying whether the player is confirming wording or an action, implementation may mistake choosing a suggestion for having already executed it.

This example executes the command after one explicit confirmation. After the player submits the original input, the prompt first displays: “You entered ‘inspect 铜玲.’ We cannot yet determine which object ‘铜玲’ refers to. Which command do you want to execute? This input has not been executed.”

It then offers three options: “Execute: inspect 铜铃,” “Execute: inspect 铜领饰,” and “Neither—enter a new command.” Keeping the full command lets the player check both the action and the object. Showing only “铜铃” and “铜领饰” can make it seem as though they are still choosing a word and will submit the command separately afterward.

Suppose the player selects “Execute: inspect 铜领饰.” Only then does the story continue: “You look at the copper collar ornament and notice a shallow dent along its edge.” This is a fictional outcome of the action. It must not appear in the repair prompt before confirmation, or the player will receive information from inspecting the object without having agreed to inspect it.

If the player chooses to enter a new command, display: “This repair has been canceled. No action has been executed. Please enter a new command.” The original input can remain available for editing, but the suggestions are no longer awaiting confirmation. If the player then enters “inspect 铜铃,” handle that as a new command. Do not also execute the collar-ornament suggestion from the previous exchange.

Although “inspect 铜领式” has only one reasonable suggestion, “inspect 铜领饰,” the prompt should still ask. An extra confirmation interrupts reading, but immediate execution chooses the object for the player. This example retains confirmation because the author cannot establish intent from similar text alone.

When there is no reasonable suggestion, make the next step specific. “Please re-enter the name of the object you want to inspect” is more useful than “Invalid input. Try again.” If object names from the scene need to be listed, include only the copper bell and copper collar ornament already shown. Typo repair must not reveal undiscovered objects.

Rejecting a suggestion also needs a definite outcome: cancel the command awaiting confirmation for this exchange and return to input, without triggering character reactions, changes to objects, or clues obtained through inspection. In this example, repair does not consume a story turn. If your work has separate timing rules, define how time behaves during the wait; “nothing has been executed” is not enough to settle that question.

Also guard against stale confirmations. If the player submits a new command while confirmation is pending, invalidate the old suggestions. A standalone “yes” entered afterward must not execute an earlier suggestion. Confirmation must apply to the complete command currently being presented.

Before handing over the draft, work through the expected behavior row by row. Do not describe a paper walkthrough as completed testing. An input with multiple suggestions should stop at selection; an input with one suggestion should allow rejection; an input with no suggestion should return to re-entry. Check all three paths for the same two conditions: no story action before confirmation, and no command left awaiting execution after rejection.

Add a counterexample in which the action is unclear too: “查砍铜铃.” Here, “查砍” combines a character associated with examining with one meaning to chop, while “铜铃” still identifies the copper bell. Do not turn this into “查看铜铃,” meaning “inspect 铜铃,” just because the object is clear. “查砍” could involve a completely different action. The prompt should identify that passage and ask the player to re-enter the action, keeping a local wording repair from expanding into a guess at the intent of the entire sentence.

Another failure is “We’ve corrected that to ‘inspect 铜铃.’” This both overwrites the original text and presents an interpretation the player has not accepted as a settled fact. A better version is: “‘铜玲’ might refer to the copper bell (铜铃) or the copper collar ornament (铜领饰). Please specify the object.” This must still be followed by complete commands and an option to enter a new one.

This table applies to local uncertainties in the wording of action commands. Passwords, puzzle answers, exact character dialogue, and deliberately misspelled text may need to retain their literal form; object suggestions should not be applied to them automatically. At handoff, specify which inputs the approach covers and check each confirmation prompt against its execution point. What the player is promised must match what happens next in the story.