Home/About/aboutProjects/projectsLab/backend-labiGaming/i-gamingBlog/blogRésumé/resumeContact/contact
iGaming lab
API-backed demo

Double Diamond

REST · 3×3 reel matrix
Server-backed slot engineNext
native.typescript / IGT

Double Diamond

Calibrated reel strips, recognizable symbols, and server-owned win evaluation behind a responsive slot cabinet.

connecting
Demo credits1,000.00
Total bet1.00
Last payout0.00
Source RTP95.1097%
slot.cabinet / spin 0003 REELS · 1 LINE
🍒
BARBARBAR
✦
REEL 01
BARBAR
💎💎
7️⃣
REEL 02
BAR
BARBARBAR
🍒
REEL 03
Spin the calibrated reel setREADY
result.contract

Normalized win records

Spin results expose pay, multiplier, payout, symbol count, line, kind, and exact screen coordinates.

engineering.case-study

Inside the Double Diamond system boundary.

What the player experiences, what the implementation actually owns, and where production responsibilities would begin.

01

Game background

Double Diamond is a classic three-reel slot format built around bars, cherries, sevens, blank stops, and a wild multiplier symbol. It is useful for demonstrating exact reel-strip sampling and rule ordering in a compact scanner.

02

How the game works

  1. Set a bet for the single fixed payline.
  2. The backend samples one stop per reel and returns a 3×3 screen.
  3. The middle row is checked for exact symbols, mixed bars, cherries, and wild substitutions.
  4. Wins are summed and returned with total bet, payout, and net result.
03

Backend architecture

A reusable SlotApiService owns an in-memory session and delegates each spin to a configured Double Diamond definition. The game samples imported strips with crypto.randomInt and evaluates wins in pure TypeScript rules.

ClientREST APIGame sessionCrypto reel stopsWin scannerResult
04

System boundaries

Game Client
Presentation, input, accessibility, and demo-credit display.
REST API
Request validation and routing into one isolated game session.
Game Session
Ephemeral configuration and the previous authoritative result.
Game Engine / RNG
Outcome generation, game rules, win evaluation, and result contracts.
Line Scanner
Exact triples, mixed bars, cherry rules, and Double Diamond multipliers.
05

Critical engineering decisions

  • Preserve the imported reel order rather than replacing it with uniform symbol selection.
  • Keep blank stops as real strip entries.
  • Represent wild substitution and 2×/4× stacking explicitly.
  • Return win coordinates so rendering does not infer game math.
06

Failure handling

  • A client disconnect does not rewrite a completed server result; reconnecting requires the session identifier while it remains in memory.
  • An unknown or expired session is rejected instead of silently creating a replacement outcome.
  • A timed-out spin or draw should not be blindly retried as though commands were idempotent; these demos do not yet persist command identifiers.
  • The browser’s virtual credits are not a ledger. If UI credit state is lost, it cannot be reconstructed from these focused game-engine modules.
07

Fairness / RNG

Each reel stop uses backend crypto.randomInt. The displayed source RTP describes the imported strip model; the demo is not certified and has no provably-fair proof.

08

Conceptual data model

GameSession- gameId- betPerLine- selectedLines- lastActivity
SpinResult- screen- wins- totalBet- totalPayout- net
Win- line- symbol- count- positions- multiplier- payout