Same flow, different UI personalities — each key Builder surface is rendered three ways so we can choose deliberately instead of defaulting to the first sketch. The journey simulator answers "does the flow feel right"; this page answers "which treatment of each screen". Every panel here is a CONCEPT · proposed mock; two variants additionally carry a tag because working code for them already exists on an unmerged branch.
Three Builder surfaces are treated below — choosing the build path (step 1), configuring mechanics (step 3), and validation & readiness (step 5). Each surface gets three variants (A / B / C) shown side by side, a trade-off table that scores them on five axes, and a recommendation. The variants are not ranked sketches; they are genuinely different bets on who the screen is for and how much it does for the builder.
The five scoring axes, each rated low · medium · high:
| Handholding | How much the screen guides a first-timer who does not know the domain. High = leads by the hand; low = assumes you know what you want. |
| Expert speed | How fast a fluent internal builder gets through it. High = nothing in the way; low = the guidance becomes friction. |
| Information density | How much state is visible at once. High = everything on screen; low = one thing at a time. |
| Build cost | Engineering effort to ship the treatment. High = expensive (new estimators, live sims); low = mostly layout. |
| GenAI leverage | How well the treatment exploits the generative-AI touchpoints. High = the model has an obvious seat; low = it is bolted on. |
The entry screen of the whole product — the first impression for an external Game Builder, and the daily front door for the internal studio. It asks what kind of game are you making before any config is touched. The proposal is specified in full at 01 · Build Path Picker; here it is one of three competing personalities.
Personality: browse-and-choose — every path and base visible at once.
Personality: maximum handholding, external-builder-first; slower for pros.
Personality: information-dense, internal-team-first — the consequences of a path are all on screen.
Variant C reproduces the BUILD_PATHS content and the five-stage FLOW_STEPS strip from the path-picker branch prototype verbatim. Note the honest mismatch: that prototype has 4 paths (New game · Variant · Reskin · Prototype) and a 5-stage Path→Handoff strip, whereas this suite's canonical flow has 5 paths (it adds Import / Tune and drops standalone Prototype into New game) across 8 steps. If C is chosen, that reconciliation is the first task — the strip would re-band onto the eight-step ladder and the path set would align with flow/01.
| Variant | Handholding | Expert speed | Info density | Build cost | GenAI leverage | Best when |
|---|---|---|---|---|---|---|
| A · Path cards | medium | high | high | low | medium | The default shell — a returning builder who scans options and goes. |
| B · One question | high | low | low | medium | high | First-run for an external builder who has a concept, not a template id. |
| C · Rail + detail | medium | high | high | medium | low | Internal studio deciding scope — what a path inherits vs owes matters most. |
The numbers screen — where a builder sets bet limits, math levers and bonus thresholds, and where a wrong value quietly changes the RTP. Today's /builder/new form is a grouped field editor; the three treatments below differ on how loudly they teach cause-and-effect and how much the model drafts for you.
Personality: spreadsheet honesty — every field and every delta laid out plainly.
Personality: genAI-forward, fastest to a draft; risk is trust and prompt literacy.
Personality: feels alive, teaches cause-and-effect; needs a cheap client-side estimator or debounced sim.
Amber zones mark out-of-band values; estimates are advisory until a Math-Sim proof confirms them.
| Variant | Handholding | Expert speed | Info density | Build cost | GenAI leverage | Best when |
|---|---|---|---|---|---|---|
| A · Grouped + diff | low | high | high | low | low | The floor — a builder who knows exactly which field to change. |
| B · Intent first | high | high | medium | medium | high | Drafting fast from a goal in plain language — proof comes after. |
| C · Impact cockpit | high | medium | high | high | medium | Teaching cause-and-effect — seeing a lever move the RTP in real time. |
The "is it ready" screen — gates that return pass / warn / fail and, in the proposal, let a builder dispatch an agent to fix a failing one. The three treatments differ on whether you see every gate, a single motivating number, or just the next thing to fix.
Personality: the canonical surface — full pass/warn/fail list, fix in place.
Personality: glanceable, motivating, exec-friendly; risk is a single number hiding which blocker matters.
Personality: maximum momentum, very handheld; risk is hiding the full picture from power users.
| Variant | Handholding | Expert speed | Info density | Build cost | GenAI leverage | Best when |
|---|---|---|---|---|---|---|
| A · Gate list | medium | high | high | medium | high | The working surface — see every gate, fix any one in place. |
| B · Scorecard | medium | medium | medium | low | low | A dashboard glance — "how close is this build" across many games. |
| C · Blocker queue | high | low | low | medium | high | Mobile or an external builder who wants the next step, not the report. |
origin/feat/builder-studio-path-picker-mock (Surface 1 · C) and origin/feat/builder-studio-readiness-grounded (Surface 3 · B). Once a direction is chosen, each should be either promoted into the chosen treatment (path-picker → the flow/01 shell with C's drawer; readiness → the GameWorkspace summary band) or closed so they don't linger as ambiguous half-states. They are concept mocks in this suite, but working code exists — leaving it un-dispositioned is its own kind of debt.The summary of the three recommendations, and the cheapest way to confirm each before committing engineering time.
| Surface | Recommended direction | What to prototype next | Cheapest validation |
|---|---|---|---|
| 1 · Build path | A as the default shell; B as the external first-run; C's detail folded into A as a drawer. | The "what this path means" drawer on an A card, using C's inherits/required/gates content. | Builder interview — watch 2–3 builders pick a path cold. |
| 3 · Mechanics | Sequence A → C → B; they compose (intent drafts the edits the others render). | C's client-side RTP/volatility estimator — the gauge accuracy is the whole bet. | Simulator run — check estimator output against a real Math-Sim proof. |
| 5 · Validation | A as canonical; B as the dashboard summary band above it; C as the mobile/external mode. | The composed B-over-A layout in GameWorkspace — promote the readiness branch. | Branch promotion — the readiness prototype already renders; trial it in workspace. |
The division of labour is deliberate: the journey simulator plays the journey end to end, this page picks the individual screens, and the flow/01–06 proposals then get updated to the chosen treatment — keeping those proposals in step with the decisions made here is the planning cadence's job, not a one-off edit. For where this sits in the wider plan, see the mind map's Guided-flow branch.