A game that needs finishing arrives as a folder and a login, not as a plan. The brief says the game is eighty percent done. The build opens. Some modes play, some throw. The math files are somewhere, the previous studio’s repository access is the publisher’s if the contract said so, and nobody can say which version the platform has actually seen.
That is the moment a takeover decision is made, and it is usually made badly, because the question gets framed as “how much is left”. The better question is “what is the baseline”. An Engine game is not one artefact that a second studio continues; it is a front version and a math version that were reviewed together, plus the rules, strings and assets that describe them. Until you know which of those the platform has approved, “eighty percent done” is a feeling rather than a measurement.
This article sets out what to establish before a takeover scope is agreed, and how to sort the remaining work into inherited defects, unfinished scope and new scope. The three are priced, scheduled and reviewed differently, and confusing them is how a takeover turns into a rewrite with the original deadline attached.
Engine’s approval guidelines state the unit plainly: each approval request covers one front version and one math version, reviewed together. The review looks at functionality, clarity, communication and technical performance, and Engine communicates issues and reasoning case by case. Approval is at the reviewer’s discretion, which is a statement about the process rather than about your game.
For a takeover, that single sentence reorganises the whole assessment. There is no such thing as “the approved game” in the abstract. There is an approved pair, with a front version and a math version, and the build in your folder is either that pair or it is not.
The follow-on rule matters just as much. Once a game is approved for publication, the published guidance permits only minor updates that address visual issues, unless the Engine team requests otherwise; changes to the underlying math model, new game modes and modifications to gameplay mechanics are not allowed. Read together, the two rules define the takeover’s real constraint: the further work you are buying has to be classified before it is quoted, because a large part of what a publisher thinks of as finishing may not be permitted on the approved pair at all.
What the platform will not let you finish
Some of the work an incoming brief describes cannot be delivered on this platform at all, no matter which studio builds it. Finding that out after signature is expensive, and it is avoidable in an hour of reading.
Engine games are strictly stateless. Each bet must be independent of previous outcomes, and the published restrictions exclude jackpots, gamble features, continuation and early cashout. A brief that inherits a community jackpot, a double-or-nothing round or a hold-and-respin that carries state between bets is not a finishing job; it is a game that has to be redesigned before it can be submitted.
The originality rules are equally concrete. Team names, game titles and assets must comply with intellectual-property and copyright law, and infringement is grounds for rejection. Games must be original designs, and pre-purchased or licensed games that already exist on other third-party websites are not permitted. Assets cannot carry Stake branding or themes. A game can have at most 20 modes, with exceptions handled through support.
An inherited build can fail any of these before a single line of new code is written, and none of them is a matter of taste. The practical test is a list, not an opinion: count the modes, read the title and asset provenance, and check whether any mechanic depends on state that the platform’s model does not carry.
The math is the game, and it has to reproduce
Every Engine game is a set of static files uploaded in two parts. The math part contains every possible outcome, generated ahead of time and compressed by mode; each outcome is a row in a CSV with a simulation number, its probability of selection and its final payout multiplier. When a player bets, the RGS picks a simulation number at a frequency proportional to its weight and returns that outcome’s events, and the front end plays those events back.
That architecture is what makes a takeover assessable, and also what makes a careless one dangerous. The outcomes are data, so the client’s job is presentation, and the client can be replaced without touching the maths. But the maths is also the product: the return figure, the volatility, the maximum win and the frequency of every feature are already encoded in files. A studio that accepts a math model without regenerating it from its source is accepting numbers it cannot defend.
So the second assessment item is reproducibility. If the math source exists, it should regenerate the published files, and the output should match what is in the folder. If it does not exist, the builder is adopting a fixed data set and every future change is a new model rather than an edit. Both are legitimate positions; only one of them is usually what the publisher believes it is buying.
Reading the client like a reviewer
The front end is where a takeover finds most of its defects, because the client is the part that touches the platform in ways a demo never shows. Engine publishes the review prompt it gives its own reviewers’ checklist to, and the list of behaviours it checks is a good assessment script for an inherited build.
Bet levels must come from the authentication response, not from a hardcoded ladder. An active round has to be restored with its original bet after a reconnect. A round that pays nothing should not be closed with an end-round call, and a play request should not be issued when the balance is insufficient. Currency presentation has to handle symbols, decimals and placement, including sub-cent payouts.
There is more of the same in the front-end and rules guidance: space bar to bet, no page scrolling, sound off everywhere, four reviewer screen sizes, RTP and maximum win stated per mode, symbol payouts and win combinations that match the maths, every control explained, and a fallback for language codes the platform does not support.
This is where a takeover differs from a new commission. A new build can be written against these requirements from the first commit. An inherited build has to be measured against them, and the measurement is the deliverable that decides the scope.
Use the platform’s own review prompt
Engine publishes a review prompt as a plain Markdown file that a coding agent runs inside the game’s folder. It is read-only until you ask for fixes. It maps the framework and build, finds where launch parameters are read, lists every RGS call and where bet levels come from, collects player-facing strings and reads the math files if they are present.
With a session URL from the Studio dashboard, or a small mock RGS, it can also open the game in a headless browser and reproduce what reviewers test: rewritten bet levels, an interrupted round, a zero balance, an invalid rgs_url, and the four reviewer screen sizes. Every guideline gets a verdict — PASS, FAIL, AT RISK, NEEDS A HUMAN or N/A — and findings carry the submission checklist’s guideline identifiers, so the same vocabulary survives into the review correspondence.
Two limits are worth stating. The run happens on your machine, with your own model provider, and nothing is sent to Engine. And a clean report is explicitly not an approval: reviewers still play every submission and judge originality, quality and how the game feels. What the prompt gives a takeover is something narrower and more useful — a shared, itemised list of what the inherited build does and does not do, produced before anyone quotes a price.
Sorting the remaining work into three buckets
With the approved pair identified, the math reproduced and the client measured, the remaining work falls into three buckets that a brief should keep apart.
Inherited defects. The build does not meet the approved baseline, or it fails a requirement the reviewer would raise. These are corrections against something already agreed. They belong in the takeover scope with the assessment evidence attached, and they are the part of the job a fixed scope can price.
Unfinished scope. The previous brief promised it and the build does not do it. Here the classification question is decisive: if the missing work touches the math model, adds a game mode or modifies gameplay mechanics, the approved pair cannot simply be extended. It needs a new submission, with the review that follows. If it is a visual fix, the published guidance is more permissive. The bucket, not the effort, determines the process.
New scope. The publisher has changed its mind, or the market has. This is a new commission inside an existing codebase, and it should be quoted as one rather than absorbed into a “finish” line item.
The value of the three buckets is that they are testable against evidence rather than argued from memory. A defect has a failing check attached. An unfinished item has a line in the previous brief. A new item has a decision date and an owner.
What the takeover brief should contain
A brief that produces a comparable quote contains six things.
A baseline statement. Which front version and which math version the platform has approved, and whether the build in hand is that pair. If the answer is unknown, the first deliverable is establishing it, not finishing anything.
The evidence set. The review run, the reproduced math files and the mode count, attached rather than summarised.
The three-bucket ledger. Every remaining item classified, with its evidence and its process consequence — correction, unfinished scope, or new submission.
The ownership and access position. Who holds the source, who holds the Studio access, and what happens to both at handover. The separate question of who owns commissioned code and art is worth settling in the same conversation rather than after it.
The acceptance definition. What “finished” means in terms of the pair: which checks pass, which screens match the rules, and who answers review feedback when it arrives.
The open questions. Items the assessment could not settle, listed rather than assumed. A takeover brief with no open questions is usually a brief written from the outgoing studio’s summary.
None of this guarantees approval, and none of it substitutes for certification in a market where the game will be offered. It does something more modest and more valuable: it turns an inherited folder into a scope that can be quoted, scheduled and reviewed without the parties discovering the classification of the work after the invoice.
If you are deciding whether to finish an existing build or commission fresh, the Engine game-development service covers assessment and production as a project-specific scope. Request a project quote with the build’s current state, the approval status you can establish and the modes you intend to ship. The submission requirements themselves are set out in what an Engine submission package should contain, the change rules after approval are covered in what changes once a game is approved, and the check that the client still presents the agreed outcomes is covered in the math-to-client parity guide.
Frequently asked questions
Can a second studio finish a game the first studio already submitted?
It can, but approval is bound to a pair: each request covers one front version and one math version reviewed together. A second studio has to establish which pair was approved, whether the build it received is that pair, and whether the remaining work is a visual correction or a change to maths, modes or mechanics. The last category cannot be added to an approved pair; it needs a new submission.
Does a finished build need a new review if the maths does not change?
The published guidance says that once a game is approved for publication, only minor updates addressing visual issues are permitted unless the Engine team requests otherwise. Changes to the math model, new game modes and gameplay-mechanic modifications are not allowed. What remains permitted is narrow, and it is worth confirming the specific change with Engine rather than inferring it from this summary.
What should be assessed before agreeing a takeover scope?
Five things: which front and math versions are approved, whether the math source reproduces the published files, how the client handles launch parameters, bet levels, active-round restore, zero-win rounds and insufficient balance, what the rules screen states about RTP and maximum win per mode, and whether any inherited feature — a jackpot, a gamble round, a continuation — is excluded by the platform’s stateless requirement.
Is a clean automated review the same as approval?
No. The published review prompt runs locally against the approval guidelines and reports each one with evidence and a fix, but Engine states that a clean report is not an approval. Reviewers still play every submission and judge originality, quality and how the game feels. The report is an assessment input, not a decision.
What files should the incoming studio receive?
At minimum the front-end source and its build, the math source and the publish files it generates, the rules and paytable text, the string tables, the asset sources with their provenance, the mode list, and the approval correspondence for the current pair. Without the math source the studio is adopting a fixed data set rather than maintaining a model, and the brief should say so explicitly.
