Scene rendering — the pipeline

A Scene is one markup-centric Scene source — Markup, with Bindings and Logic embossed from it. Scene rendering is how that one source becomes what a person actually sees and does. It is not a single renderer you reach for; it is a process — a defined pipeline that runs over the Scene source every time the Scene is drawn, both while you preview it and while it is played.

Scene rendering is a pluggable rendering process — a pipeline that parses the Scene source, resolves Bindings, runs Logic, transforms the markup, and draws it through an engine — invoked while previewing and playing. It is curated, not user-authored; a Mode targets a rendering, and Slides is the slides rendering of the same Scene source.

---

One Scene source, one process, many engines

The Scene source is the canonical material a Scene is made of. Rendering is what turns that material into the real experience. Different renderings draw the same source differently — prose with interactive choices, or a slide deck — but a rendering never changes what the source is.

This is the point to hold onto: Slides is not a different kind of document. It is the same Scene source run through the slides rendering. The way you author may differ, but underneath it is one Scene source — the same Markup, Bindings, and Logic — drawn by a different engine.

---

The pipeline, step by step

The spine of the pipeline, in one line:

parse the Scene source → resolve Bindings (read state) → run Logic (the effects that write state) → transform the markup → draw it through an engine.

This is the current shape of the pipeline. It runs in two phases: a one-time init when a scenario starts, then a per-Scene tick that repeats at every Scene the player reaches.

Init (scenario start). Load the scenario, validate it at the import gate, set every fact to its default, and open the Playthrough log.

The per-Scene tick — each time the player arrives at a Scene:

1. Enter — record the arrival in the log.
2. Run on-enter Logic — the when you arrive rules fire; their effects write Memory and update Content and Context. State advances.
3. Resolve Bindings — read the current state into the markup. (Bindings only read; Logic is the only writer.)
4. Transform the Scene source — parse and normalize the markup (Markdoc plus the safe HTML subset) into a render tree.
5. Draw through the engine — the targeted rendering draws that tree: prose with interactive choices for the default rendering, a deck for Slides, and so on. The Scene is presented.
6. Await the player — they choose, answer, or input.
7. Run on-choice Logic — the chosen rule’s gate and effects run, writing state, and the choice is recorded in the log.
8. Route — follow the path to the next Scene (back to step 1), or settle on a terminal outcome.

A shared core and a swappable engine

Steps 2–3 and 6–8 are the shared runtime — Logic, state, Bindings, and routing — identical under every rendering. That is what keeps state the same no matter how a Scene is drawn: there is no per-rendering translation of Memory, Content, or Context. Steps 4–5 — transform and draw — are the swappable part each rendering owns. Moving a Scene from the default rendering to Slides swaps those two steps, and nothing else.

---

Preview and play — one process, two moments

The same pipeline runs in two moments.

• Play runs the whole loop and appends to the Playthrough log — the single source of truth, so a run can be replayed exactly.
• Preview runs the drawing steps over the current state without committing to a path or writing the real log. It shows the Scene as it would render right now.

Same process, two moments — the way a game engine draws a scene both in the editor viewport and at runtime.

---

Pluggable, but curated — the asymmetry with Modes

Renderings are pluggable: Cynario ships its own default rendering and can add others (the slides rendering today; more later). But they are curated, system-level pipelines — not something an author writes. Even an advanced author does not author a rendering process.

That is the load-bearing asymmetry with Modes. A Mode — how you author a Scene — is a registry, eventually user-extensible. A rendering process is not. Authoring is open; rendering is curated.

Concept	Author picks it?	User-extensible?	What it governs
Scene source	edited — it is the material	—	the canonical Scene data
Mode	yes — one choice per Scene	eventually (a registry)	how you author and which rendering it targets
Scene rendering	no — it rides with the Mode	no — curated pipelines	how the Scene source is drawn and played

---

A Mode targets a rendering

The author makes one choice — the Mode — and the rendering rides along with it. A Mode is paired with the rendering it targets, so rendering is never a second, competing toggle the author has to set.

Decision, Quiz, and Custom differ mainly in how you author; they share the default rendering. Slides is the Mode that also swaps the rendering: the same Scene source, drawn by the slides rendering (built on SlidesNG) as a deck instead of prose. That is why Slides can feel like a different kind of document while being the same Scene source underneath — it is the one Mode that changes the render, not just the authoring.

At the Custom floor — the Scene source authored directly — rendering can become an explicit, advanced concern. Everywhere else, you never choose a rendering on its own; you choose a Mode, and the rendering follows.

---

Why this shape

This mirrors tools authors already know. In Quarto and Pandoc, one source document is authored once and rendered to whatever you target — a web page, a reveal.js deck, a PDF — and slides are a render of the same source, not a separate source type. In a game engine, scene data is drawn by one render pipeline used both in the editor viewport (preview) and at runtime (play). Cynario’s Scene rendering is the same idea: one Scene source, one pipeline, several engines it can target.

---

In short

• Scene rendering is a process, not a renderer — a pipeline that turns one Scene source into the real experience.
• The spine is parse → resolve Bindings → run Logic → transform → draw through an engine, run as a one-time init and then a per-Scene tick.
• The pipeline has a shared core (Logic, state, Bindings, routing) and a swappable engine (transform + draw), which is why state is the same under every rendering.
• It runs in two moments — preview (no commit, no real log) and play (the whole loop, appended to the log).
• Renderings are pluggable but curated — not user-authored. That is the asymmetry with Modes, which are a registry and eventually user-extensible.
• A Mode targets a rendering, so the author makes one choice. Slides is the same Scene source drawn by the slides rendering (SlidesNG), not a different document type.

---

Where this fits

Scene rendering completes the picture the other concept pages paint — it is how the one Scene source is drawn and played:

• The mental model (start here) — the whole picture on one page.
• The Scene (the Scene source) — the one source this pipeline renders, and the Modes that target a rendering.
• Logic: triggers, conditions, effects — the WHEN/IF/DO rules the tick runs, and the three effect families (Memory · Content · Context).
• The truth model — the Playthrough log the pipeline writes while playing, and why preview can run without it.
• Reuse and the Workspace Library — the Logic Blocks and Components a Scene source is built from.