Where to go next

You have a story printing lines. From here the documentation stops being linear.

If you are building the game’s presentation

The playing a story track, in order. It is the longest track and the one a Unity developer spends real time in:

• Starting a session — the wiring a real game needs, and the two places you can hand in your own error handling.
• Reading a step — the whole read surface, once. This is the page to bookmark.
• Choices, and why one is locked — advancing, and drawing an option the player can see but cannot take.
• One handler per node type — where a node type’s own logic goes, and why it is a file rather than a branch in yours.
• Entity display: name, colour, portrait — resolving a speaker once, and why a game asks whether there is a colour rather than assuming one.
• Implementing commands — the hook a story calls to make your game do something.

If you want the exact members of a type

The reference track is the public surface, one page per subject. It is not meant to be read through — the sidebar is the index, and searching for a type name lands you on the page that documents it.

• The play loop and what a step contains — the two that most questions end at.
• The Unity player — TaleShardPlayer and the component that owns one, which is where most integrations actually start.
• Scripting and commands, saving, media — a subsystem each.
• Drawing text, colour and UI strings — everything between a resolved field and a pixel.
• Diagnostics — the two channels, and every code the runtime emits.
• Generated entity data — what the generator’s own types are built on.

Before your first real integration, what to get right first collects the ordering rules that cost an afternoon each.

If a picture is not drawing

Where synced media lands is the build side: the media path and the Resources segment in it, the address the postprocessor assigns, the import that has to happen for a sprite to load at all, and the one setting combination that ships every file into your build twice.

If you want to know what the sync wrote

The generated code track is two pages, and reading them once saves a lot of guessing at file names:

• What a sync generates to start from — GameBootstrapper, GameSession, GameData, and the two MonoBehaviours.
• The generated constants and stores — NodeTypes, GameBoards, EntityCodes and the four stores your game code reads through.

If you want the model rather than the API

The concepts track is four short pages, read once:

• The three files — who writes each, who reads each.
• Node meaning is resolved once — why there is no node-type table, and why that is a feature.
• Expressions ship as trees — parsed at sync time, evaluated at play time.
• The two seams — which assembly is which, and what belongs on each side.

Read these before writing a generator or a custom media source. They answer most of the questions that otherwise turn into a wrong design.

The payload, field by field sits in the same track and is the exception to read once: it is a reference, for when you are writing a generator or a second engine’s runtime and need to know what a key means.

If you are the person writing the story

You are in the wrong manual, and that is not a criticism — the editor is a different product and it has its own documentation. Nothing on these pages is needed to write a story.

The one page worth crossing over for is commands: a command you declare becomes a method a programmer has to write, and an awaited one that nobody implements fails their build. That is worth knowing before you author fifty of them.

Everything else in that shape is collected in what a build needs from a project — written for the programmer, but it is the list to go through together once.

If you are integrating deeply

Custom generators, custom media sources, and running the generator outside the editor are the extending track. Start at the two seams — the assembly boundaries decide which of those is even possible from where your code sits.

Then the generator pipeline, which is the list of twelve generators a sync runs and the four ways to change it, and post-sync hooks for reacting to a sync rather than changing what it writes.