When Result Text Cuts Off in Interactive Fiction: Read On or Resubmit?

When result text cuts off midway, first explain what is known about the action, then tell the player what the next step will do. Offer “Continue reading” only when the action is confirmed to have taken effect and its original result text can be retrieved. Offer “Resubmit” only when the action is confirmed not to have been executed. If execution is unknown, first state that the outcome still needs to be confirmed. Text that did not arrive does not mean an action did not happen.

The parcel-delivery example below demonstrates a reusable table for recovery copy. It is a fictional teaching example, not a real user experience, a tested result, or a DramaFork product feature. Status records, retained original text, and a way to check the outcome are explicit assumptions in this example; each would need to be implemented in an actual work.

The player selects “Hand the parcel to the attendant.” The screen gets as far as “The attendant takes the parcel and opens the logbook…” before the text cuts off. This fragment can make the delivery seem complete, but recovery messages cannot determine the action’s status from the narrative tone alone.

The author first checks two things: whether this delivery is confirmed to have taken effect, and how much of its result text was displayed. The first determines whether the action can be attempted again; the second determines where reading can resume. An action may be complete even if the player saw only half a sentence. Conversely, the words “takes the parcel” cannot replace evidence confirming this particular action.

For this example, the confirmation record must correspond to this submission. “Delivery complete” means the parcel has been handed over and the stated consequences of the action have taken effect. If all that can be confirmed is receipt of the request, do not describe the delivery as successful. Whenever neither execution nor non-execution can be established, use the pending-confirmation branch. Do not guess based on how long the player has waited.

Record the displayed portion accurately, too. If the last complete sentence is known, record that sentence. If all that is known is that some text appeared, write “Partial text; cutoff point unknown.” An unknown cutoff point does not prevent you from showing the retained result in full, but it does prevent you from promising to resume at the exact point of interruption.

Treat each row as the basis for the recovery copy. Fill in the status and recoverable content first, and name the option last. This avoids writing “Retry” first and then assigning it to every kind of interruption.

The option in the last row assumes that the outcome can actually be checked. If the work provides neither a lookup mechanism nor a way to check manually, it can only display “Delivery outcome awaiting confirmation” and explain that recovery is currently unavailable. Do not present a “Check outcome” button that actually resubmits the action.

It is better for the table to promise less than to present a confirmed status as the complete story. This sacrifices some reading continuity, but preserves the player’s ability to judge what has happened to the parcel.

The first branch assumes that delivery is confirmed, the full result is retained, and the cutoff point is known. The recovery message reads: “This delivery is complete, but its result text was not fully displayed. Continue reading to see the remaining text from the same delivery. This will not submit the delivery again.” The option is “Continue reading the delivery result.”

Next, show a short marker—“Continuing the previous delivery result”—followed by the original text: “Your name is added to the logbook. The attendant slides the receipt toward you and gestures for you to keep it.” This passage belongs to the retained original result. It is not a new registration taking place when the player resumes reading.

Do not rewrite it as “You hand over the parcel again, and the attendant finally accepts it.” “Again” and “finally” turn restored text into a repeated action and imply that the earlier attempt did not succeed. Even an edit intended only to improve the flow can change how many times the player believes an event occurred.

If the cutoff point is unreliable but the full text remains available, use “Reread the full result of this delivery” and explain beforehand that it includes passages already read. Repeated text is easier to recognize than an important missing sentence, but it must be labeled as a reread. If the original text has been lost and only evidence of completed delivery remains, write: “This delivery is complete. Its original result text cannot currently be retrieved.” Do not invent receipt details and pass them off as the original text.

The second branch assumes that this delivery is confirmed not to have been executed. Even if the fragment says “takes the parcel,” explicitly correct the impression: “This delivery was not executed. The handoff text shown earlier does not mean the action took effect. You can resubmit the delivery.” The option is “Resubmit delivery.”

Resubmitting initiates the action again; it does not guarantee that the next attempt will succeed. If conditions need to be checked again before submission, start with that check instead of carrying over the outcome suggested by the fragment. Display the corresponding result only after obtaining new confirmation. Do not append “Registration complete” merely to finish the sentence.

The third branch assumes that whether this delivery was executed cannot be confirmed. The message reads: “Delivery feedback was interrupted. We cannot currently confirm whether this action took effect. Check the outcome first to avoid a duplicate delivery.” The option is “Check delivery outcome,” and it must only check the original submission.

If that check confirms completion, move to continued reading or a status view. Allow resubmission only if non-execution is confirmed. If the status remains unknown, retain “Outcome awaiting confirmation.” Do not write “No record was found, so the delivery failed.” Missing confirmation and confirmed non-execution are two different kinds of evidence.

An unknown status temporarily halts progress; that is its cost. Authors can explain what is currently possible, but cannot promise that recovery will definitely become available later. Nor should “Click again to continue” conceal the possibility of repeating the action.

Read the message, the option label, and the first paragraph shown afterward together. Players should be able to answer two questions: Is the parcel confirmed to have been handed over? Will this option display text, check the outcome, or initiate another delivery? If they have to guess what “Continue,” “Recover,” or “Retry” means, specify the action and its object.

Then remove the example’s assumptions one at a time. If the original text is unavailable, does the copy still promise to restore it in full? If the cutoff point is unknown, does it still promise seamless continuation without repetition? If execution is unknown, does the wording still imply success? If checking remains inconclusive, does it incorrectly allow another attempt? This is a walkthrough of the copy under hypothetical conditions, not a completed product test.

Pay particular attention to whether guarantees such as “This will not submit the action again” match the option’s behavior. If the option actually includes re-execution, a new button label cannot turn it into continued reading. Change the behavior or rewrite the message. If another interruption occurs during recovery, choose a row again using the status that can now be confirmed. Do not assume the preceding step finished.

This table applies to interruptions in the delivery of result text for a single action. A delivery explicitly refused by the story, a sequence of commands only partly completed, or a delivery that simultaneously triggers several consequences not yet fully verified all require additional states. They cannot be forced into “success or failure.” Include the table, the three messages, and the assumptions supporting each when handing off the work, so later revisions can check the basis for every promise.