What a Save File Actually Remembers About Your Choices

People talk about saving an interactive story as if it were a bookmark. It is not. A bookmark records a position in a fixed text; a save records a position plus whatever the engine was holding in its hands at that moment. Those two things can diverge, and when they do, the reader is usually the last to find out.

The engine already tracks things you never named

Consider how ink describes its own structure. The manual explains that the story flow is “flat” — there is no call stack, and diverts are not returned from. A script starts at the top, moves between named knots by divert, and eventually reaches -> END. On the surface that sounds like nothing is remembered at all.

But the same manual introduces functions that read the engine’s memory directly. TURNS() returns the number of game turns since play began. TURNS_SINCE(-> knot) returns the number of moves since a particular knot was last visited, where zero means it was seen in the current chunk, minus one means it has never been seen, and any other positive value means it was seen that many turns ago.

That is a memory of your past. It is not prose you read; it is a counter the author can query. Any story that uses it can greet you differently on a second visit, lock a door because you already opened it, or refuse to repeat a scene. None of that is visible in the text you are reading — only in what the text does next.

Choice counts are memory too

Ink also exposes CHOICE_COUNT(), which returns the number of options created so far in the current chunk. The manual’s own example uses it inside an option’s condition so that a third choice only appears when fewer than two exist — producing a menu of two rather than three.

For a reader, this means the size of a menu can be a function of earlier menus. If a game offers you three doors the first time and two the second, that is not a glitch or a shrinking budget. It is a rule the author wrote about how many options the player is allowed to see at once.

Saving in Twine is a variable problem

Twine’s own documentation frames passages as the basic unit: a title, optional tags, and content in which prose and code are not separated. Because code lives beside the prose, the state that matters is generally whatever variables the format provides.

The Cookbook’s account of story formats explains why this varies so much. Harlowe and Chapbook are described as user-friendly but limited in advanced functionality; SugarCube carries a large, expanded set of built-in features and expects the author to know the tool; Snowman ships with very little built in and expects the author to write or supply it.

The practical consequence for saving is direct. A story told in a format with a mature save system will restore variables for you. A story that supplies its own state handling may save only what its author remembered to serialise. If a re-read behaves oddly — a flag you earned that is suddenly gone — the fault usually lies at that seam, not in your memory of what happened.

Undo is not the same as reload

Undo is a stack of states inside the running session. Reload is a state reconstituted from storage. They can disagree, and the disagreement is often where readers get confused.

This is where the flat flow of ink becomes useful rather than just technical. Because diverts do not return, an undo in an ink story is not “step back one function call” — it is a step back along a recorded sequence of turns. Anything the script did between turns, including automatic diverts that happened without your input, belongs to that sequence.

A reader’s rule of thumb: if the story moved without asking, that movement still counts as a turn in the record, even if you did not choose it.

Re-reading is a different operation

When you finish an interactive story and start again, you are usually not resuming the same machine. You are constructing a fresh one with initial values. That is why some engines can show you a “previously visited” marker and others cannot: the marker depends on state that may not survive a restart at all.

Two habits keep this honest:

• Save before experiments, not after. If you want to see a branch and come back, save first. Saving after the experiment bakes the experiment into the state.
• Name your saves by what you knew, not where you were. “Before the cellar” is less useful than “before I told the boatman the truth”, because the second records a fact the engine may be holding.

What the engine cannot remember

Nothing in these systems tracks your comprehension. The machine knows which knots you visited and how many turns have passed; it does not know that you skipped a sentence, misunderstood a hint, or read the ending twice.

That asymmetry is the real subject here. Interactive stories are precise about mechanism and indifferent to understanding, which is why the best way to read one closely is to keep your own external record — a note of what you decided and why — and compare it with what the story decides to remember.

Sources

• inkle, Writing with ink — https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md
• Twine Cookbook, “Passages” — https://twinery.org/cookbook/introduction/passages.html
• Twine Cookbook, “Story Formats” — https://twinery.org/cookbook/introduction/story_formats.html
• Twine 2 reference guide — https://twinery.org/reference/en/