Standout Builder Studio · planning Index / The walkthrough review Updated 12 Jun 2026

The walkthrough: idea → playable on the edge

This page walks through the canonical eight-step flow for building a game in Builder Studio — from choosing a build path to promoting a build toward operator handoff. Each step explains what you are trying to do, shows an inline mock of the relevant screen, and tells you what already exists versus what this suite proposes. Background agents handle the engineering work at each step; humans approve at gates. The target end-state is a playable game session on Cloudflare's edge with little to no engineering engagement per title.

---

Step 1 · Choose build path

Before any configuration can happen, the builder must decide what kind of game they are making. The five build paths are: new game from scratch, config-only variant of an existing title, theme-only reskin, mechanic prototype, or import of an existing third-party game. Each path determines which subsequent steps are required and which can be skipped — a reskin, for example, inherits all config and jumps straight to assets and theming, while a new game traverses every step. One "Add a game" entry point funnels every path through this screen.

Agents at this step

The Scaffolder is primed at this step: once a path and template are confirmed it will generate the variant folder skeleton into standout-games. For the Import path, the Info-Sheet agent begins extracting manifest fields, math targets, and paytable structure from uploaded screenshots and PDF documents before the builder proceeds.

---

Step 2 · Define the game package

The game package definition is the identity contract for a build: the variant name, mechanic type, format, target devices, jurisdiction scope, RTP/volatility/max-win targets, and whether the initial intent is an operator sandbox or a full handoff. The package also records who the build is for — an operator handoff or an internal demo — so downstream steps and collaborators know the delivery context from the outset. This information seeds the GameSpec and drives everything downstream — particularly the asset checklist thresholds (step 4) and the jurisdiction gate in validation (step 5). Getting these values right early avoids rework; the Math-Sim agent will later verify that configured mechanics can actually hit the stated targets.

Agents at this step

The Info-Sheet agent can pre-populate this form if the Import path was chosen — it extracts name, mechanic, RTP targets, and jurisdiction scope from a PDF or screenshot set. For all paths, the Math-Sim agent is scheduled to run a preliminary feasibility check once the mechanic config is complete in step 3.

---

Step 3 · Configure mechanics

Each template exposes a schema-driven set of configuration fields grouped by concern: betting limits, math and RTP levers, timing parameters, and bonus thresholds. For a variant or reskin, only fields that differ from the base are stored — the rest inherit. The key distinction here is that some fields directly affect the RTP, volatility class, or max-win outcome, and the builder needs to know that when they touch them. An inline note on each math-touching field states "changes RTP", "affects volatility", or "shifts max-win" so intent is clear.

Agents at this step

The Math-Sim agent is the primary actor: it consumes the saved config and produces an RTP/volatility simulation report as a proof artefact. Changes to math-touching fields trigger a new queued sim run. The Scaffolder is also watching: it will regenerate the variant scaffold if the template or base-game reference changes.

---

Step 4 · Attach assets & theme

Not every asset is required to reach a playable sandbox — the distinction between "good enough for sandbox" and "required for operator handoff" is critical and must be explicit. A lobby tile placeholder allows a sandbox session to launch; the real operator lobby tile is only blocking at the handoff stage. This step renders a checklist with two columns: what clears the sandbox gate and what must be complete before a build can be promoted to operator demo or certification.

Agents at this step

The Asset agent processes uploaded files: it resizes lobby tiles, runs safe-area checks against mobile operator lobby grids, and produces derived outputs for human art-owner approval. The Copy/Localisation agent generates draft help text and operator copy from the spec and paytable, producing locale variants where jurisdiction scope includes multiple languages. The full prompt-to-artefact flows are mapped in the generative AI map.

---

Step 5 · Run validation

Validation runs a set of gates against the current build state and returns a pass / warn / fail result for each. Blockers must be resolved before the build can proceed to sandbox launch or promotion. The key affordance here is "Do it for me": non-pass gates include a button that dispatches the appropriate background agent to fix the issue, with a parallel "Explain" button that gives the builder the reasoning in plain language. This transforms validation from a report into an action surface.

Agents at this step

The Validation agent runs gates and produces fix-next recommendations — it is the only read-only agent in the roster. "Do it for me" buttons route to the correct specialist: Math-Sim for RTP proof, Asset for missing or failing art, and Copy/Localisation for missing help text or locale gaps.

---

Step 6 · Generate playable sandbox

The sandbox session composer lets the builder specify the parameters of a test session — operator, player profile, currency, device, jurisdiction, wallet behaviour, and expiry — and launch a real signed URL into the sandbox dispatch namespace on Cloudflare (the routing layer that runs each game's Worker at the edge). The resulting session is live: events stream in, logs are captured, and a replay bundle is available afterward. This is the moment where the build transitions from specification to running software.

Agents at this step

Deployment is owned by the Deploy agent: it deploys the merged build to the sandbox dispatch namespace and runs a smoke test, with automatic rollback on failure and a human gate only on promotion. The Validation agent runs a post-launch sanity check once the first session events arrive.

---

Step 7 · Iterate

Real game tuning is cyclical: run a sandbox session, observe the behaviour, adjust config, re-validate, re-launch. Builder Studio tracks every version of a build so the builder can see what changed between v0.1.9 and v0.2.1, why validation moved from Warn to Pass on one gate, and how sandbox session outcomes shifted. The version timeline and compare drawer are the primary tools here — they turn an otherwise invisible tuning loop into a traceable record.

Agents at this step

The Math-Sim agent is re-triggered on every config save, so each new version has an associated sim result for comparison. The Validation agent maintains a per-version gate run history so the builder can see exactly when and why a gate moved from Warn to Pass or vice versa.

---

Step 8 · Promote toward handoff

Promotion is the controlled movement of a build up a stage ladder: prototype → internal → review candidate → operator demo → certification package. Each stage transition requires the relevant blockers to be cleared. The goal is that only real blockers gate promotion — not paperwork bureaucracy. The Cert-Pack agent assembles the certification evidence bundle once the build reaches the certification package stage.

Agents at this step

The Cert-Pack agent assembles the certification evidence bundle on promotion to the certification package stage, requiring compliance-owner approval before the bundle is finalised. The Deploy agent handles the operator demo deployment with a human gate on promote — it auto-rolls back on smoke test failure.

---

Where Builder Validation went

The navigation sidebar in apps/web/src/components/ui.tsx at line 241 contains the entry:

{ id: "builderValidation", label: "Builder Validation", icon: "cert" },

This sidebar item points at the route /builder-validation, a page that does not exist. No view, component, or route handler for builderValidation exists in apps/web/src/. The decision taken in this planning suite is: do not create a standalone Builder Validation page. Instead, validation is folded into Builder Studio as the Step 5 panel (described above), surfaced per-build inside the GameWorkspace, and summarised in the aggregate validation ring on the studio dashboard. Validation is not a separate destination — it is a state of a build.

---

How a build becomes a pipeline game

Builder Studio is the zoomed-in view of the build stage of the existing Standout pipeline. The pipeline has four macro stages: concept → build → cert → live. Builder Studio owns the entire "build" stage — from path-picker through to a certification package that the cert stage consumes. Once a build is promoted to the certification package stage and the Cert-Pack agent produces the evidence bundle, the record joins the main pipeline view as a normal game entry moving toward cert and live.

The join point is the stage field on the build record. When Builder Studio promotes a build to "certification package", a new entry appears in the main pipeline games table at the "cert" stage. The game's GameSpec provides the source of truth for config, assets, and math proof; the pipeline view adds the operator and jurisdiction deployment records that Builder Studio does not manage.