The first thing most publishers see of a commissioned game is a link. It opens a playable slot in a browser tab, spins, pays, and looks finished. That link is the artefact on which a shortlist is often built and a quote often requested, and it is routinely read as more than it is.
A studio demo on a platform like Engine is not a video and not a mock-up. It is a real front end loaded from a versioned URL, talking to a remote game server in a play-money session. That makes it genuine evidence for one set of questions — whether the client is built properly — and no evidence at all for another set, which is whether the game will be certified, approved, or perform.
This article separates the two. It sets out what an hour with a demo can actually settle, what the same demo cannot, and what a buyer should ask for alongside the link so that a quote is based on something that survives contact with production.
A demo launch is a real session with one flag changed
Engine’s documented launch URL is a set of query parameters the game reads when it loads: a session identifier, the RGS host, the language, the currency, the device class, a social-casino flag and a demo flag. The demo flag is documented as true for a play-money launch, and the session is authenticated through the same wallet call a real-money session uses.
Two consequences follow directly. The first is that the front end you are clicking is the front end an operator would receive, pointed at a demo session rather than an operator wallet. The second is that the RGS host arrives as a parameter and the platform documentation is explicit that it must never be hardcoded, because it can change at any time.
So a demo is a fair test of the client and an unfair test of everything behind it. The money path is simulated; the maths is whatever configuration the studio published for the demo; nothing about certification status is being demonstrated. Reading those limits correctly is most of the skill.
What an hour with the demo settles
The round loop behaves like the documented flow
The platform’s basic flow is short: authenticate, place a bet that opens a round, play the round, settle it. A round that pays nothing is closed by the bet call itself, with the returned round marked inactive, and there is nothing to end. A round with a win stays active until the end-round call pays it out. Only one round can be active at a time, and a second bet while one is open is rejected.
That gives three observations a buyer can make in five minutes. Does a losing spin leave an open round behind? Does a winning spin settle through an explicit end call rather than silently? Does the interface block a second bet while a feature sequence is still playing? A client that guesses any of the three will reconcile badly against an operator wallet, and the failure surfaces as a support queue rather than a bug report.
The client reads its launch parameters
Open the demo with the query string visible and check what the build does with each parameter. The device class is documented as desktop, mobile or tablet, and a demo that is only ever opened on a desktop has not been exposed to the value an operator will actually send. The language parameter is an ISO 639-1 code that carries whatever the operator sent, including an empty value or a code outside the supported list, with English as the documented fallback.
That last point decides a specific question at quote stage. The documented supported-language list covers seventeen languages; Italian is not among them, and Portuguese is. A studio that tells you Italian is handled because the platform lists languages has not looked at the list. Whether the Italian copy exists in the delivered build is a scope item, not an assumption.
The resume path works
Disconnect mid-feature, reload, and see what returns. The platform records how far a player watched a multi-step round through a bet-event call, and authentication returns the unfinished round with that last recorded step, so the front end can resume the sequence instead of restarting it. A demo that was never interrupted has not been tested on the one path that generates complaints.
The display layer accepts unfamiliar money
Amounts on the RGS are integers with six decimal places of precision, and currency affects only the display layer, not gameplay logic. The documented currency table mixes two-decimal currencies, three-decimal currencies and zero-decimal currencies such as the yen and the won. A build that formats whatever code the wallet returns, with no fallback for a code outside the language runtime’s tables, breaks on the first operator whose currency is unusual — and a demo that only ever rendered euros has not shown you the fallback.
The bet ladder is the same kind of observation. Minimum bet, maximum bet and step are returned at authentication, and the platform recommends small base denominations. If the ladder, the cost multipliers of each bet mode and the win-display precision do not agree with each other, the demo’s coin sizes are a decoration rather than a plan.
The help surface exists before the first spin
The demo is also the cheapest place to check the disclosure surface. In Great Britain the remote technical standards require an explanation of the applicable rules to be easily available before the customer commits to gamble, information that would reasonably enable them to understand the current state of a multi-state game, information sufficient to judge the chances of winning including the house edge or return to player, and the potential prizes or the means by which they are calculated. In Portugal the corresponding framework requires demonstration games to carry the same characteristics as the real-money game and to present the chance of winning correctly and in balance.
A demo whose help screen is a stub is telling you something about the build, not about the market. The market rules are summarised in our guide to localised certification evidence, and the Portuguese demonstration rule in the Portugal requirement set.
What the demo must disclose, and what to ask if it does not
The GB remote technical standards treat play-for-free games as a fairness surface rather than a marketing one. Play-for-free games must implement the same rules as the corresponding play-for-money games offered on the same facilities, and operators must take all reasonable steps to ensure that play-for-free games accurately represent the likelihood of winning and the prize distribution of the play-for-money game. The implementation guidance adds that the play-for-free game should use the same random number generator as the real-money game, or another one meeting the standards’ own requirements, or a publicly available generator with no systematic bias.
The same guidance then addresses the case a publisher is most likely to meet during procurement: where a non-consumer website — a supplier’s own site, for example — demonstrates a game with higher than normal returns, it must be made clear that it is a demonstration game specifically designed to demonstrate the bonus features.
That is the question to put to any studio whose demo paid generously. Is this demonstration build configured to show features, or is it the shipping configuration? A supplier demo with elevated returns is not automatically a problem; an unexplained one is, in the market that wrote the rule, and a poor basis for evaluation anywhere. Ask for the answer in writing, along with the return to player the demo was configured at.
What the demo cannot settle
Approval. A platform review attaches to a submitted front version and a submitted math version, as a pair. A demo URL is not that pair, and a clean demo session is not a review outcome. The assessment path for an existing build and the submission package guide cover what a review actually examines.
The maths. A demo session is a sample, and a sample cannot establish a return to player. The artefact that can is a par sheet with simulation evidence, which is a document you request rather than a thing you play — the math model guide sets out what should be in it, and the parity guide covers the separate question of whether the client presents the agreed outcomes.
Originality and provenance. You can see the art. You cannot see the licence position of a font, a sound library or a symbol set from a browser tab, and a demo is a common place to meet placeholder assets that will not survive production.
Behaviour at portfolio scale. Load, memory and thermal behaviour across a catalogue is a testing programme, not a first impression.
The code you would receive. A demo proves that a build runs; it does not prove that the delivered repository, build scripts and source of the version you played are the same objects.
The observation sheet
Eight observations, each recorded as seen or not seen, rather than as a score out of ten:
- The query string the demo launched with, and whether the build reads the RGS host from it.
- What a losing round returned, and whether an active round was left open.
- What a winning round did before and after settlement.
- Whether a second bet was accepted while a feature sequence was running.
- What came back after a reload mid-feature, and whether the sequence resumed at the recorded step.
- Whether the help surface was reachable before the first bet, and whether it stated rules, current state, chances of winning and prizes.
- The currencies and bet ranges one operator session returned, and the decimal count rendered for each.
- The device class the demo was opened under, and one repeat on a phone if the demo is aimed at mobile.
Then the questions, which matter more than the sheet: what version is this, what math configuration is it running, is it a feature-demonstration build, which markets is it intended for, and what would change between this build and the delivered one.
What to ask for beside the link
A demo plus five documents makes a quote defensible. The demo, as above. The par sheet the build is meant to implement. The version identifiers for the front end and the math, so that “the demo” has a name. A statement of which assets are prototype and which are final. The intended market set, because it decides which disclosure and certification surfaces are in scope — the submission guide is the map for that work. And the integration target, since a client that has never read a launch parameter is a porting project rather than a delivery.
None of this is a substitute for the acceptance work that follows a contract, and none of it predicts an approval. It is the difference between a shortlist built on a build and a shortlist built on a first impression.
If you are preparing a brief and want the demo, the math evidence and the market set assessed together, request a project quote. The commissioning guide covers how that brief is assembled, and the front-end acceptance criteria pick up where the demo review stops.
Questions buyers ask
Does a demo that plays well mean the game will be approved?
No. A platform review attaches to a submitted front version and a submitted math version as a pair, and a demo URL is neither. A clean demo session shows that a client runs and that its round loop behaves as documented; it says nothing about the review outcome, the certification position or the final math configuration.
Why would a studio’s demo pay more than the real game?
Because a supplier demo is often configured to show bonus features rather than to represent the shipping return. Great Britain’s remote technical standards require play-for-free games to implement the same rules as the corresponding play-for-money game and to represent the likelihood of winning accurately, and their implementation guidance says that where a non-consumer website demonstrates a game with higher than normal returns it must be made clear that it is a demonstration game designed to demonstrate the bonus features. Ask which configuration you are playing.
Can I judge the return to player from a demo session?
No. A session is a sample, and the return to player is a property of the math model, established by simulation evidence. The artefacts to request are the par sheet and the simulation report for the version under consideration — the demo only tells you what the client does with the outcomes it is given.
What should I check on a phone rather than a desktop?
The device class the launch sends, because the documented values are desktop, mobile and tablet and a build can behave differently under each; the touch targets on the bet and spin controls; the legibility of the symbol set and the win presentation at the smaller size; and whether an interrupted feature resumes when the browser tab is discarded and reopened.
Is a studio demo the same thing as a mechanic prototype?
No. A prototype exists to prove that a mechanic is understandable and worth producing, usually before final art. A demo is a versioned front end served from the platform, with a language, currency, device class and demo flag supplied at launch. The prototype gate is the earlier decision; this one is about the build.
