Introducing Storyarn: A Connected Narrative Design Platform

Today we are opening Storyarn to everyone.

Storyarn is a narrative design platform for teams building interactive stories. It connects brainstorming, worldbuilding, branching dialogue, spatial scenes, testing, localization, and export in one project.

It comes from a product decision: an interactive story has to behave as one system, even when it is built with several tools. So Storyarn focuses on the connections that are hardest to preserve when ideation, worldbuilding, dialogue, state, scenes, localization, and implementation live in different places.

Behind a single line

Consider a short exchange in which the player asks a character about a hidden location.

The idea that this character keeps the secret came out of a team brainstorm. The response only appears when that character trusts the player. Choosing it changes the state of a quest. The location becomes available on the map. The line needs translation, its voice-over needs tracking, and the final result has to reach the game in a form the runtime can understand.

Writing the sentence is the smallest part of that decision.

Teams have capable tools, and their boundaries overlap. World Anvil focuses on organizing and presenting the narrative world, while Notion can be adapted into a project wiki or knowledge base. articy:draft X and Arcweave cover a much broader part of narrative design: structured data, interactive flows, logic, testing, localization, and engine integration. Yarn Spinner and Ink approach the problem through narrative scripting and execution inside the game.

Some teams run most of the work from a single platform. At Drop Bear Bytes, the vast majority of Broken Roads runs on articy:draft, while the data the tool did not suit stayed in Unity.

When the work is split across several tools, the fragile part is the connections between them. A condition is renamed in the dialogue but not in the engine integration. A character decision changes in the world bible while an older assumption survives in a branch. A location exists in the setting, yet no reachable path reveals it. A translator receives a line without the state or context that gives it meaning.

Teams keep these connections with stable identifiers. Yarn Spinner gives every line an ID that links its translations and voice-over, and Unity’s localization tables look up each string by key. Around those IDs come naming conventions and integration code.

In our experience, keeping these connections also takes documentation, reviews, and people who know where each dependency crosses a tool boundary. That coordination becomes more expensive as the project grows and more disciplines depend on the same decisions.

Storyarn is another response to that continuity problem: it keeps world data, narrative, state, scenes, and localization connected and navigable in one shared web environment, so the team can inspect and change how they relate while designing the story.

A connected narrative model

The central idea is straightforward: the character, the trust value, the conversation, the location, and the localized line can belong to one model, instead of being five representations the team has to reconcile by hand.

Sheets describe the structured parts of a world: characters, places, factions, items, quests, and the fields that matter to the project. Flows use that data directly in dialogue, responses, conditions, and instructions. Scenes give narrative content a spatial context. Localization retains the identity and source of player-facing text. And in Brainstorming sessions, the team records its decisions and links them to the Sheets, Flows, and Scenes they change.

All of these pieces work together. A field defined for a character can be read by a condition in a Flow and changed by an instruction. A scene can lead into that Flow during exploration. When the source dialogue changes, the localization workflow can show that the existing translation now needs attention.

This changes the questions a team can ask: “what makes this line available?”, “which decision led to it?”, “what does it change?”, “where can the player encounter it?”, and “which translation came from it?”

We also want to keep the creative intent close to the work: the graph should explain on its own what a condition means, worldbuilding context and executable state should move together, and a handoff should start with the relationships already in place, without rebuilding them from identifiers, exports, and private conventions.

Follow one decision through the project

Return to the hidden location.

The decision is made in a Brainstorming session and linked to the character’s Sheet and the conversation’s Flow. The character’s trust value is defined once as structured data in Storyarn. The conversation checks that exact value. If the requirement is met, the response becomes available; choosing it can update the quest and reveal the location. The scene gives the location a place in the world, and the dialogue keeps its source identity as it moves into localization.

What matters is that the same decision can keep its identity as it moves from the session where it was made through the Sheet editor, the node canvas, and the map, without being translated into a new private convention at every boundary.

Branching narrative has state, dependencies, reusable structures, delayed consequences, and edge cases. Storyarn’s job is to keep that complexity visible and navigable. A writer can stay with the conversation while a narrative designer inspects its rules. A localization team can see the source context. An engineer can receive Flows, Sheets, and localized text exported from one model instead of several exports whose relationships have to be reconstructed during integration.

Test the story before the engine

To call an interactive story finished, you have to be able to run it.

Playback in the Sequence editor runs a Flow from the dialogue you choose, as the player would experience it, evaluating its conditions and applying its instructions. Debug Mode exposes the logic underneath: it steps through the Flow from any node, traces the path taken, shows every variable before and after it changes, explains each condition rule by rule, stops at breakpoints, and follows the run into subflows.

Those are different kinds of feedback. Playback helps a team judge pacing, choice, and context. Debug Mode helps it understand behavior.

The final experience is tested in the game engine: UI, animation, audio, saving, input, and integration. Storyarn lets a narrative designer find out earlier, without leaving the project, that a branch is unreachable or a condition reads the wrong value.

Before export, Storyarn validates the connected project for broken references, unreachable paths, missing entry points, incomplete content, and other issues that are easier to resolve while the narrative context is still present. It can then export Flows, Sheets, and localized text to Ink, Yarn Spinner, and Dialogic (Godot). Exports to Dialogue System for Unity (JSON), Unreal Engine (CSV for Data Tables), and an XML file that follows articy:draft’s export structure are in beta.

Scenes and the visual and audio composition in Sequence are for designing and testing the story inside Storyarn; in the game, they are implemented in the engine. Pre-export validation flags every Flow that uses Sequence composition.

Open beta is where the model meets real projects

Storyarn can already take a brainstorm through to decisions about the content, structure worlds, build and run branching Flows, map narrative spaces, manage localization, validate projects, and prepare exports. It is an open beta, and its features will keep evolving with what real productions teach us.

We want to learn what narrative teams need to work in Storyarn from start to finish: which part of the process they still handle in another tool, which relationship they want to express, which handoff to the engine loses context, and which part of writing needs more support.

Storyarn works alongside the tools each team values. Our goal is to reduce how much of the narrative model has to be rebuilt whenever work moves from one tool to another.

Storyarn is being built for narrative designers, game writers, world builders, localization teams, and small studios that need more than a dialogue editor and want a lightweight creative process.

We are building a place where the complexity of interactive narrative stays connected, testable, and understandable from the first idea to the game.