Standout Builder Studio · planningIndex / Flow / 01 · Build Path PickerreviewUpdated 12 Jun 2026
Proposal 01 · Build Path Picker
Every game in Builder Studio begins at a choice. This proposal specifies the path-picker screen — the single entry point that asks a builder what kind of game they are making before a single config value is touched. It replaces three disconnected "add a game" surfaces with one intentional funnel.
1 Choose build path2 Define the game package3 Configure mechanics4 Attach assets & theme5 Run validation6 Generate playable sandbox7 Iterate8 Promote toward handoff
User problem
Today, "add a game" means three different things depending on where you are in the dashboard, and none of the three routes by intent:
The pipeline game editor (apps/web/src/components/game-editor.tsx) creates a pipeline card — a development-pipeline entry tracking title, format, stage, and ownership. It opens via window.sgNewGame(stage?) and writes to window.PIPELINE.store (localStorage). It has no concept of a build path, template, or game spec.
The Builder Studio template gallery (apps/web/src/views/builder-hub.tsx, rendered at /builder) shows three certified templates from packages/shared/src/templates.ts — Crash, Trunk Raider, Silk Road — with a "Build on this" button that routes to /builder/new?template=<id>. The builder's next action is configuring a GameSpec in views/builder-editor.tsx, but there is no moment that asks "what are you trying to do?"
The /builder/new config editor (apps/web/src/lib/nav.ts: builderNew route, params today limited to template and spec) jumps straight to configuring fields. It supports no path param, so there is no way to signal "reskin only" or "import existing" and suppress irrelevant config steps.
The result: a builder who wants to do a theme-only reskin of an existing game ends up in the same config form as one building a new game from scratch. An external builder has no guided way in at all — the three surfaces are internal-facing and provide no scaffolding around intent. There is no place that says "here are your five paths, here is how long each takes, here is what you can and cannot change."
Why this matters for external builders
The external Builder Studio product is the proposition we take out to studio partners. They will arrive with a game concept, not a template id. If the first screen asks them to pick a template rather than describe intent, we lose them before step 2. The path-picker is the first impression of the guided build pipeline.
Proposed UI
The path-picker screen replaces the template gallery at /builder as the entry point. A builder chooses one of five paths — Reskin, Tune, Variant, New game, Import existing — then optionally selects a base game to branch from (template or existing build). Only when both choices are confirmed does the primary CTA become active and route to step 2.
Choose a build path, then pick a base to branch from.
Reskin
Swap theme, art, and copy on a certified base. Zero config delta — the math does not change.
Unlocks: Asset & theme steps, operator copyLimits: No mechanic or config changes
hours
Tune
Adjust bet limits, timing, or volatility on an existing title. Math gate required before promotion.
Unlocks: Config overrides (non-mechanic fields)Limits: No structural mechanic changes
~a day · math gate
Variant
Full config diff from a base game. New mechanic parameters, bonus thresholds, and RTP targets — scaffold PR generated by the Scaffolder agent.
Unlocks: Full config form + mechanic stepLimits: Must share an engine plugin with the base
days · scaffold PR
New game
Design from a mechanic concept up. All eight steps apply. No certified base required — mechanic sourced from the library or proposed as new.
Unlocks: All steps, new mechanic proposalLimits: Math-Sim gate before any sandbox
a week+
Import existing
Upload screenshots and a PDF info sheet for a game already built elsewhere. The Info-Sheet agent extracts manifest fields, math targets, and paytable structure while you fill in context.
Branch from an existing buildGROUNDED · matches main
Crash Cartel
Multiplier crash · BLD-CC-074
v0.7.4
Neon Bounty
Bonus slots · BLD-NB-110
v1.1.0-rc2
Vault Runners
Instant win · BLD-VR-098
v0.9.8
Choose a path to enable this button
State variants
Five states cover the full interaction arc of the path-picker screen. With JavaScript enabled, use the tabs below to switch. With JavaScript disabled, all panels render stacked with their state labels — every panel starts with a visible label identifying which state it depicts.
State: empty — nothing chosen yet
empty — initial load, no selection
CONCEPT · proposed
Running · extracting manifest fields from uploaded documents
10:04:11Info-Sheet agentPDF parsed — 4-page info sheet detected. Extracting game name, math targets, and paytable.
10:04:14Info-Sheet agentRTP target found: 96.5% — confirmed against paytable summary on page 2.
10:04:17Info-Sheet agentMechanic type unclear — "pick-3 multiplier" referenced but no plugin match. Flagged for human review.
Extracted fields
Game nameNeon HaulHigh
RTP target96.5%High
Max win5,000×Medium
Mechanic typeno match — review neededLow
You can proceed; low-confidence fields remain editable in step 2.
State: done — path + base confirmed, routing to step 2
done — handoff to step 2
CONCEPT · proposed
Path confirmedHeading to step 2 · Define the game package
Your choices have been recorded. The builder will now prompt you to name the game, set targets, and confirm device and jurisdiction scope before configuration begins.
What is passed forward:buildPath and baseGameRef are written to the GameSpec record (see affected files). The config editor at /builder/new reads these from the route params to pre-select the template and suppress irrelevant config steps.
Affected current files
These are the files that need to change to implement this proposal. All paths are relative to the repo root on main.
File
Change
apps/web/src/views/builder-hub.tsx
Entry point becomes the path-picker screen. The current template gallery and "Your builds" panels move inside the picker as the two "branch from" galleries. The BuilderStudioDashboard sub-component is retained below the fold for the studio overview.
apps/web/src/lib/nav.ts
The builderNew route handler grows a path param (e.g. ?path=variant&template=trunk-raider). The config editor reads this param to determine which steps to surface and which to suppress for the chosen build path.
packages/shared/src/templates.ts
Template manifests gain path-compatibility metadata: a compatiblePaths array ("reskin" | "tune" | "variant" | "new") and an optional pathNotes record. Used by the picker to filter or annotate the template gallery when a path is chosen.
apps/web/src/lib/specs.ts
The GameSpec type (and its persistence layer) grows two new fields: buildPath (the chosen path key) and baseGameRef (template id or existing build id). Both are set at path-picker completion and passed through to subsequent steps.
Not changing
apps/web/src/components/game-editor.tsx — the pipeline game editor is a separate surface (pipeline-card creation, not spec-based builds). This proposal does not consolidate the two. That is a larger architectural decision logged in the open questions below.
What changes in the build flow
Today a builder encounters three disconnected entry points, none of which routes by intent. After this proposal they encounter one funnel — "Add a game" — which routes through the path-picker before anything else.
Today — three disconnected entries
GROUNDED · matches main
Pipeline editor
game-editor.tsx · creates pipeline card only
Template gallery
builder-hub.tsx · starts a GameSpec directly
Config editor
/builder/new · no path param, no intent signal
A builder who wants a reskin follows the same path as one building a new game. No guidance. No time estimate. No filtering.
Reskin · Tune · Variant · New game · Import — with estimates
↓
Guided steps 2 → 8
Only the steps relevant to the chosen path are surfaced
A reskin builder sees hours-to-playable and skips the math step. A new-game builder sees the full eight-step ladder. Each path is honest about what it costs.
Open questions
Decisions needed before implementation
Import path — info sheet required up front?
Does the Import path require a PDF info sheet before the builder can proceed, or can they start with screenshots only (or a free-form description) and defer the info sheet upload? The extraction quality difference is material — PDF gives structured fields with high confidence; screenshots alone push mechanic-type confidence to low. This needs a usability decision before the agent's input contract is finalised.
External builder path visibility.
At launch, do external builders see all five paths (Reskin · Tune · Variant · New game · Import), or do we surface only Reskin and Tune to reduce decision paralysis and reservation of engineering capacity? New game in particular implies a scaffold PR that requires internal engineering review — surfacing it for external builders day-one may create support load before the Scaffolder agent is fully reliable.
Mechanic prototype placement.
The vision doc references a "mechanic prototype" path (not for cert, mechanic exploration). Today this is not one of the five named paths. Should it surface as a variant of New game (laxer gates, no cert runway, fast Math-Sim loop), as a sixth card, or as an advanced toggle within the New game path? Calling it out separately avoids confusion with production-bound builds; folding it in keeps the picker clean.
What to tackle next
The picker's done state hands the builder directly to pipeline step 2 (Define the game package), where they name the game, set targets, and confirm device and jurisdiction scope — that walkthrough lives in vision.html · step 2. The next proposal in this cadence is Proposal 02 · Mechanic Setup, which covers pipeline step 3 (Configure mechanics): how path context drives the mechanic configuration form, how variant diffs are surfaced against the base game, and how the Math-Sim agent integrates as a live RTP advisor during configuration.