Game tech that ships
with the product
Slot client, math, backend contracts, launch flow, and operator integration are built together. The goal is simple: a playable game that can move from demo to production without rewriting the stack.
Runtime pieces that need to agree
Game backend
Session, launch, wallet, spin, and reconciliation flows are separated by contract.
Spin runtime
The client renders the authoritative spin contract instead of guessing game state.
State storage
Round, session, transaction, and audit rows stay tied to backend source of truth.
Integration boundary
Operators integrate through explicit launch and wallet contracts.
Fail closed at the boundary
Launch, wallet, and spin flows should not invent missing state in the browser. When a contract is wrong, the mapper or API layer should expose it early.
Signed operator launch
Launch requests are scoped to operator, game, player, and session.
Server-side validation
Invalid state is rejected at the API boundary instead of hidden in the client.
Runtime diagnostics
Spin, cascade, wallet, and launch failures have traceable error paths.
Scoped access
Operator and player context is carried through launch and gameplay requests.
Contract surface
The actual build stack
PixiJS client
Slot UI runs in a WebGL renderer with responsive layout and deterministic animation steps.
Math package
Game math produces authoritative spin results consumed by backend and frontend contracts.
Launch shell
The landing and lobby flow can open a playable slot demo or an operator-scoped iframe.
Generated API clients
Frontend clients are generated from backend Swagger so contracts stay visible in code.
Contracts operators care about
The integration work is launch, session, wallet, spin, reconciliation, and support handoff.