An approval is often treated as the finish line of a game project. On Engine it works more like a version lock. The submission that goes to review is not the idea, the art direction or the theme; it is one front build and one math build, inspected together as a single object. Once that object is approved, the commercial question changes from “what else could this game do?” to “what may still be changed without breaking the approved pair?”
This article sets out how Engine’s approval guidelines define that boundary: the version pair that is actually approved, the one category of post-release change the guidelines permit, the three categories they exclude, why the math file format makes those exclusions structural rather than bureaucratic, and how a publisher should scope a title’s update roadmap before the build is locked. It assumes the reader has already decided to commission an original Engine game rather than buy a licensed one.
Approval covers a front build and a math version together
Engine’s approval guidelines are explicit about what a review request contains: each request covers one front version and one math version, reviewed together. The team inspects the game for functionality, clarity, communication and technical performance. The description field on the submission form supplies a short blurb about the theme and mechanics, which may be used in promotional material and the game description tag.
That structure has a practical consequence for the brief and the handoff. The approved object is a pair of build identities, not a general permission to operate a game. The publisher should record which front build and which math version were reviewed, keep those artifacts archived and immutable, and treat the pairing as the reference point for every later change. If either side of the pair moves, the approved object no longer exists in the form that was inspected.
The guidelines also tell the submitter to make sure the game is finalised and ready for publication at the moment of the request. Approval is not a staging environment for iterative design. A team that submits early, planning to fix the maths or add a mode after launch, is treating the review as a design checkpoint; the guidelines treat it as a publication gate.
What the post-release rule permits and what it excludes
The post-release rule is short. Once a game has been approved for publication on Stake or Stake.us, only minor updates to address visual issues are permitted, unless the Engine team requests otherwise. Changes to the underlying math model, the addition of new game modes, or modifications to gameplay mechanics will not be allowed.
Read that as one narrow permission and three named exclusions:
- Permitted: minor updates that address visual issues.
- Excluded: changes to the underlying math model.
- Excluded: the addition of new game modes.
- Excluded: modifications to gameplay mechanics.
The distinction between a visual fix and a visual feature matters. Correcting a broken asset, an illegible label or a layout defect is the kind of change the sentence describes. Replacing the symbol set, adding an animated intro or redesigning the presentation of a feature is a visual change of a different order, and it may alter what the game communicates. Because the review covers clarity and communication as well as functionality, a copy or presentation change that affects what the player is told should be raised with Engine support before it ships rather than assumed to be cosmetic.
The same caution applies to rules text and translations. A corrected typo is one thing; a changed rule, a changed qualification or a new localized claim is another. These are questions to settle before submission, not after.
Why the math model sits inside the boundary
The exclusions are not arbitrary. They follow from how an Engine game is assembled. Engine’s math file format describes a game through an index file that lists every mode with its name, its cost multiplier, and the names of its game-logic and lookup-table files. The payout multipliers in the CSV lookup table must match the values in the game logic exactly, because those values are hashed during verification. The game logic itself is compressed JSON-lines in which every round carries an id, an events list and a payoutMultiplier.
A math change is therefore not a text edit to a document the reviewer read. It is a change to the hashed evidence that was reviewed. A new mode is worse than that: it adds an index entry, a lookup table and a game-logic file, and the approved index no longer describes the product. This is why “math model changes and new modes” cannot be waved through as minor updates — the approval was granted to a specific index and a specific set of hashes.
The stateless requirement reinforces the same boundary. Engine games are strictly stateless: each bet must be independent of previous outcomes, and games cannot include jackpots, gamble features, continuation or early cashout options. A design that depends on progress carried between rounds is outside the approved model, and no post-release patch can make it compliant. The constraint belongs in the brief, before art and engineering, not in a support ticket after launch.
There is also a ceiling to plan around. A game can have at most twenty modes, with exceptions for fantastic games handled through Support. Because modes cannot be added after approval, the initial index has to contain every mode the title may need for its commercial life. The twenty-mode limit is not only a technical maximum; it is a scoping deadline.
Treat the first submission as the title’s whole commercial life
The practical conclusion is uncomfortable for teams used to live-service thinking. If the maths, the mode set and the mechanics are frozen at approval, then the first submission is not version one of an evolving product. It is the product. Seasonal events, new bonus modes, mechanic variants and structural updates cannot be patched into an approved build; each becomes a new submission or a separate title.
That does not mean the game cannot be improved. It means the improvement has to be planned inside the approved envelope. Art polish, presentation fixes, clarity improvements and visual corrections remain available. Anything that changes the economy, the outcome set or the player’s decision space does not. A roadmap that assumes otherwise is not a roadmap; it is a list of future submissions that were never scoped or budgeted.
The brief should therefore separate two kinds of planned change before art lock. The first is visual maintenance: fixes and polish that can ship inside the approved pair. The second is structural evolution: modes, maths or mechanics that would require a new approval. Structural items belong in the first submission or in a sequel plan, not in a post-launch backlog. The submission package brief covers what the initial review needs, and the bonus mode scope brief covers how to define a mode boundary before engineering starts.
Questions to settle before the approval request
- The version pair: the exact front build and math version that will be submitted, and where both are archived.
- The complete mode list: every mode the title may need, each with its name, cost multiplier and file set, within the twenty-mode limit.
- The structural roadmap: which planned updates change maths, modes or mechanics and therefore cannot be post-release patches.
- The visual-only list: the fixes and polish that remain permitted after approval.
- The rules and localization state: final rules text and final translations, with any change that affects communication raised before submission.
- The acceptance owner: who signs off that the submitted front and math versions describe the same game.
None of these are unusual production questions. What makes them expensive when deferred is that the approval answers them once, together, and does not reopen them later. A team that settles them before art lock gets a clean approval and a realistic update plan; a team that leaves them to launch discovers that its roadmap requires new submissions it never scoped. A studio that builds Engine games will recognise the sequence. The brief is where it becomes affordable.
Frequently asked questions
What changes are allowed after an Engine game is approved?
Engine’s approval guidelines permit only minor updates that address visual issues after approval, unless the Engine team requests otherwise. Changes to the underlying math model, the addition of new game modes and modifications to gameplay mechanics are not allowed. The permitted category is narrow by design, because the review covers one front version and one math version as a pair.
Can a new bonus mode be added after approval?
No. Adding a mode means adding an index entry, a lookup table and a game-logic file, so the approved index would no longer describe the product. Every mode the title may need should be scoped and submitted before approval. The twenty-mode ceiling makes that decision a planning constraint rather than a later option.
Does a math-only change require a new submission?
Yes. An approval request covers one front version and one math version reviewed together, and the payout multipliers in the lookup table are hashed during verification. Changing the math model breaks the reviewed pair and falls outside the post-release permission. Plan the maths before submission rather than treating it as a launch-time adjustment.
Can rules copy or a translation be corrected after approval?
The guidelines name minor visual updates as the permitted category, and the review covers clarity and communication as well as functionality. A simple typo fix is different from a changed rule, a changed qualification or a new localized claim. Raise copy, rules and translation changes with Engine support before shipping instead of assuming they are cosmetic.
