Docs

Getting it into Unity

What the export contains, how the Yarn Spinner files and string table fit together, and why the string IDs staying stable is the part that matters for localisation.

Export produces files. There is no plugin to install, no service your game talks to at runtime, and nothing that stops working if you stop paying.

What comes out

Yarn Spinner dialogue — one .yarn file per dialogue tree. Conditions and effects from the quest state machines are mapped through to Yarn’s own condition and command syntax, so a node that requires a flag arrives as a node that requires that flag.

A string table — csv and json, every line of dialogue with a stable ID. The .yarn files carry matching #line: tags, which is what lets Yarn Spinner and your localisation tooling agree on which string is which.

The whole project as a git repository — every generation, every edit, every approval as a commit. Clone it and it is an ordinary repo; nothing about it refers back to us.

Dropping it into a Unity project

  1. Install Yarn Spinner for Unity through the package manager, if it is not already there.
  2. Copy the exported .yarn files into your project — anywhere under Assets/.
  3. Add them to a Yarn Project asset so they compile together and share one string table.
  4. Point your dialogue runner at the node you want to start from.

The exported string table can be used directly as the source for your localisation pipeline, or ignored if you are shipping in one language and letting Yarn Spinner generate its own.

Why stable string IDs are the part that matters

The IDs are allocated once and kept. Regenerate a dialogue tree, edit a line, restructure the quest around it — the lines that did not change keep the IDs they had.

This is what makes localisation survive iteration. The failure mode it avoids is specific and expensive: you send a string table to translators, then regenerate a tree, the IDs shift, and now every translated line is attached to the wrong English one. Nobody notices until a playthrough in a language nobody on the team reads.

Export refuses to run if the IDs would change unexpectedly, rather than writing a table that would silently misalign what you already had translated.

Godot, Unreal, and everything else

Yarn Spinner ships for Godot and Unreal as well as Unity, and the exported .yarn files are the same files. If you use something else entirely, the string table is plain csv and json, and the quest state machines and beat sheet are plain structured data in the repository — the export is not the only readable thing, the whole project is.

The balance never blocks this

Running out of points pauses new generation and nothing else. Export, including the full git repository with history, works at a zero or negative balance. Taking your own work out is not something we hold back.