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

Cherry Hot

REST · 5×3 / 5 lines
Server-backed slot engineNext
native.typescript / AGT

Cherry Hot

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

connecting
Demo credits1,000.00
Total bet5.00
Last payout0.00
Source RTP95.0644%
slot.cabinet / spin 0005 REELS · 5 LINES
🍒
🍓
🍐
REEL 01
🍎
🍒
🫐
REEL 02
SCATTER
🍒
🍑
REEL 03
🍒
🍓
REEL 04
🍐
🍒
🍎
REEL 05
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 Cherry Hot system boundary.

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

01

Game background

Cherry Hot is a five-reel fruit slot combining left-aligned payline wins, a dedicated scatter, and a multiplier based on consecutive fully filled columns. It demonstrates how independent win rules must compose without losing their coordinates or provenance.

02

How the game works

  1. Choose bet per line and up to five paylines.
  2. The backend samples five strips and builds a 5×3 reel-major screen.
  3. Line wins, scatter wins, and full-column multipliers are evaluated separately.
  4. Normalized win records are returned and summed into the final payout.
03

Backend architecture

A configured slot session delegates to Cherry Hot’s multi-rule evaluator. The server sampler owns stops; the evaluator owns left-aligned matching, scatter counts, and full-column multiplication.

ClientREST APIGame sessionReel samplerMulti-rule 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.
Multi-rule Scanner
Line, scatter, and filled-column evaluations with exact coordinates.
05

Critical engineering decisions

  • Separate each win family before aggregation.
  • Keep reel-major coordinates stable in the result contract.
  • Apply fill multipliers after identifying the base combination.
  • Test full-screen multiplication with deterministic screens.
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

Five backend CSPRNG reel-stop selections determine the screen. The imported math model is testable, but this portfolio engine is not certified or provably fair.

08

Conceptual data model

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