Time Travel Interactive Fiction and Its Three Rules

Time travel interactive fiction works when the story commits to one rule about what reaching the past does, and then remembers enough to keep it. Three rule sets cover nearly the whole genre: the fixed loop, the branching timeline, and the single timeline you overwrite. Pick one and a paradox becomes plot. Drift between them and the reader stops believing any of it.

• A fixed loop holds that the past cannot be altered, so your visit to it was always part of what happened.
• A branching rule holds that a changed past opens a second line and leaves the first one standing.
• An overwrite rule holds that the past is replaced, so the present you return to is not the one you left.
• In ink, a passage label is an integer holding “the number of times the content at the address has been seen by the player.”
• Inform’s clock is a variable an author can reassign, which makes moving the hour trivial and restoring the world the real work.

What are the three rule sets in time travel interactive fiction?

A rule set answers one question: when you act in the past, what happens to everything downstream of it? Every time travel interactive fiction story answers that, deliberately or by accident. The three answers in common use are a closed loop, a branch, and an overwrite. Each is a promise to the reader, and each asks the story to keep a different kind of record.

Rule set	What acting in the past does	What the story must track	How it breaks when forgotten
Fixed loop	Nothing new; your visit was always part of history	Every event you have already caused, and which pass caused it	The second pass contradicts the first, and the loop is no longer closed
Branching	Opens a new line; the original continues without you	Which line you are standing in, and the state of each line	People and objects leak across lines that should never touch
Overwrite	Replaces what came after; the old present is gone	One current state, and the edits that produced it	The present reverts to details the change should have erased

Readers rarely name the rule set, but they feel it break. A story that lets you warn someone in 1904 and then forgets the warning has not written a paradox; it has written a mistake. The difference between the two is whether anything was recorded, which makes the third column of that table the one that decides whether the story holds.

Why does a time loop need a counter?

A loop is only a loop if something counts the passes. Authoring systems are unusually literal about this. In ink, inkle’s scripting language, the label you test to ask whether the reader has seen a passage is not a flag at all. The ink documentation is blunt: a knot or stitch used that way “is actually an integer variable containing the number of times the content at the address has been seen by the player.”

That integer is the loop’s spine. ink also supplies TURNS_SINCE(-> knot), which “returns the number of moves (formally, player inputs) since a particular knot/stitch was last visited,” and where a value of -1 means the passage “has never been seen.” Given a count and a distance, a passage can tell you that you have stood in this room four times, and that the last time was nine moves ago.

None of that is exotic. It is bookkeeping. But the effects readers remember from loop fiction are all comparisons between this pass and an earlier one: the line of dialogue arriving a beat early, the stranger who flinches at a name you have not said yet, the door you now open without looking. A story that cannot compare cannot deliver any of them.

What a loop costs the reader

Repetition is a tax on attention, and time travel interactive fiction pays it by making each pass shorter than the last. A hand-authored loop does this with variant text keyed to the read count. A story written live can do it by summarizing what you have already walked through and spending the words on what is new, which again works only if the earlier passes are still on file to summarize.

Can a story just move the clock backward?

Moving the clock is the easy half. Inform tracks a time of day value, and its manual notes that “play ordinarily begins at 9 AM and each turn takes one minute.” An author who needs a jump reassigns it. The manual’s own example covers “drastic events,” setting now the time of day is 10:12 AM when a character loses consciousness, and nothing stops the same assignment from naming an earlier hour instead.

The world does not follow the clock. Rolling time back to Tuesday does not unburn the barn, un-tell the secret, or bring back the cat, because those facts live in separate state that someone has to restore deliberately. That is the entire engineering problem of the genre, and it is why so many stories quietly cheat: the hour moves, the consequences stay, and the reader notices inside two scenes.

A hand-authored story pays that bill in advance, which is also its protection, since the author decided at writing time exactly which facts a jump restores. A story generated as you read has no such list unless something builds one, which is among the differences between Twine and AI interactive fiction worth understanding before judging either.

Does a time loop still have stakes?

Yes, as long as something survives the reset. If every pass returns the world to its opening state and the reader to their opening ignorance, the loop is a screensaver. The usual remedy is to let one channel persist: what you know, what a character has come to feel about you, or a price paid in something the loop does not refund.

That persistence also settles what death means inside a loop. Dying and restarting is not a consequence if nothing keeps count of it; it is a reload. As with character death in interactive fiction, whether a lethal moment ends anything is an authored call, and inside a loop the call is usually that it ends the pass rather than the story.

What to write when your move crosses time

Name the when before the what. “Go back and warn her” leaves a narrator guessing at which hour you mean and what you are willing to spend to get there. “Go back to the platform ten minutes before the train and tell her the name on the ticket is wrong” does not. In a story written as you read it, the specificity of your move is the specificity of the scene that comes back.

It helps to carry one object and one question. An object gives the story a physical fact to track across the jump, and a physical fact is harder to lose than an abstraction. A question gives your earlier self, or an earlier witness, something to answer, so the pass yields new information instead of a replay. Two passes that yield the same information are really one pass.

Fabledrift, an interactive fiction app for Android, keeps this sort of thing in a structured record of facts, characters, places and promises that is handed to the AI narrator on every turn, and readers can add notes of their own with “remember this.” When a note contradicts the story record, the note wins. In a story that bends time, that is where to pin the rule you want kept.

Settle this before the first jump

Three things want deciding before the story moves an hour in either direction.

• The rule set: loop, branch, or overwrite, stated plainly, even if only to yourself.
• The record: which facts a jump restores, and which ones it deliberately leaves standing.
• The carry: what crosses with you — knowledge, objects, injuries, debts — and what stays behind.

A story that has answered all three can run paradoxes all evening and stay coherent, because every strange thing in it is strange on purpose. A story that has answered none of them is not writing time travel interactive fiction at all. It is writing continuity errors with a clock attached.