Sequential Actions in Interactive Fiction: Show Exactly Where Execution Stopped

When an input contains a sequence of actions, split it into individual instructions, then process them according to the stated rules. If execution gets blocked, clearly distinguish “completed,” “currently blocked,” and “not started,” and preserve the results that have already taken effect. Do not just say, “The door is closed. You cannot continue,” and leave the player guessing whether they have picked up the lamp or touched the curtain.

This article turns “pick up the lamp, enter the dark room, draw back the curtain” into an execution report whose results can be checked. The following scenario, rules, and feedback are fictional teaching examples. They are not real user experiences, empirical findings, or records of hands-on testing, and they do not represent DramaFork product features.

Three verbs in one sentence do not mean that all three actions can happen together. This example uses the following rules: consecutive actions separated by commas are processed in the order written; “then” explicitly requires the preceding step to finish before the next begins; if any step is blocked, all subsequent actions in that input stop. Explain these rules before accepting this kind of input.

“Pick up the lamp, then enter the dark room, then draw back the curtain” therefore creates a three-step queue. Even if the third step could be performed independently in another scenario, it cannot be executed by skipping the failed second step: the player specified an order.

“Simultaneously” needs a different set of rules. Authors should first check whether the actions can run in parallel, then decide whether to accept the input as a group. The three actions in this example cannot reasonably be processed simultaneously: the character is still outside and cannot reach the curtain inside. If the player requests simultaneous execution, the feedback could say: “These actions cannot be performed simultaneously. No action has started in this attempt. Please request them in sequence.” Do not silently change “simultaneously” to “then.”

Scenarios that genuinely allow parallel actions also need rules explaining whether one action’s failure affects the others and when each result takes effect. The report in this article covers sequential queues only; it does not force parallel groups into a single sequence.

Set the initial state: an oil lamp rests on a table outside the door, the character stands empty-handed before the closed door to the dark room, and the curtain is inside. The only rule established here is that the character cannot enter directly while the door is closed. Do not additionally infer that it is locked or add an action to open it on the player’s behalf.

First, separate the actions and their completion conditions:

There are two different relationships here. “Pick up the lamp before entering” comes from the input order; this example does not require the character to carry a lamp to enter the room. “Enter before you can reach the curtain” comes from the spatial conditions of the scene. Keeping these separate makes it clear which constraints still apply if the command is rewritten.

The stopping rule also needs to say more than “stop if a dependency fails.” This example stops the entire remaining queue whenever an action is blocked, so that the scope of “then” stays predictable. The tradeoff is that even an independently executable action later in the queue must wait for a separate input from the player. If a work allows execution to skip failed actions and continue, that rule must be announced in advance and results reported action by action. Do not switch rules on the fly.

The reusable report fields are: original input | rules for connecting words | action breakdown | dependencies | stopping point | results already in effect | remaining instructions | conditions for resuming. Fill these in before writing the narrative response to avoid sacrificing clarity about completion for smoother prose.

Here is the completed report for this example:

• Original input: Pick up the lamp, enter the dark room, draw back the curtain.
• Rules for connecting words: Execute in sequence; if blocked, stop subsequent actions.
• Action breakdown: One, pick up the lamp; two, enter; three, draw back the curtain.
• Dependencies: Two follows one; three follows two and requires entering the room to reach the target.
• Stopping point: Step two. The door is closed, so the character did not enter.
• Results already in effect: The oil lamp is in the character’s hand; the character remains outside. This blocked attempt causes no other state changes in this example.
• Remaining instructions: Enter the dark room and draw back the curtain. Entering was attempted but not completed; drawing back the curtain has not started.
• Conditions for resuming: First make the entrance passable, then have the player submit the remaining actions. This command does not remain pending for automatic resumption.

For the player, this can become one paragraph: “You have picked up the oil lamp from the table. The door to the dark room is closed, so you could not enter. You are still outside, holding the lamp. This command stopped at the step of entering the dark room; drawing back the curtain has not started, and the curtain has not been touched. Once the entrance is passable, please submit ‘enter the dark room, then draw back the curtain’ again.”

This feedback explains what happened first, describes the obstacle next, and finally defines what remains. It does not treat the blockage as invalidating the entire command, nor does it take the opportunity to open the door for the player.

When reviewing the draft, work through three cases from the same initial state, changing only the conditions needed for each case. Do not quietly carry results from one walkthrough into the next.

Failure at the first step: Suppose the oil lamp is fixed in place and cannot be picked up. The report should say: “You could not pick up the oil lamp. It remains on the table, and this command stopped at the first step. Neither entering the dark room nor drawing back the curtain has started.” No step has been completed, so you cannot write, “You carry the lamp over to the door.”

Failure midway: Use the closed-door setup described earlier. Step one is complete, step two is blocked, and step three has not started. Check the character’s location, the lamp’s location, and the curtain’s state: they must be outside the door, in hand, and hanging down, respectively.

Full completion: Suppose the door is open, the way is clear, and the curtain is within reach and can be drawn back. The feedback could say: “You pick up the oil lamp, enter the dark room, and draw back the curtain. All three steps are complete: the lamp is in your hand, you are inside, and the curtain is drawn back. There are no remaining instructions.”

These are textual walkthroughs, not a validation of success rates. Also remember that “not completed” does not mean “had no effect”: if a failed action consumed an item or changed the character’s location, the report must include those actual results. This example explicitly has no such changes; that condition cannot be generalized to all failed actions.

The least ambiguous way to resume is to submit only the blocked action and the actions after it. After a mid-sequence blockage, the player first deals with the entrance, then enters “enter the dark room, then draw back the curtain.” There is no need to pick up the lamp again. The remaining instructions in the blockage report become text the player can copy to resume.

If the player resends the original three-step command unchanged, the author needs an explicit rule for repeated actions. This example could use the following rule: if the same lamp is still in hand, record “pick up the lamp” as “target state already satisfied; action not repeated in this attempt,” then check the entry conditions again. If the door is still closed, stop at step two again. If the lamp has been put down, the previous completion record can no longer be used.

This approach is suitable only for actions whose target state can be confirmed from the current state. Repeating “knock on the door” or “take a sip of water” may produce new results; those actions cannot be skipped merely because the wording is identical. If it is unclear whether the player is retrying an action or asking to repeat it, clarify first and state that nothing has been executed in this attempt.

Before submitting the draft, classify every verb as completed, blocked, or not started, then check that the final state matches the text provided for resuming. This report applies to sequential commands whose actions and objects are already clear. It does not resolve ambiguous targets, and it does not require every failure to come with a clue or narrative reward.