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

Captain's Treasure

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

Captain's Treasure

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

connecting
Demo credits1,000.00
Total bet9.00
Last payout0.00
Source RTP95.3531%
slot.cabinet / spin 0005 REELS · 9 LINES
⚓
⚔️
J
REEL 01
K
🏴‍☠️
🗺️
REEL 02
💼
⚔️
A
REEL 03
Q
🏴‍☠️
⚓
REEL 04
🗺️
⚔️
10
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 Captain's Treasure system boundary.

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

01

Game background

Captain’s Treasure is a five-reel, nine-line slot model with wild multiplication, scatter evaluation, and pays that may begin from either edge. It highlights overlap prevention and the need to preserve direction in normalized win results.

02

How the game works

  1. Configure bet per line and the number of active paylines.
  2. The backend samples five calibrated reel strips.
  3. Each active line is scanned from left and right, followed by scatter evaluation.
  4. Wild multipliers and accepted directional wins are combined into the spin payout.
03

Backend architecture

The shared session and CSPRNG layer feeds Captain’s Treasure’s bidirectional evaluator. The evaluator tracks positions, prevents overlapping directional awards, applies wild multipliers, and adds scatter wins independently.

ClientREST APIGame sessionReel samplerL→R / R→L 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.
Bidirectional Scanner
Left/right runs, overlap rules, wild multiplication, and scatter results.
05

Critical engineering decisions

  • Evaluate both directions explicitly instead of reversing UI data.
  • Prevent the same cells from being paid twice through overlap rules.
  • Keep wild multiplication attached to the evaluated run.
  • Return direction-neutral coordinates for presentation.
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

Reel stops use backend cryptographic selection against imported strips. RTP remains source-model evidence, not a regulated guarantee or verifiable public proof.

08

Conceptual data model

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