Going Back Without Breaking the Story

Restoring an old version of a conversation can finish without a single error and still leave the story broken. The conversation gets its nodes and text back, but Captain Ilya, who spoke those lines, no longer exists in the project, and one of its conditions reads the trust_ilya variable, which was later renamed. The button said “restore”, but it only brought back part of what was there.

Almost nothing in an interactive story lives alone. A line may be connected to a translation and a recording. A choice depends on a variable. A character reappears across conversations, scenes, and documents that evolve at different speeds. Recovering text is simple. Recovering the meaning it acquired through everything around it is much harder.

Version control has spent decades trying to make change reversible. Its history helps explain why the problem changes when it reaches narrative design.

From files to connected stories

In 1972, Marc Rochkind wrote SCCS at Bell Labs to track source code versions and record who made changes, when, and why. In a retrospective published fifty years after his 1975 paper, he explained that the system did not model how programming teams actually worked. Among the weaknesses he lists: “SCCS controlled each file in isolation.”

Later tools added branches, merges, and distributed collaboration. Although systems such as Git version repository snapshots, their usual comparison vocabulary remains organized around files and lines. Narrative design inherited that infrastructure and its mismatch: to a designer, the thing that changed is usually a conversation, a scene, or a decision connected to many others.

Twine shows both the progress and what remains. Since version 2.6, it can export a story to Twee 3, a plain-text format whose passage headers carry each passage’s position and size, and import it back. Its guide to source control warns that Twine compresses story HTML, which can make diffs hard to read, and suggests converting stories to Twee before committing them. It also asks you to quit Twine before pulling or merging.

When an author who saved their work with Git asked for one passage per line in the story HTML, another user advised versioning Twee instead. That route has its own gaps: an open report notes that exporting to Twee and importing again removes a story’s tags.

Research on creative work points the same way. A 2022 study, based on 18 interviews with creative practitioners, starts from the observation that version control systems do not fit their needs and ways of working. Its interviewees also used version histories to gain confidence and freedom to explore.

A dependable way back lets teams experiment, divide work, and revisit decisions without maintaining folders full of copies. In branching narrative, where one edit can alter playable paths, state, localization, and voice-over, version history is both a production safeguard and a source of creative freedom.

Saving is only the first layer

Persistence problems still turn up, autosave included. In 2025, a user of Inky, the Ink editor, documented, with steps to reproduce it, that editing included files stored in nested subfolders could corrupt them and lose data. In 2026, another user found that in Twine, launching Play, Test, or Export right after editing a passage could leave the latest changes out; the fix is already in Twine’s development branch.

Part of the confusion comes from using “safety” for several different mechanisms. Save persists the current state. Undo reverses a recent action. A backup survives loss. History preserves decisions across time and should explain what changes when one is recovered. A product can provide three of those layers and still leave a gap in the fourth.

Plain-text files and Git provide portability, authorship, and an application-independent format. They are a valuable foundation. Git can tell us which lines changed; on its own, it does not know whether a condition made a branch unreachable or whether a translation still belongs to its source. Rochkind makes the same point about code: edits to different lines can still produce an incorrect merge, even one that fails to compile.

A story breaks between objects

Return to Ilya’s conversation, whose lines have now entered localization. Restoring only its nodes may leave an apparently correct canvas with a missing speaker, an unresolved condition, and a disconnected translation. Restoring the whole project brings the captain and variable back, but also replaces valid work created later. The difficulty lies in knowing which relationships belonged to that version and which evolved on their own afterwards.

Dialogue System for Unity makes the identity problem concrete. Its manual says only one person at a time should edit a dialogue database, and suggests several databases when several people write at the same time. Databases loaded together need unique IDs for each element type. The Unique ID Tool renumbers them, and the manual recommends renumbering before final testing and release.

Renumbering has consequences for code that uses those IDs. On the Pixel Crushers forum, a user explained that renumbering would break their Lua code, which read fields from other conversations by ID, and the answer was to give each database its own range, with Base IDs spaced 10,000 apart, so as not to need renumbering. Versioning content also means keeping the identifiers the rest of the project points to.

In LegendKeeper, import creates new content: reimporting an export from the same project produces copies with new IDs and new internal links. Recovering content that way yields a copy with a different identity.

Integration with source control has other risks. articy:draft X 4.2.2 restored deterministic ordering in partition files: after discarding changes, saving a reverted file could otherwise generate differences without changing its content. Version 4.3.4 corrected “Discard and Unclaim” so that it also releases source-control locks.

There has also been clear progress. Since December 2025, Arcweave has offered project history in Team workspaces: a timeline of the whole project in which each version shows who made changes, when, and what actions were recorded. Restoring keeps what came before: Arcweave “creates a new version that duplicates the selected version”, so later versions stay in the history. Its granularity is the project: the restore returns the whole project to that version. The useful question remains what a restore preserves: text, identity, relationships, authorship, and the future.

How we approach the problem in Storyarn

In Storyarn, we version units a designer recognizes: Sheets, Flows, and Scenes. Revisions can be named and compared as structured changes without reading JSON. Before restoring a version of a Sheet, a Flow, or a Scene, Storyarn saves the current state as a safety version, reads it back, and checks it before changing anything. Required references are validated against their active project-owned targets; those that are missing, malformed, or ambiguous block the restore instead of being silently cleared.

Each mechanism has its own scope. A version recovers one Sheet, Flow, or Scene, and automatic versions are turned on separately for each type in the project settings. Trash recovers what was deleted.

A backup returns the whole project to the backup’s state: it replaces the active Sheets, Flows, Scenes, and assets, and moves the current ones to Trash, where they can be recovered; the project and its members stay. Restoring a version of one Flow leaves every other Sheet, Flow, and Scene as it is. Inside the Flow, it brings back that version’s nodes, connections, and translations, and the safety version keeps the previous state, with everyone’s changes, in case the team needs it back. Afterwards, each editor’s health check flags any broken reference in Sheets, Flows, and Scenes.

A restore should say which narrative unit will change, keep its current state, and explain the effect on identities and relationships. For Ilya’s conversation, Storyarn already warns that her character is missing and blocks the restore until that is resolved, and the Flow’s health check flags the renamed variable; the next step is to also show what will happen to the translations of her lines.

If you have encountered a case where restoring a version broke a reference, a translation, or someone else’s work, we would like to hear about it. Real edge cases are what turn “going back” into something a team can trust.