Casino Slots Engine
The Slots Engine is too heavy to present as a public demo because it includes provider APIs, database-backed game configuration, provably-fair kernels, iframe embedding, admin tooling, and game clients. The right portfolio format is a structured technical documentation page with selected screenshots, architecture notes, and runbook references.
Monorepo with provider-api, iframe-runtime, admin-web, casino-web, game packages, SDKs, and infra docs
Do not deploy the full engine as a public portfolio app. Publish the rendering architecture, provider API map, game catalog notes, and selected gameplay/admin screenshots as SFreedom docs.
Highlights
Outcome-first engine with replaceable presentation
The important story is the boundary between money/outcome logic and presentation. Static SFreedom docs can explain the real architecture without exposing a casino runtime publicly.
Provider API
NestJS API for sessions, spins, game configuration, operator setup, catalog surfaces, and server-side settlement paths.
- Owns the authoritative money path and outcome generation.
- Exposes API documentation and OpenAPI-style references when running locally.
- Connects to PostgreSQL and Redis infrastructure for local and provider-style workflows.
Core game packages
Provably-fair kernels, family math, game definitions, combinations, RTP/win-frequency logic, and replayable outcome data.
- Renderer-agnostic by design.
- Uses integer/BigInt money paths where required.
- Provides the source material for detailed game documentation pages.
iframe-runtime
Secure embedding shell for postMessage communication, bootstrap, session context, preload, audio unlock, and theme handoff.
- Hosts the game but does not decide outcomes.
- Documents a stable postMessage v1 contract for host/operator integration.
game-client
Interactive game presentation for reels, clusters, scatter-pays, instant games, plinko, and related UI.
- Current implementation is presentation-focused and can be documented with screenshots and state diagrams.
- Target architecture describes layered Pixi scenes, symbol state machines, FX layers, and ThemeConfig-driven skins.
admin and operator tooling
Operational interfaces for tenant/provider management, game configuration, analytics, and setup workflows.
- Best shown through static annotated screens and runbook excerpts.
- Does not require public deployment to prove implementation quality.
Delivered work
Engine and API work record
- Provider API surface for sessions, games, operator bootstrap, wallet callbacks, and game execution paths.
- Game catalog and family-level engine organization for multiple slot mechanics.
- SDK and conformance package boundaries for integration quality.
- Runbooks, DR plan, status-page notes, and OpenAPI references for operational clarity.
Rendering and frontend work record
- Documented current DOM/CSS/Canvas2D baseline and target PixiJS runtime architecture.
- Defined layered renderer model: background, board, FX, UI, and overlay layers.
- Defined symbol state-machine model for IDLE, SPINNING, LAND, WIN, and DISAPPEAR states.
- Separated renderer presentation from server-side outcome and settlement logic.
Documentation-ready artifacts
- Game rendering architecture notes.
- Per-game UI module architecture and migration model.
- Provider API docs, OpenAPI specs, postMessage contract, analytics docs, and responsive testing matrix.
Modules and demo strategy
Game families
Organizes distinct mechanics such as reels, clusters, megaways, scatter-pays, hold-and-win, plinko, and instant games.
- Each family can get a short public doc page with mechanic, UX, and architecture notes.
- Math and settlement details should stay summarized unless disclosure is intended.
Rendering runtime
Explains how game outcomes become animation timelines and user-facing presentation.
- Use diagrams and screenshots instead of deploying real-money flows.
- Show the Pixi target model as a technical direction without overclaiming current state.
Provider operations
Shows how operators, sessions, wallets, configuration, status, and runbooks fit together.
- Make operational maturity visible with docs and runbook excerpts.
- Keep secrets, credentials, and live endpoints out of public pages.