Two Things at Once: Writing a Timeline the Player Cannot Witness

To write concurrent events the player cannot witness, put both strands on one timeline, then add the times and conditions under which information arrives. Every event should answer at least three questions: When does it happen? Through which channels can the player learn about it? Which parts cannot be revisited? Information may arrive late; established events must not quietly be rescheduled because the player arrives late.

The following example, Rainy Night Observatory, is an original fictional teaching scenario, not a real user case, test result, or product feature. The player stays in the machine room to repair a generator while another team moves observation instruments from storage to the receiving room. The repair is purely a narrative situation and provides no instructions for operating equipment.

The scene must establish why the crew delivers one fewer instrument case and what grounds the player has for deciding where to look next. The author knows the full sequence; the player encounters only part of it. That gap must be reflected in the evidence.

This example advances through story nodes. Reading and pausing consume no story time. Inspecting the panel advances the clock to 21:03, completing the repair to 21:08, and leaving the machine room to 21:10. When a node crosses several timestamps, process the intervening events in order: advancing from 21:03 to 21:08 first delivers the broken voice transmission scheduled for 21:04, then resolves the completed repair. Checking records and asking questions require the player to act; an event happening in the background does not mean the player knows about it.

All times below belong to the fictional story. “How it can be learned later” lists channels only; whether the player knows the information depends on whether the current path has triggered them.

After 21:10, every path follows the same rules: each move between locations, inspection of a set of documents, question, or wait advances time by one minute. Extra actions also count. Resolve that minute’s offscreen events before presenting the action’s result. Reading existing notes does not advance time. The platform and receiving room have a two-way intercom. Asking from the platform also takes one minute, and the reply arrives after offscreen events have been resolved.

Cen always reaches the platform at 21:15. If the case is still there, he takes it, returns to the receiving room at 21:16, and logs it. If the player has already taken it, he still reaches the platform on time and returns empty-handed. This is the example’s fixed schedule, not an event triggered by the player’s arrival. When the player carries the case back to the receiving room, travel and handover form a single node, which also updates the log.

To reuse this structure, replace the events while preserving the distinction between “happened,” “can be learned,” and “cannot be recovered.” Specify each channel’s trigger conditions and separately record when the current path actually obtains its information. Information from untriggered channels does not count as known.

Here, the east-corridor door is mechanically jammed. Restoring power will not open it, so the rerouting happens independently. If you replace it with an electrically controlled door and allow power to be restored earlier, you must write the corresponding outcomes.

As the clock advances through 21:04, the player hears: “East corridor blocked. Rerouting via…” This establishes only that the crew reported an obstruction in the east corridor. The prompt cannot say “Go to the west platform to meet them.” The location has not been communicated; prompts must not complete messages on the character’s behalf.

The player leaves the machine room at 21:10, reaches the receiving room at 21:11, and checks the dispatch slip and receiving log at 21:12. Three cases dispatched and two received supports only a discrepancy in quantity. It does not prove that someone stole a case. The third might have been set aside temporarily or lost.

At 21:13, the player asks a question. The crew member who stayed behind says: “We left the third case on the west platform. Cen is getting ready to go back for it.” This supplies a location and a crew member’s account. Since the case has not yet been seen, the note should say “Go to the west platform to check,” not prematurely claim “Recover the instrument left behind.” If the player skips the question, that location cannot simply appear in the notes.

At 21:14, the player reaches the platform and finds the third case. Only now is its presence there at this moment confirmed. The case cannot establish who first suggested leaving it, or whether the two crew members argued.

The available choices are now “Carry the case back to the receiving room” and “Wait for Cen to take the case, then ask over the intercom how it came to be left here.” The first completes the handover at 21:15. With the second, the player waits until 21:15, sees Cen take the case and leave, then remains on the platform and asks. The node advances the clock to 21:16: first resolve Cen’s return and log entry in the receiving room, then deliver his spoken account. One choice prioritizes delivery; the other prioritizes learning what happened. Both rely on information already obtained.

This is only a demonstration path. The player could instead choose the platform as a place to explore, go directly there, and see the case as early as 21:11. Without asking, they cannot claim to know how it came to be left there. If an extra action delays arrival until 21:15, Cen has already taken the case under the shared rules, and the player sees only the scene after its removal. After 21:16, they can also visit the receiving room to check the updated log. Arriving late changes the visible evidence, not Cen’s schedule. An empty platform alone cannot prove that the case was never there.

If investigation is the focus, delay discovery: show the quantity discrepancy first, then let the player seek witnesses and physical evidence. This gives the player grounds for judgment, at the cost of a weaker sense of urgency during the transport itself. A broken voice transmission can preserve the sense that the other team is still active, but every line must stay within its information limits.

If suspense is the focus, you can cut to the transport crew and show the audience the case being left behind, creating a gap between audience knowledge and the protagonist’s knowledge. The protagonist’s options cannot refer to the secret shown onscreen unless that information arrives through another channel. A cutaway addresses the audience’s absence, not the character’s.

If coordination is the focus, the crew can send a request for guidance that comes through in full before changing route. The player participates in decisions on the other strand, turning the task into remote command. This suits a story in which two teams influence each other, but leaves less to reconstruct afterward.

Verification needs traces, apprehension can rely on the audience knowing in advance, and coordination needs communication before a decision is settled. Once an event is over, do not insert a button that pretends it can change the past.

The first failure is “the world waits for the player.” The crew begins moving only when the player arrives, even though the text says both sides have been acting simultaneously all along. Logs, people’s positions, and quantities should reflect what has already happened. If the crew really is waiting, establish that arrangement beforehand. Nor should the retrieval time be secretly tied to the player’s arrival.

The second failure is “the crucial warning added after the fact.” Only at the end does the story reveal that the undelivered part of the voice message ordered the player to rush to the platform, then blame them for failing to do so. Characters may misunderstand, but the narration must not treat an unreceived message as a fact the player ignored. For missing a message to carry consequences the player can reasonably bear, explain the communication opportunity and its limits before the player makes the choice.

The third failure is “playback fills every gap.” If the end of the message was not saved, a recording cannot suddenly appear. If an argument has not been established, an unsourced flashback cannot present it as a verified finding. You may add witness testimony, but distinguish it from a direct record: recollection is not a verbatim transcript.

“Cannot be revisited” means that the current story rules provide no channel for returning to or verifying something. It does not prohibit replaying the game. If time travel is allowed, specify its return conditions and rules for changing events separately.

Before submitting the draft, list the information potentially available before every decision. Circle only what the current path actually obtains, and note the channel and time. Hide the unobtained information and reread the options: judgments need to rest on information the player has already received; obtainable clues count only as opportunities to investigate. Then check paths involving direct travel, extra actions, and late arrivals to ensure that the offscreen schedule keeps advancing. Mark which gaps can be investigated and which must remain unknown.