A sync writes the whole wiring: something that loads the data, something that holds the result, a static way to reach it, and two components you can drop on a GameObject.

GameBootstrapper.Setup

GameSession Setup(Func<string, string> loadJson, string language = null)

loadJson is the only seam: given a resource path with no extension, return its text. That is the same shape UIStrings takes, so a project on Addressables, an asset bundle or a downloaded pack passes the loader it already has.

It does seven things, in this order, and the order is the whole design:

Build the entity database. A ProjectDatabase is created, EntityLoader.LoadAll fills it, and it is sealed. Until that seal, every read on an entity set throws rather than answering empty.
Build the expression runtime from the payload — first, because everything below is a view over it. There is one source of truth for a value: gates read it, scripts write it, a save captures it. Anything it could not resolve is warned to the console rather than swallowed.
Create the stores — the enum registry, the variables, the entity store, the command handler — each a live view over that runtime. Then CommandHandler.Register.
Compose the game state from those four.
Build the story on the same runtime, with a diagnostics sink that routes errors and warnings to the Unity console.
Create the session and publish it as GameSession.Current.

GameSession

What Setup returns, and what GameSession.Current holds.

Member
`static GameSession Current`	Set by `Setup`. One per game.
`Database`	The sealed `ProjectDatabase`
`Variables` · `EntityStore` · `EnumRegistry` · `CommandHandler`	The four stores
`State`	The four composed as an `IGameState`
`Story`	The `EngineSession` — the play loop starts here

GameData

The static facade. Every member forwards to GameSession.Current, so game code never carries a reference.

Database · Variables · EntityStore · EnumRegistry · CommandHandler · State · Story · Dialogue, plus StartGame() and StartGame(string nodeId).

Dialogue is the story’s engine — one hop shorter than Story.Engine.

GameManagerBehaviour

The component that bootstraps. Drop it on one GameObject in your first scene and it does the rest.

dontDestroyOnLoad, a serialised field, defaults to true.
On Awake, if a session already exists it destroys its own GameObject and returns — so a second scene carrying the component cannot re-bootstrap over a running game.
It loads through Resources, and throws a named exception on a missing resource rather than returning null: TaleShard: missing resource at 'Resources/…'.

DialogueBehaviour

A MonoBehaviour wrapper around the engine, for getting a story on screen quickly.

Member
`StepPresented` · `Finished` · `ErrorRaised`
`Story` · `Engine` · `CurrentStep`
`IsAwaitingChoice` · `IsRunning`
`Initialize()`	Attaches to `GameData.Story`
`Initialize(EngineSession story)`
`Play()` · `Play(string boardId, string nodeId = null)`
`Advance()` · `Choose(int index)` · `Back()` · `Forward()` · `Stop()` · `SetLanguage(string)`

Turning this off

Everything on this page is the Unity bootstrap layer, and the sync window has a checkbox for it. Turn it off when you have your own game initialization — nothing else generated depends on it, and the pipeline reference has the other two toggles.

If you do, Setup’s seven steps above are the list of what you now owe: build and seal the database, build the runtime first, create the stores over it, register commands before anything can run a script, then build the story on that same runtime.

Where the pieces are documented


The play loop	What `Story` is
The Unity player	The richer alternative to `DialogueBehaviour`
Generated entity data	What `Database` holds, and the seal
Scripting and commands	The runtime every store is a view over
What a sync writes	Where these files land, and what to commit