Endings
Mark a scene as an ending, keep your endings distinct, and understand the gallery readers collect them in.
Play stops when a scene's script runs out and no edge leaving it matches. The studio wants that scene to say which ending the reader just reached, so the final screen can name it and the gallery can count it.
Mark a scene as an ending
Open the scene
Select it in the navigator or in the flow view. The right dock's Stage tab follows the open scene.
Tick the box
Under the Ending heading, tick this scene is an ending. A title field appears, pre-filled with "An ending".
Name it
Replace the title with what the reader should see, for example "She was the arsonist". The optional flavour field is a subtitle line under it.
That is the whole ending record:
| Field | Required | What it does |
|---|---|---|
| id | Yes, minted for you | The ending's stable identity. Never shown to the reader |
| title | Yes | The heading on the end screen, and the row in the gallery once found |
| flavour | No | A subtitle under the title on the end screen |
Unticking the box and ticking it again mints a new id. To a reader who had already found that ending, it becomes an ending they have never seen, and their gallery count drops. Edit the title instead of clearing the mark.
What makes an ending distinct
One marked scene is one ending. Two scenes can carry the same title if you want them to read the same, but they count as two, because the count is over ids. Duplicate ids are a compile error.
Two compile rules keep the set honest, and you will meet both:
- Play can stop here, but no ending is named. Every scene without an unconditional outgoing edge is a place the story can end. Either mark it, or give it an edge onward with no condition. In the flow view these scenes wear the dead end tag until you do.
- This scene names an ending but always routes onward. A marked scene with an unconditional edge out can never be a stopping point, so the ending could never be reached and the gallery would sit at "N of M" forever. Drop the mark or condition the edge.
The second one is reported as you type, in the header's problem list, with a link straight to the scene. The first is not: a draft is allowed loose ends, so it only surfaces when you publish, which it blocks. The dead end tag in the flow view is the warning you get in the meantime.
What the reader sees
At the end of a playthrough: a small "Ending reached" kicker, the ending title as the heading, the flavour line underneath if you wrote one, then Play again and Return to title. A story that ends on an unmarked scene shows "The End" instead.
Back on the title screen, if the story has at least one ending, the reader gets the gallery:
You have found 3 of 8 endings
[check] She was the arsonist
[check] Nobody talks
[lock] Undiscovered
[lock] UndiscoveredAn ending they have not reached shows as Undiscovered with no title, because an ending's title is usually the punchline of a branch and listing all eight on the front door would spoil seven of them. The count stays honest either way, which is what makes it something to chase.
Below the list sits Clear unlocks and endings. It forgets both the found endings and everything the story remembers between playthroughs (persistent state). Saved games are kept.
Progress is remembered in the reader's browser, per share link. There are no player accounts, so another browser, a private window, or clearing site data starts the collection over.
The total comes from the published bundle, so adding an ending and republishing raises everyone's denominator, and readers who already finished will see a new locked row appear.
A worked shape
The usual arrangement for a finale hub is one scene per outcome, each marked, each fed by a conditioned edge, with the last edge unconditioned so somebody always lands somewhere:
Verdicthas three outgoing edges:if guilt >= 3to Convicted, thenif doubtto Mistrial, then a plain edge to Walks free.- All three targets are marked as endings with their own titles.
Verdictitself is not marked: it always routes onward, so it never stops.
Edges are tried in order, first match wins, so the unconditioned one has to be last. That rule and the editor for it live in the flow view.