A studio that is asked to “add a social mode” is usually being asked for something much larger than a setting. On a platform that publishes both real-money and social-casino titles, the social edition is a separate front version with its own wording, its own currency set, its own language rules and its own review. Treating it as a flag on the existing build is the most common way a commissioned game reaches its submission date with a second review still ahead of it.
The distinction is not pedantic. Engine’s published approval guidelines state that each approval request covers one front version and one math version, reviewed together, and that after approval only minor updates to address visual issues are permitted — changes to the underlying math model, the addition of new game modes, or modifications to gameplay mechanics are not allowed. If the social edition needs different mode names, different paytable wording or a different currency presentation, those decisions have to exist before the submission, not after it.
This article is written for the two people who have to make that call: the operator or platform content lead deciding whether a title can serve a social casino at all, and the studio producer deciding what the commission has to include. The certification side of a market-specific edition is covered separately in the localised certification evidence guide; this is the build-scope side.
The toggle you can see is a test harness, not a build strategy
Engine’s documentation describes a social-mode setting inside the play modal, and it is easy to read that as evidence that social mode is a switch. It is a test surface: it lets a team check how a build behaves when the platform loads it in a social context. The behaviour it exposes is real, and it is driven by the platform rather than by the game’s own settings.
The RGS passes a social=true or social=false query parameter to indicate whether the game is loaded in a social casino. The game is expected to handle both. That single parameter changes more than a label: it changes which language file is appropriate, which currency codes arrive, and which words are permitted anywhere a player can read them.
So the first question in the brief is not “can we support social mode?” It is “which of the two editions is the primary build, and what does the second one inherit?” A studio that answers “the same build, with a different language file” has described a real and workable approach — but only if the wording, the mode names and the currency handling were designed for it from the start.
The restricted-wording surface is content work, not a find-and-replace
The clearest published example of how deep a social edition reaches is the restricted-phrase list Engine applies for stake.us. The requirement is that a game approved for that market cannot contain the listed terms when it runs in social mode, and the list is not a short one: bet becomes play, buy becomes play, cash becomes coins, deposit becomes get coins, wager becomes play, stake becomes play amount, total bet becomes total play, withdraw becomes redeem, credit becomes balance, currency becomes token, bonus buy becomes bonus or feature, and place your bets becomes come and play or join in the game.
What makes this a content problem rather than a search-and-replace is the scope. The requirement covers all player-facing text: UI labels, buttons, paytables, help pages, loading screens, popups, confirmation dialogs, error messages and settings menus. Engine’s own guidance names the misses it sees most often — a bet button still labelled “Bet”, “Auto Bet” or “Total Bet” inside an autoplay menu, and “Buy” left on a bonus-buy button or its confirmation dialog.
Those are exactly the strings that live outside the main copy deck. A paytable is generated from the math model. An autoplay menu is a component with its own defaults. A confirmation dialog is often written by whoever built the feature, late, and never reviewed as copy. A studio that plans the social edition as a translation pass will find these strings after the front version is frozen, which is the worst possible moment.
The practical answer is a wording inventory as a deliverable: every player-visible string in the build, its source file, and its social-mode replacement, reviewed as a list rather than discovered in a test. That inventory is also the artefact a platform reviewer can check, which makes it worth more than an assurance that the build “has been checked for restricted terms”.
Mode names are the trap, because they live in the math file
The requirement that catches experienced teams is the one about game mode names. Engine’s guidance says mode names must not contain restricted terms such as “buy”, “bet” or “pay”, and — the important part — must be named the same in the game, the replay window and the math files.
That last clause turns a naming decision into a versioning decision. On Engine, a game is a set of static files: a math version containing every possible outcome, generated ahead of time and compressed by mode, and a front end that plays those outcomes back. The RGS selects a simulation number at a frequency proportional to its weight and returns that outcome’s events in the /wallet/play response. Mode names are part of that structure, not a display string layered on top.
So a mode called “Buy Bonus” is not fixed by relabelling a button. It has to be renamed in the math files, in the game, and in the replay window together — and if the game has already been approved, the post-approval rules do not permit adding modes or changing the math model. A social edition that needs different mode names is therefore a different submission, planned from the start, not a correction applied afterwards.
The replay window deserves its own line in the brief for the same reason. It is a player-facing surface that reproduces a past round, and Engine’s guidance requires it to be free of restricted terms too. A replay screen that renders the original mode name will fail a requirement that nobody thought to test, because the replay window is usually built once and never revisited.
Currency and language are configuration the brief has to name
Two more parameters belong in the brief because they are cheap to specify and expensive to retrofit.
The first is currency. Engine’s guidance requires the game to load and display correctly with the social currencies XSC (SC) and XGC (GC), and specifically not to prefix those values with a dollar sign. That is a formatting rule with a real failure mode: a build that formats every balance through a single currency formatter will render a social balance as a cash amount, which is both wrong and, in a social casino, a compliance problem rather than a cosmetic one.
The second is language. English is the only supported language in social mode on that platform, and the guidance recommends an additional language file with the sweeps_ prefix to handle the phrase changes. That recommendation is the difference between one build with a second string table and two builds that drift. A studio that keeps the social wording in a separate file can update it without touching the real-money copy; a studio that edits the main strings in place has made the two editions mutually exclusive.
Neither of these is a reason to refuse a social edition. Both are reasons to write them into the commission before the front version is built, alongside the front-end acceptance checks that already cover language and currency combinations.
The session contract is part of the build, not the platform’s problem
A social edition still has to satisfy the same RGS contract as any other build, and the contract has behaviours that a front end can get wrong in ways that only appear under real play.
Every flow starts with a call to /wallet/authenticate when the game first loads. That call authorises the session ID for /wallet/play, /wallet/balance and /wallet/end-round. If the game never calls it, later calls come back as a 400 ERR_IS error because the session is invalid. The recommended basic flow opens a round with /wallet/play and closes it with /wallet/end-round once the animations finish.
For a longer round — a slot bonus, for instance — the guidance suggests storing how far the player has watched, and on the next load using the round.event value from the /wallet/authenticate response to resume the animations from that point. That is a resume requirement, and it interacts with the social edition in a way worth naming: a resumed round renders the same mode name and the same wording as the original, so a wording change that is not applied to the resume path produces a screen that fails the restricted-term rule only for players who dropped off mid-round.
The URL contract matters too. The game is loaded with a session ID, a language, a device value of mobile or desktop, and an rgs_url. The session ID is required on every request, and the rgs_url must not be hardcoded because it can change at runtime. A build that hardcodes the RGS endpoint will work in the studio and fail in an environment the studio does not control.
What the brief should actually say
Pulled together, a commission that includes a social edition needs six decisions recorded before production starts.
Which edition is primary. The real-money build or the social build. The primary edition sets the copy deck, the mode names and the paytable structure; the secondary one inherits and adapts. Deciding this late means rewriting the math file’s mode names, which is the expensive path.
The wording inventory. Every player-visible string, its source, and its social replacement, as a reviewed list. Include the generated surfaces: paytables, autoplay menus, confirmation dialogs, error messages, loading screens and the replay window.
Mode names, agreed once. Names that survive both editions, checked against the restricted-term list before the math version is generated. This is the single decision most likely to force a resubmission.
The currency presentation. How XSC and XGC are formatted, and where the formatter lives, so a social balance cannot inherit a cash symbol.
The language file strategy. A separate sweeps_ table rather than in-place edits, so the two editions can be maintained independently.
The session and resume behaviour. Authentication before any other call, round closure after animations, and a resume path that renders the same wording as the original round.
None of this requires a platform relationship or a special approval. It requires the buyer to ask for the second edition’s scope at briefing time, when the mode names are still a design decision rather than a file format. The cost of that conversation at kickoff is a meeting; the cost of discovering it after approval is a second submission with a frozen math model.
For a studio, the honest position is that a social edition is a second product with a shared art and math core. That is a scoping statement, not a refusal — and it is the one that lets a publisher plan a launch across both catalogues instead of discovering the second review on the day the first one clears. The Engine project brief is the route to set that scope, including which edition is primary and what the second one inherits, before production starts.
Frequently asked questions
Is social mode a setting on the same game build?
No. The platform passes a social=true or social=false parameter to indicate whether the game is loaded in a social casino, and the game is expected to handle both, but the social edition carries its own wording, currency presentation and language rules. Engine’s approval guidelines state that each request covers one front version and one math version reviewed together, so a social edition with different mode names or paytable wording is a separate submission rather than a toggle.
Why can’t a studio just rename the modes after approval?
Because mode names are part of the math structure, not a display label. Engine’s guidance requires mode names to be free of restricted terms and to be named the same in the game, the replay window and the math files. After approval, only minor updates to address visual issues are permitted; adding game modes or changing the math model is not allowed. A rename that touches the math files is therefore a new submission.
Which words have to change in a social-mode build?
Engine publishes a restricted-phrase list for stake.us that includes bet to play, buy to play, cash to coins, deposit to get coins, wager to play, stake to play amount, total bet to total play, withdraw to redeem, credit to balance, currency to token and bonus buy to bonus or feature. The requirement covers all player-facing text, including paytables, help pages, loading screens, popups, confirmation dialogs, error messages and settings menus.
How should a social build handle currency and language?
Engine’s guidance requires the game to load and display correctly with the social currencies XSC and XGC, without a dollar-sign prefix, and states that English is the only supported language in social mode. It recommends a separate language file with the sweeps_ prefix for the phrase changes, which keeps the social wording maintainable without editing the real-money copy in place.
What does the RGS expect from the front end?
Every flow starts with /wallet/authenticate, which authorises the session ID for /wallet/play, /wallet/balance and /wallet/end-round; without it, later calls return a 400 ERR_IS error. The basic flow opens a round with /wallet/play and closes it with /wallet/end-round after the animations finish. For longer rounds, the round.event value from the authentication response lets the front end resume animations where the player left off, and the rgs_url must not be hardcoded because it can change at runtime.
