Workflow · mozg/stake-engine-game
A Stake Engine slot game, end to end
Concept, math, books, RGS, front end, motion, art, compliance, then the publish gates — each step on the brain that knows it.
The route is free — it is the order the reading happens in, and charging for an order is charging twice. What costs money is the shelf under it, and most of that comes as a pack, which is cheaper than the same brains bought one at a time.
Run it from any agent with mozg connected
/mozg:build mozg/stake-engine-gameIt will not run until every brain below is open to you. A step whose brain is missing does not stop — it answers from the model's own training in this route's voice, which is the failure the route was written to prevent.
The shelf this route needs
Your agent reads these as it goes, so the route is held closed until all of them are open to you. One missing brain does not stop a step — it makes the step guess, and a guess wearing this route's authority is worse than no route at all.
The route, step by step
- 1
Concept, theme and the one-page spec
reads mozg/slot-design-presentation · 92%
askscore loop, feature set and volatility profile that read as market-competitive; what a slot's spec must state before anyone builds it
rulesNothing is written into code in this step. The output is one page the whole route is judged against: theme, reel layout, pay system, features, target RTP, target volatility and max win. Name the competitor titles it stands against — a spec with no comparison is a wish.
done whenthe spec states RTP, volatility, max win and every feature, and the user has agreed to it
- 2
Math model and modes
reads mozg/stake-engine-math-sdk · 91%
askshow a game's modes, criteria, win caps and distributions are declared in the math SDK, and what run.py must produce
rulesNever hand-tune a paytable outside the config the SDK reads. Every mode in the spec exists here, buy-bonus included if the spec has one. Do not invent SDK field names — search the brain for the exact ones.
done whenrun.py completes and the simulated RTP for every mode is within 0.1% of the spec's target
- 3
Books, lookup tables and optimization
reads mozg/stake-engine-math-sdk · 91%
askswhat create_books() writes, what the lookup tables contain, and how the optimization algorithm adjusts weights toward the target payout characteristics
rulesNever hand-edit a generated book. The payout multiplier in a book and in its lookup table row must agree for every simulation id — a mismatch survives local eyes and fails review. library/publish_files/ is the only thing that goes to Stake Engine.
done whenlibrary/publish_files/ exists for every mode and its lookup tables reproduce the target RTP
- 4
Math against Stake's own requirements
reads mozg/stake-engine-approval · 82%
asksthe math requirements a game must meet: RTP range, max win, hit rate, volatility and the simulation criteria reviewers check
rulesThese are Stake's numbers, not the studio's taste. Where the spec and the requirement disagree, the requirement wins and the spec gets amended — discovering this after the front end is built costs the front end.
done whenevery number in the math requirements page has a measured value from the simulation beside it
- 5
RGS lifecycle and replay
reads mozg/stake-engine-rgs-api · 91%
asksauthenticate, play and end-round: the exact call order, bet validation, microunit amounts, and what replay has to reproduce
rulesAmounts are microunits on the wire and formatted only at the edge. Every state the RGS can return has a handled branch — a dropped connection mid-round must not lose the round.
done whena full round completes against the RGS and the same round replays identically from its book
- 6
Front end and the event contract
reads mozg/stake-engine-web-sdk · 78%
asksthe web SDK's state machine, how book events reach the front end, and which events a round emits
rulesEvery event the books can emit has a handler before any of it is made pretty. An unhandled event is a frozen game, not a missing animation.
done whenevery event kind present in the books is handled, and an unknown event fails loudly in development
- 7
Rendering
reads mozg/pixijs-casino · 69%
asksPixiJS 8 application setup, sprite and texture lifecycle, and the render patterns a reel grid needs
rulesPool the symbols, allocate no texture per spin, pause the ticker on a hidden tab, and destroy the scene graph on mode change. Static files only — the build has to be uploadable as-is.
done whena long session shows no memory growth and the mid device profile holds its frame rate
- 8
Motion and win presentation
reads mozg/slot-animation-craft · 82%
asksspin and stop timing, anticipation, the win tier ladder and how a bonus entry is choreographed
rulesNever animate CSS filters. Every celebration is skippable, and the tiers are visibly distinct — a mega win that looks like a small one is the most expensive defect in presentation.
done wheneach win tier reads differently on a muted phone, and every sequence can be skipped
- 9
Art direction, tile and assets
reads mozg/slot-art-direction · 88%
askssymbol hierarchy, palette and lighting for this theme, and what separates premium symbols from low pays
rulesOne visual language across symbols, background and UI. The game tile is a separate deliverable with its own asset spec — background, foreground and provider logo — and it is checked at approval, so it is made here rather than remembered at the end.
done whenthe symbol set reads as one game, the tile assets match their spec, and the bundle is inside its size budget
- 10
Frontend requirements, compliance and locales
reads mozg/casino-compliance-locales · 94%
asksrequired disclosures, social-casino wording, RTP and max win statements, and which locales and currencies the game must carry
rulesNo wording that implies a real-money outcome where the jurisdiction forbids it. Every user-facing string goes through i18n — one hardcoded English label is a failed locale check. Rules, paytable and game disclaimer are required screens, not extras.
done whenrules, paytable and disclaimer render in every shipped locale, with RTP and max win stated
- 11
The approval checklist, item by item
reads mozg/stake-engine-approval · 82%
asksthe interactive approval checklist: its sections — pre-checks, game tile, math, RGS, frontend, jurisdiction, replay, sign-off — and what each item demands
rulesWalk the real checklist at /docs/approval/checklist and answer every item with evidence: a file, a number, a screenshot. Never mark an item done because it looks fine. Games below an average of one star are not approved at all, so the quality rankings are a gate and not advice.
done whenevery checklist item has an answer with evidence, and none is outstanding
- 12
Upload and submit
reads mozg/stake-engine · 57%
askswhat the Admin Control Panel accepts, the static-file requirement, and how a finished game is submitted for review
rulesUpload the built static files and library/publish_files/ — nothing else. Submit only a finalized game: a submission is a review request, not a save point. Do not claim an upload or a version happened without the panel showing it.
done whenthe ACP shows the uploaded files and the game is submitted for review
Write your own route.
The order your team already works in, written down once, runnable from anyone's terminal.