This proposal covers pipeline step 3 — Configure mechanics. Today the mechanic configuration form in builder-editor.tsx is a single flat grouping with no mechanic-specific panels, no variant diff against the base game, and no inline guidance about how a field change affects RTP or volatility. This stub captures the problem, sketches one wireframe, and lists the open questions that must be resolved before a full proposal can be written.
Config editing exists today in apps/web/src/views/builder-editor.tsx, which renders a form generated from a template's fields array grouped by field.group. For Crash the groups are Betting, Math & RTP, and Timing; Trunk Raider adds a fourth group, Bonuses. However the form presents all groups as one flat scroll — there are no mechanic-specific panels that collapse irrelevant sections or surface the most impactful controls first.
When a builder is working on a variant, none of the fields show which values were inherited from the base game and which have been overridden. The only diff signal is that diffFromDefaults (in builder-editor.tsx) silently excludes unchanged fields from the saved GameSpec — it is invisible to the builder. Furthermore, range-type fields such as winMultiplier {min, max} on Trunk Raider have no guidance about how the pair of values drives expected value; adjusting one end without understanding the relationship can produce an unintended RTP shift with no warning.
The config editor becomes a set of collapsible mechanic-specific panels — one per field group — with a persistent "changed vs base" rail on the right that lists every field that diverges from the base game's defaults. A Math-impact note appears inline beneath any field whose change is detected as affecting RTP or volatility.
minBet > maxBet); field highlighted in red; save CTA blocked.| File | Change |
|---|---|
apps/web/src/views/builder-editor.tsx |
Replace the flat grouped form with collapsible per-group panels; add a diff-rail component that compares live config values against base-game defaults; wire inline Math-impact annotations to the Math & RTP and Bonuses groups. |
packages/shared/src/templates.ts |
Field definitions may need an impact annotation (e.g. "rtp" | "volatility" | "timing" | none) so the editor can decide which changed fields warrant a Math-Sim prompt without hard-coding field keys. |
Today, a builder moves from step 2 to a flat config form with no context about what they inherited from the base game or what their changes mean for math. After this proposal, step 3 presents grouped panels with a persistent diff rail that makes inherited vs overridden values visible at a glance, and an inline Math-impact signal that prompts a Math-Sim run before the builder advances to step 4.
templates.ts (e.g. houseEdge, minCrashPoint) directly set certified math parameters. Should external builders be permitted to change these, or are they locked and surfaced read-only? This affects whether the diff rail can show a change or only show inherited values for those fields.winMultiplier {min, max}) render? The current form handles them as two separate number inputs (see builder-editor.tsx case 'range'). The proposal sketch shows them paired with an EV-shift note, but the calculation method (mean of min/max, full simulation, or lookup) is not decided. The implementation of inline Math-impact notes depends on this.Once the open questions above are resolved, the mechanic-setup form can be specced in full. The next stub in this reading order is Proposal 03 · Package Checklist, which covers the manifest, assets, copy, and jurisdiction state that must be assembled alongside (and after) mechanic configuration.