An Engine submission is not just a working game — it is a package that a review team can assess without asking for missing pieces. An incomplete submission does not fail immediately; it waits in the queue until the issues are resolved, and that wait can stretch from hours into weeks. Preparing the package completely before uploading is the single decision that controls how long the review takes.
For a studio building an original game or a publisher commissioning one, the preparation decision belongs before production ends. The studio that reaches submission with every required element already organised arrives at a reviewable state; the one that relies on last-minute corrections arrives at a delay.
The static-file format requirement
Engine games must be uploaded as static files. Every possible game outcome lives inside the compressed game files, typically split by mode. Each outcome corresponds to a row in a CSV that records one simulated round by simulation number, selection probability and final payout multiplier. When a round begins, the platform selects a simulation number in proportion to its weight and returns the matching events in the play API response.
Studios building on the Engine SDK produce these files directly: the Math Framework generates the backend config, lookup tables and simulation output from game rules written in Python, and the Frontend Framework — built on PixieJS and Svelte — reads those outputs so the client stays in sync with the math. Teams using their own frontend or math stack can still upload in a compatible format through the Admin Control Panel.
The static-file requirement exists for verification, testing and security. A game that generates outcomes at runtime cannot be fully reviewed before it goes live; a game whose outcomes are precomputed can be audited against its rules and math documentation completely before any player sees it.
The game description on the submission form
The submission form has a description field for a short blurb covering the game’s theme and mechanics. This is not a marketing paragraph; it is the reviewer’s first orientation to what the game is supposed to do.
A useful description names the genre, the core mechanic, any bonus modes and the target volatility direction. It does not need to be long, but it should make the game’s intent unambiguous to someone who has not yet opened the client. A reviewer who has to infer the intended behaviour from the files alone is working harder than one who can verify that the files match an explicit description.
What the review assesses
Three independent reviewers are assigned to each submission. Each reviewer rates the game from zero to three stars across three dimensions: design, gameplay and math compliance. The individual ratings are kept hidden until all three reviewers have submitted, and the average then determines the outcome. An average of one star or higher results in approval for production; below one star results in rejection, with feedback that the studio can address before resubmitting.
The three-reviewer structure matters for preparing the submission. Design, gameplay and math compliance are separate assessments. A game that passes math compliance but delivers a poor play experience can average below the threshold; a game with strong visual presentation but incomplete math documentation faces the same risk. Preparing all three dimensions rather than only the one the team is most confident about is the preparation decision.
Engine communicates its reasoning on approvals and rejections on a case-by-case basis. The platform may request specific changes and explain them before issuing a final decision.
Building the game around reviewable mechanics
A mechanic is reviewable when its complete state machine can be traced from the rules document through the math output to the client. The reviewer should be able to follow what happens after a trigger, through all feature states, to the final outcome and its communication to the player.
This means defining each mode’s entry condition, all possible paths through the feature and the exit condition. It means agreeing what happens after a reconnect and how the game communicates the round result. A mechanic that works in practice but whose states are not documented leaves the reviewer inferring correctness; a documented mechanic whose client matches the documentation is verifiable.
For a studio working with a publisher’s brief, the mechanic’s scope belongs in the written brief before production begins. Arriving at submission with a mechanic that the brief never fully specified creates correction rounds that the briefing stage could have prevented.
Math documentation and rules consistency
The math documentation and the player-visible rules should use the same vocabulary and describe the same game. A symbol name, award table or bonus condition that appears under different labels in the math document and the rules gives the reviewer a consistency question to resolve.
The math package should name every feature, describe how each outcome is produced, and make the theoretical return figure traceable to the simulation. The rules should describe every player-visible outcome and its trigger condition in terms the player can read against what they see on screen.
Where the game has a bonus buy or a state that a player can enter directly, the documentation should cover that path specifically, not only the base-game flow.
Preparing the submission before the queue
Incomplete submissions cause delays because they hold reviewer time without reaching a decision. A submission that does not meet the requirements is held until the issues are resolved, which can push the go-live date back significantly. The shared review queue means that an incomplete submission affects the throughput of other teams, and Engine may deprioritise requests that arrive without the expected package.
The practical preparation approach is to work backwards from the submission checklist before uploading. Confirm that the static files cover every possible outcome, that the description is accurate, that the math and rules documentation are consistent, and that the client matches both. A studio that checks those conditions before submission does not discover them as rejection feedback.
Wizards’ Engine game-development service covers the production workstreams — math, client, documentation and review support — as a project-specific scope. Request a project quote with your game concept, the existing assets you hold and the production stage you need support from.
What file format does Engine require for game submissions?
Engine requires static files: every possible game outcome is precomputed and stored in compressed game files, usually split by mode. Each outcome maps to a CSV row recording a simulation number, selection probability and payout multiplier. The platform selects outcomes by weight at runtime rather than computing them on demand. Teams can produce these files with the Engine SDK or upload in the compatible format using the Admin Control Panel.
How does the Engine review process work?
Three independent reviewers are assigned to each submission. Each rates the game from zero to three stars across design, gameplay and math compliance, with ratings hidden until all three are submitted. An average of one star or above means the game is approved for production; below one star results in rejection with feedback for resubmission. Engine communicates its reasoning on each decision and may request specific changes before issuing a final outcome.
What causes an Engine submission to be delayed?
Incomplete submissions are the main cause of delay. A game that does not meet the requirements when it enters the queue is held until the issues are resolved, which can extend the review from hours to weeks. The review queue is shared across all teams, so a submission that requires back-and-forth takes reviewer time away from other games and may be deprioritised. Completing the package before uploading — static files, game description, math documentation and rules — is the preparation decision that controls how long the review takes.
What should the game description on the submission form say?
The description should briefly cover the game’s theme, core mechanic, any bonus modes and the intended volatility direction. Its purpose is to give reviewers an unambiguous statement of what the game is meant to do, so they can verify the files against a clear intent rather than inferring it. It is not a marketing pitch; a short, accurate statement of the game’s structure is more useful than a promotional one.
How does commissioning through a studio affect Engine submission?
A publisher commissioning an original Engine game should agree the submission package scope with the studio before production begins. The contract should name the game version, rules, math evidence and QA records the studio will deliver, identify who owns the submission and who answers review feedback, and clarify what counts as an implementation correction versus a changed feature request. The current Engine submission checklist is the platform reference; the studio’s contract should describe its own contribution to that process. Platform approval, independent certification and permission to operate in a specific market are separate questions from production delivery.
