One design, one place: why your game needs a single source of truth
Why design documents break as your game changes, and what happens when your design lives in one connected, playable project.
Somewhere in your design document there is a sentence like this one: the door to the pier opens once the player has the key. A programmer reads it, writes the check, and moves on.
Three weeks later the design changes. Now the door needs the key and a conversation with the ferryman. Someone updates the document. Nobody updates the build. The playtest finds it, if you are lucky.
That gap between what the team designed and what the game does is where most narrative bugs live. This post is about closing it.
A document describes. A project runs.
A game design document (GDD) is great at explaining a game, but bad at being one.
In a document, a condition is a sentence like "if the player has the key," and a branch is a line that says "see the Ferryman scene." Nothing is connected, so every change relies on someone remembering where else it matters.
In a studio of ten or more, this problem multiplies. The writer keeps the document, the programmer keeps the code, and the build is the first place where the two actually meet.
We built the same game twice
To see the difference up close, we wrote one short point-and-click adventure in two ways: as a design document and as an Arcweave project. Same story, same lines, same rules.
Then we changed it: a rename, a new condition on the exit, and a new character with a new ending.
The document handled the rename in seconds. Then it got hard. There was no obvious place to start, sections were copied and patched, and the document grew messier with every change.
In Arcweave, every change had a home before we started. The new character became a component. Its dialogue got a board. The new ending came from a few new variables.
One thing surprised us: we ended up modelling the game loop itself in the flow. In a document, a loop is a paragraph about behaviour. In Arcweave, it is structure, so editing the flow edits how the game behaves.
Play it before anyone builds it
You cannot playtest a GDD. You can playtest an Arcweave project the moment it has two connected elements.
Play Mode runs the story in the browser with every condition and variable live, so a broken branch shows up while you are still designing. Share the link, and the rest of the team plays the same version, with comments left exactly where the question arises.
From the board to the build
This is the part a document can never do: the project is not handed over to the game. The game reads it.
- Unity, Unreal and Godot have dedicated Arcweave plugins. The engine imports the project as data, so dialogue and logic arrive exactly as written.
- Runtime updates come through the API. A build can pull the latest published version of the story without a rebuild, so a writer's fix reaches the game the same day.
- Web games and custom engines read the Arcweave JSON export, and the open-source Arcscript interpreters run your conditions as authored instead of rewritten by hand.
- Play Mode embeds let a small story ship straight to the web, on itch.io or your own site.
The writer stays in Arcweave. The programmer stays in the engine. They don't need to visit each other's tool or copy anything across. The writer makes changes and the programmer reimports them.
Already have a GDD? Bring it in
Nobody wants to rebuild a finished design by hand. On the Team plan, the REST API can create boards, elements, connections, components and variables straight from an existing document. The MCP server, in beta, does the same without you wiring up the endpoints yourself.
The architecture gets built for you. Your writing comes across 1:1.
The honest cost
Your design document will always be useful for pitching the game. It should not be the thing your build depends on.
Sure, setting up a project requires more thought upfront. You decide how boards are split and where jumpers keep a busy flow readable. In our test that was where most of the setup time went.
However, with an Arcweave project, you only have to pay this once. With a document, you pay it on every change.
Arcweave is an intuitive narrative engine that manages your collaboration and acts as your project's source of truth, including text, logic, and assets.
