ScryMaster Docs

A worked example

Two things a first-time AI author needs: a real pattern to learn from, and one tiny end-to-end loop to imitate. Here is both — the signature companion chain we already ship, then a minimal skeleton you can build in minutes.

The signature pattern: a companion who matters (the “Mira chain”)

This is the relationship-domino recipe made concrete — the reason a ScryMaster companion feels different from a portrait with dialogue. It is one relationship variable read at four beats:

  1. The bond (influence beat). A quiet choice/dialogue moment raises a relationship variable — say mira_trust. Small, early, optional.
  2. The rescue (assist beat). Later, a skill check the companion can step into (allyAssist) — but only if the bond was built. The player feels the trust pay off at a tense moment, not in a menu.
  3. The fight (combat beat). The companion joins the encounter as an ally — again gated on the relationship. An earned sword, not a scripted one.
  4. The parting (payoff beat). A stay-or-leave scene whose DC bends on mira_trust (a dcAdjust), and whose ending text differs by whether the bond held.

Why each mechanic earns its place: the variable is written once and read three times — that is the difference between a flag and a character. The DC adjustment makes the relationship mechanically real (not just flavor). The combat ally makes it visible. The ending callback makes it remembered. Hand-wired this is 90–150 actions; as the relationship-domino recipe it is one stamp you then rewrite in your own voice. Run get_world afterward and you’ll see Mira as a companion card with her relationship variable and every beat she touches.

The one-loop skeleton (copy this shape)

The smallest thing that proves the whole loop. Not a campaign — the shape of success:

  1. Premise: “A traveler shelters from a storm in a haunted mill.”
  2. Blueprint: 5 beats, 2 endings, 1 durable variable (trusted_the_ghost), 1 payoff.
  3. Beats: (1) arrival scene → (2) a dialogue with the mill’s ghost with a help-or-refuse choice that sets trusted_the_ghost → (3) a skillCheck to survive the night → (4) an optional search beat that reveals the ghost’s story → (5) an ending.
  4. Payoff: the ending reads trusted_the_ghost: trust it and the ghost lifts you out at dawn (a warm ending); refuse and you claw out alone (a grim one). Same beat, two remembered outcomes — a braid, not a fork.
  5. Read the loop: validate → 0 errors; simulate → both endings reached, 0% deaths, no never-visited beats; get_health → the variable is written-and-read (no unpaid-setup lint); get_world → the ghost shows as a speaker.
  6. Revise: if simulate shows only one ending reached, the choice isn’t really gating the payoff — fix the gate, not the prose.
  7. Dry-publish → publish.

That skeleton hits every bar in the quality metrics: a durable variable written then read, a real optional beat, a state-dependent ending (not just a last-click branch), and a clean validate/simulate. Scale the same shape up — more acts, a companion via relationship-domino, a town with a store and a quest-board — and you have a rich campaign built the same way, one reactive beat at a time.

Back to the playbook · or the MCP quickstart.