A front build is judged on what a player can actually do with it. Engine’s review inspects the game for functionality, clarity, communication and technical performance, and the approval request covers one front version and one math version reviewed together. That sentence is the whole acceptance contract: the version you submit is the version that gets examined, and the front end is half of it.
This article turns Engine’s published approval guidelines into a sign-off list for the client. It covers what the review inspects, which assets are rejected before any code is read, what the interface has to disclose, the controls the platform expects, the small-view and mobile conditions, the bet levels that come from the session rather than the design, the network behaviour reviewers watch, and the quality threshold that sits above simple compliance. It assumes the reader is commissioning an original Engine game and wants the front build to arrive at review already finished.
The review inspects a front build and a math version together
Engine’s approval guidelines describe the review object precisely: each approval request covers one front version and one math version, reviewed together. The team inspects the game for functionality, clarity, communication and technical performance, and communicates issues case by case with the requested changes and the reasoning for approval or rejection.
Two consequences follow for a commissioning brief. First, the front build cannot be a moving target while review is in progress; whatever is submitted is what gets examined. Second, a front build that presents outcomes the approved math version does not contain is not a small discrepancy. What goes into a submission package covers the packaging side; this article covers what the client itself has to prove before the request is filed.
The guidelines are also explicit that approval is at the reviewer’s discretion. A game judged offensive, explicit, in poor taste or of insufficient quality may be rejected regardless of technical correctness. Compliance is the floor, not the target.
Assets have to be original and served from the platform’s CDN
The first rejection category is not functional. Games must use unique audio and visual assets: backgrounds, symbols and animations supplied with the web SDK’s sample games will not be approved. A build assembled from sample art fails before anyone plays it.
Games must also be original designs. Pre-purchased or licensed games already published on third-party sites are not permitted, and team names, titles and assets must comply with intellectual-property and copyright law. Assets cannot carry Stake branding or themes. The review is looking for a game that exists only on this platform.
Delivery has a matching constraint. Engine games must be uploaded as static files, and all images and fonts must be loaded from the Engine content delivery network. The strict cross-site-scripting policy means the build cannot reach external sources at all. Downloading a font from an external server is the common case, and it surfaces as console errors during review rather than as a silent degradation. Font and image hosting belongs in the build pipeline, not in the last week before submission.
The interface has to answer the player’s questions
The frontend requirements treat game information as part of the game. Everything below must be reachable from the interface:
- A detailed description of all game rules.
- Where more than one mode exists, a description of the cost of each bet and of the actions being purchased.
- The RTP of the game, stated for each mode where modes differ.
- The maximum win amount for each mode, clearly displayed.
- Payout amounts for all symbol combinations.
- Every obtainable value of special symbols such as cash prizes or multipliers.
- For feature modes, how the feature is reached — for example, three scatters award ten free spins and four award fifteen.
This is a disclosure list, not a marketing list. Each item is a fact the player is entitled to find before staking anything, and each one has to match the approved math version exactly. A paytable copied from an earlier build, or an RTP stated once for a game whose modes carry different values, is a presentation failure the review is designed to catch.
The controls a front build is expected to carry
The interface components are specified individually, which makes them easy to sign off one at a time:
- A user interface guide that briefly describes what each button does.
- The ability to change bet size, covering every bet level returned in the session authentication response.
- The player’s current balance, displayed.
- Final win amounts, clearly shown for every non-zero payout.
- Where an outcome contains several winning actions, a payout that increments to the final multiplier instead of jumping to it.
- An option to disable sound.
- The spacebar mapped to the bet button.
- If autoplay exists, a confirmation step — games may not place consecutive bets automatically from a single click.
None of these are optional polish. They are the difference between a demo and a client a player can operate without guessing, and each one is cheap to test and expensive to retrofit after the front version has been reviewed.
Small view and mobile are acceptance conditions
Two display conditions are stated as requirements rather than recommendations. The platform offers players a mini-player modal so a game can run in the background, and the game must support that small view without the active game board being visibly distorted. The game must also support mobile view on commonly used devices with all interface functionality still usable during screen scaling.
Both are failures of layout, not of logic, so they rarely appear in a functional test. A build that plays correctly at desktop width and loses its bet controls in the mini-player has not passed the frontend requirements. The practical acceptance step is to load the build at the small view and at mobile widths and operate every control, rather than to check that the page renders.
Bet levels come from the session, not from the design
The session authentication response returns the default bet levels, the supported bet levels for a specified currency, and the minimum and maximum bet amounts. The front end must respect those values. The guidelines give the failure mode directly: if the default bet size is one unit but the session uses a currency whose minimum bet size is ten units, the play request fails.
Bet increments must reflect the allowed values within the authenticated configuration, and the minimum and maximum levels must be selectable. A hardcoded bet ladder that happens to work in one currency is an acceptance risk in every other one. The rgs_url query parameter determines which server the client calls, so the build also has to read that parameter rather than assume an endpoint.
Localization belongs in the same test. English is the only required language, but if the build supports only English, on-screen text must not corrupt when other language parameters are passed. The review tests combinations of currencies and languages, and the play modal offers a social-mode setting for testing social languages, because games are considered for stake.us publication subject to strict language requirements.
The network tab is part of the review
The published checks include inspecting the network tab for errors and for game information being logged. A build that writes round data or player identifiers to the console leaves them in the browser, and the review reads the network activity as part of the technical assessment.
Playtesting follows the same logic: the reviewer plays the game to verify it behaves as the rules describe, including validating payout combinations. That makes the rules text and the build one artefact. If the rules promise a behaviour the client does not produce, the discrepancy is found during review rather than in a support ticket.
Where a fastplay option exists, win amounts, winning symbol combinations and pop-up information must remain legible to the player. Speed settings are one of the places where disclosure quietly degrades.
Quality sits above compliance
Passing the technical checks does not guarantee approval. Submitted games receive a quality ranking from zero to three stars, assessed by three anonymous reviewers who each choose from a fixed fractional scale in steps of about a third of a star. The three scores are averaged and rounded, and an average below one star is treated as below the minimum threshold regardless of rounding — an average of 0.67 does not become one.
The consequence of falling below the threshold is procedural: the approval thread is closed and locked, the game gets a seven-day improvement window, and it can be resubmitted for a new review cycle afterwards. That policy has been in effect since March 2026. It is not a permanent rejection, but it is a seven-day cost that a brief can avoid by treating polish as part of acceptance rather than as a later pass.
What to sign off before the submission goes in
The acceptance conversation belongs before the request, not after the review comment. A brief should settle:
- The submitted version pair: which front build and which math version go to review, and who confirms they are the pair being described.
- Asset provenance: confirmation that no sample-game art, audio or font remains in the build, and that every image and font is served from the platform’s CDN.
- The disclosure set: rules, per-mode bet cost, per-mode RTP, per-mode maximum win, the full paytable and the access conditions for each feature mode.
- The control inventory: each listed interface component, with the bet levels read from the authenticated session rather than a fixed list.
- The display conditions: mini-player small view and mobile scaling, each operated rather than only rendered.
- The network state: no console errors and no game or player information logged.
- The quality bar: what the build will be judged on beyond compliance, and who signs that judgement.
None of this requires new engineering. It requires that the acceptance list be written down while the build can still change. A studio that builds Engine games will already be testing most of these items; the difference is whether the operator receives the results as evidence or discovers the gaps in a review thread.
Frequently asked questions
What does Engine’s review actually inspect in a game?
Engine’s approval guidelines state that each approval request covers one front version and one math version, reviewed together, and that the team inspects the game for functionality, clarity, communication and technical performance. Approval is at the reviewer’s discretion, so meeting the technical requirements is necessary but not sufficient.
Can a front build ship with the web SDK’s sample assets?
No. Submitted games must use unique audio and visual assets, and backgrounds, symbols or animations supplied with the web SDK’s sample games will not be approved for publication. Games must also be original designs rather than pre-purchased or licensed games already available on third-party sites.
Why does a hardcoded bet ladder fail Engine review?
The session authentication response returns the default bet levels, the supported bet levels for a specified currency and the minimum and maximum bet amounts, and the front end must respect them. If the default bet size is one unit but the session uses a currency with a ten-unit minimum, the play request fails. Bet increments must follow the authenticated configuration.
What happens if an Engine game scores below one star?
Games receive a zero-to-three-star quality ranking from three anonymous reviewers, averaged and rounded. An average below one star is treated as below the minimum threshold, so the game is not approved. The approval thread is closed and locked for a seven-day improvement window, after which the game can be resubmitted for a new review cycle.
Does an approved game allow frontend changes afterwards?
Only minor updates that address visual issues are permitted after approval, unless the Engine team requests otherwise. Changes to the underlying math model, new game modes and gameplay mechanic modifications are not allowed. What can change after Engine approval covers that boundary in full.
