3D City: Neighborhoods
A single-step instant game on an island city. The player picks an outlined plot, sets the bet and presses BUILD: one press = one round = one draw. The server decides the outcome first; construction then reveals the matching neighborhood, which stays in the player's city. The round returns the neighborhood's multiplier × the bet (the total includes the stake, so a multiplier below 1× is a partial return). The land grows as neighborhoods are built at its edge, and building again on an existing plot (redevelop) is a normal round that replaces that neighborhood.
The outcome is decided by the RNG at the bet: one draw picks one of twelve tiers of a fixed ladder. Where the player builds, the camera, the timing and redevelopment never change it. Construction, traffic, residents, emergencies, day and night, the milestone landmarks at 25 / 50 / 100 neighborhoods and the photo mode are presentation and decoration: the client animates the outcome the server returned and cannot change it.
| Property | Value |
|---|---|
| Game ID | 3d-city-neighborhoods |
| Engine version | 1.0.0 (ladder version 1) |
| Type | single_step |
| Volatility | Medium |
| Max Win | 250× bet (Metropolis) |
| RTP variants | 92.00% / 94.00% / 96.00% / 97.00% — exact for every accepted round, uncapped or under any operator or money cap (a round whose cap would fall below 2× is refused); payouts round down to the minor unit |
| Minimum stake | 100 minor units (1.00 in 2-decimal currencies), over any lower operator setting |
| Random draws | One per round, at the bet |
| Theme | An island city that grows one neighborhood at a time |
How a round works
| Phase | Description | Player input |
|---|---|---|
| Set up | Choose a plot on the island's edge (or an existing neighborhood to redevelop) and the bet | Tap or click a plot, bet |
| Build | The stake is debited, ONE draw decides the neighborhood, and the round settles in the same call | Press BUILD (or Enter / Space when nothing else is open; a held key never builds again) |
| Reveal | The same construction sequence plays for every round, the same length every time; then the neighborhood stands on the plot and the result is shown | None |
The round is complete when the response arrives: there is no round to resume, cash out or abandon. The construction is the same for every outcome — the client never hints at the result before it is shown — and returns at or below the stake are shown neutrally ("No return", "Partial return", "Stake returned"), never as a win. Milestone landmarks are decoration only and are never celebrated at a round's reveal.
The neighborhoods
Twelve tiers, the same in every RTP variant (a lower variant only makes Green beginnings, which pays nothing, a little more likely). Some Garden districts are drawn as a grand city park — a visual variant of the same tier.
| Tier | Neighborhood | Pays (× stake, stake included) |
|---|---|---|
| 0 | Green beginnings | nothing (0×) |
| 1 | Garden suburb | 0.50× |
| 2 | Residential block | 1× |
| 3 | Mixed-use quarter | 2× |
| 4 | Premium residences | 3× |
| 5 | Garden district | 4× |
| 6 | Skyline district | 5× |
| 7 | City observatory | 8× |
| 8 | Grand observatory | 10× |
| 9 | Golden landmark | 25× |
| 10 | Grand landmark | 100× |
| 11 | Metropolis | 250× |
Every accepted round returns the RTP
The tiers carry integer weights over an exact draw range, built so that the game returns the variant's RTP exactly — not approximately, and never above. There is no decision after the press, so no way of playing returns more or less than the RTP: the plot, redevelopment and timing change nothing about the money.
| Variant | RTP | Below the RTP (points) | Max win | SD of one round (stakes) | Rounds to 99.9% house-ahead (normal approximation, optimistic for right-skewed outcomes) |
|---|---|---|---|---|---|
| rtp-92 | 92.00% | 0 (exact) | 250× | 3.705 | 20,479 |
| rtp-94 | 94.00% | 0 (exact) | 250× | 3.742 | 37,147 |
| rtp-96 | 96.00% | 0 (exact) | 250× | 3.779 | 85,245 |
| rtp-97 | 97.00% | 0 (exact) | 250× | 3.798 | 153,022 |
"Rounds to 99.9% house-ahead" is the normal approximation (3.09 × SD / edge)² for a casino whose every round is played at that variant. It is an indication, not a guarantee, and it is optimistic for right-skewed outcomes such as these: the real horizon is longer.
Max win and caps
The round's effective cap is the lowest of 250×, the operator's multiplier cap (when one is set for your casino) and the money cap (the tenant's or the jurisdiction's maximum win per round ÷ the stake). It is fixed at the bet, before the draw, and a round never pays more than cap × stake. The game has no default operator cap; Slotty Labs can set one for your casino.
Caps are RTP-neutral (rule fair-cap-v1): when a cap binds, the tiers above it pay the cap (shown as MAX WIN) and returns become more frequent, so every accepted round still returns the variant's RTP exactly — the cap lowers the spread, not the return. A bet whose effective cap would fall below 2× is refused (HTTP 422, before anything is debited or drawn), so an operator multiplier cap must be at least 2× for the game to play, and at large stakes the money cap can refuse a stake (the game shows "This stake is above the maximum for this game. Lower your stake."; its stake selector never offers such a stake). At rtp-96:
| Effective cap | Return (rtp-96) | W(C) | z(C) (the zero tier) | Nothing (0×) | Win (> 1×) | Tiers paid at the cap | SD (stakes) | Rounds to 99.9% house-ahead (normal approx., optimistic) |
|---|---|---|---|---|---|---|---|---|
| below 2.00× | refused before the draw (no round is played) | — | — | — | — | — | — | — |
| 2.00× | 96.000% — exact | 60,600,000 | 7,512,000 | 12.396% | 24.238% | tiers 4–11 | 0.666 | 2,650 |
| 2.50× | 96.000% — exact | 65,750,000 | 12,662,000 | 19.258% | 22.339% | tiers 4–11 | 0.822 | 4,031 |
| 5.00× | 96.000% — exact | 81,000,000 | 27,912,000 | 34.459% | 18.133% | tiers 7–11 | 1.280 | 9,779 |
| 10.00× | 96.000% — exact | 88,000,000 | 34,912,000 | 39.673% | 16.691% | tiers 9–11 | 1.586 | 15,010 |
| 25.00× | 96.000% — exact | 92,500,000 | 39,412,000 | 42.608% | 15.879% | tiers 10–11 | 1.996 | 23,768 |
| 50.00× | 96.000% — exact | 94,000,000 | 40,912,000 | 43.523% | 15.626% | tiers 10–11 | 2.248 | 30,158 |
| 100.00× | 96.000% — exact | 97,000,000 | 43,912,000 | 45.270% | 15.142% | tier 11 | 3.053 | 55,637 |
| 250.00× | 96.000% — exact | 98,500,000 | 45,412,000 | 46.104% | 14.912% | none | 3.779 | 85,245 |
Payout rounding
The payout is floor(stake × multiplier) in the currency's smallest unit — never rounded up. Every multiplier is a whole number of times the stake except Garden suburb's 0.5×, so every stake that is an even number of minor units pays exactly; on an odd stake the 0.5× return rounds down by half a minor unit (the house side). Uncapped, that costs at most about a tenth of a point of return near the 1.00 minimum stake and less as the stake grows — the table below gives the exact return after rounding, by stake. Below 1.00 it would cost more, which is why the game's minimum stake is 1.00. A capped payout, stake × cap, rounds down the same way when it is not a whole number of minor units: under a cap that is not a whole multiple the shortfall can reach about three tenths of a point at stakes just above 1.00 (worst case found across 396,916 stake and cap combinations: a 1.03 stake under a 2.33× cap returns 96.70% on rtp-97). The rounding is always on the house side and never lifts the return above the variant's RTP.
| Stake (2-decimal currency) | rtp-92 | rtp-94 | rtp-96 | rtp-97 |
|---|---|---|---|---|
| 0.10 (below the 1.00 floor) | 92.000% | 94.000% | 96.000% | 97.000% |
| 0.50 (below the 1.00 floor) | 92.000% | 94.000% | 96.000% | 97.000% |
| 0.99 (below the 1.00 floor) | 91.906% | 93.904% | 95.901% | 96.900% |
| 1.00 | 92.000% | 94.000% | 96.000% | 97.000% |
| 1.01 | 91.907% | 93.906% | 95.903% | 96.902% |
| 1.05 | 91.911% | 93.909% | 95.907% | 96.906% |
| 1.50 | 92.000% | 94.000% | 96.000% | 97.000% |
| 1.99 | 91.953% | 93.952% | 95.951% | 96.951% |
| 2.50 | 92.000% | 94.000% | 96.000% | 97.000% |
| 9.99 | 91.991% | 93.990% | 95.990% | 96.990% |
| 10.00 | 92.000% | 94.000% | 96.000% | 97.000% |
| 10.01 | 91.991% | 93.990% | 95.990% | 96.990% |
| 100.00 | 92.000% | 94.000% | 96.000% | 97.000% |
The player's city
Each neighborhood built in a real-money round is saved to the player's account, so the city is still there in the next session and on another device. Fun-play / demo rounds are not stored by the platform, so a fun-play city is kept on the device (per operator, in the browser's storage) and is lost if that storage is cleared. The city is decoration: what is stored is what the rounds already decided, and nothing in it changes a future round.
The player can delete the city at any time — Settings → Start a fresh city. The confirmation says how many neighborhoods will be removed and that the balance and round history are not affected. The island then starts again from its four starter districts. Rounds, transactions and their history are never deleted by it.
Provably fair
For tenants with provably fair enabled, the round's one draw is derived from the committed server seed at the bare round block (clientSeed:nonce, no sub-nonce), purpose label build: a uniform integer in [0, W − 1], where W is the ladder's total weight for the round's variant and cap. The published paytable (type city_ladder) carries the twelve tiers — name, multiplier and base weight — and the ladder's SHA-256 (ladderHash), which the verifier recomputes before reading the draw. The round record stores the round's effective cap (capHundredths); with it and the published paytable that priced the round, the verifier reproduces the weights, the draw, the tier and the payout, and the verification page does the same in the browser and compares it with what the round booked. A round without a recorded cap is reported as not replayable rather than read uncapped. The plot and the neighborhood's look (a cosmetic visual seed derived from the round id) are display data. See Provably Fair.
Integration notes
- Bet:
POST /games/3d-city-neighborhoods/roundswith{ "betAmount": <whole minor units>, "plot": { "q": <integer>, "r": <integer> }, "currency": "…" }. The plot is required (integers, |q| and |r| at most 100,000; which plots can be built on is the client's concern — the plot never changes the outcome). Refused with HTTP 422 before anything is drawn or debited: a missing or invalid plot or a stake that is not a whole number of minor units (20001), an effective cap below 2× (20001, "This stake is above the maximum for this game. Lower your stake.", withdetails.reasonmax_win_capanddetails.engineCode30605), a stake under the 1.00 floor (30007) or above the maximum bet (30008), and an insufficient balance (40001). - The response settles the round: the stake debit, the draw and the credit happen in the one call (no actions, no cash-out, no open round). Its outcome carries
tier,name,family,plot,seed(the cosmetic visual seed),fullMultiplierHundredths(the tier's multiplier),multiplierHundredthsandmultiplier(what the round paid, after the cap),capped,winAmountandladderVersion— everything the client needs to build the neighborhood, and no RNG internals. - Game metadata (
rules):ladderVersion,ladderHash, the twelve tiers (tier,name,family,multiplier,multiplierHundredths),maxMultiplier(250),minCapMultiplier(2),roundMaxWin,maxWinAmountandoperatorMaxWinMultiplierwhen the operator set a cap — never weights, chances or the RTP. - Casino free chips are not offered on this game (single-step games refuse them, HTTP 409
30027). - Progressive jackpot. The game can feed your progressive jackpot like the other games: switch on Jackpot Participation for it (see Progressive Jackpots). The contribution comes out of the RTP, never on top of it (97% plays 96% + 1%). In the game the pot ticker sits in the top bar beside the balance (on desktop, just under the game's logo). Because a build's result is revealed 2.35 s after the server answers, a jackpot won on that build — and the round's
game:balanceUpdateandgame:roundEndmessages to your page — wait until the build's result is on screen (should a device stall, they go at most 10 s after construction starts). When the result is shown the game also postsroundCompletewith{ roundId, totalWin, balance }, like the other instant games. - Operator webhooks are unchanged. The
round.completedpayload carries no city data: the stored neighborhood is server-only and never part of the event stream, the hash chain or a webhook.
The account city (player data)
What is stored. One record per built plot, per player and game in your casino: the key
"q,r"(the plot) and{ "v": 1, "q", "r", "tier", "seed", "paidHundredths" }, written by the platform from the completed real-money round (never by the client), with when the plot was first built and last rebuilt. The newest round on a plot wins. At most 20,000 plots per player and game are stored (redeveloping an existing plot always updates it). Records are best effort — exactly as durable as the round itself; nothing retries a failed write, and a failed write never affects the round.Reading and deleting it (the game client does this through the player's session; the
currencyis required, the city is kept per currency):GET /api/v1/games/3d-city-neighborhoods/records?currency=<CUR>&cursor=<opaque>&limit=<1..5000> → 200 { "success": true, "data": { "storage": "account", "records": [ { "key": "3,-1", "data": { … }, "firstAt": "…", "updatedAt": "…" } ], "nextCursor": "<opaque>" | null } } DELETE /api/v1/games/3d-city-neighborhoods/records?currency=<CUR> → 200 { "success": true, "data": { "storage": "account", "deleted": <n> } }Records come in the order they were first built; the client reads every page before it shows the city. A fun-play / demo session answers
{ "storage": "device", "deviceScope": "…", "records": [], "nextCursor": null }(and"deleted": 0): the platform stores nothing for it. A missing player identity is refused with 401 (10001), an unknown game with 404 (30001), a missing currency with 400 (30032), a malformedlimitorcursorwith 400 (20001), and any storage error answers 503 (50002/50004) with"retryable": true— never an empty or partial city. A page holds up tolimitrecords (default 1,000, at most 5,000). The routes have their own rate limits per player (reads 30 per 10 seconds, deletes 5 per minute), separate from the betting limit.Kept until the player starts fresh. Start a fresh city deletes that player's records for the game in one step and remembers when. The rounds and their history stay, and a round that completed before the reset never re-enters the new city.
Known limit. An account city belongs to the tenant. On an aggregator the tenant is the (merchant, RTP listing) pair, so a player moved to another RTP listing starts a new city there.
Personal data. An account city is per-player data: include it when you answer a data-subject access or erasure request — ask Slotty Labs to export or erase a player's city.