Skip to main content
The Stake Engine Web SDK is an open-source monorepo framework for building casino games that run on the Stake Engine Remote Game Server (RGS). It gives you a fully wired-up development environment—complete with component isolation, a local test harness, and a one-command build pipeline—so you can focus on the game itself rather than the infrastructure around it. You can use the SDK in two ways:
  • Deploy on Stake Engine — build a game using the provided patterns and launch it directly on the platform.
  • Starting point for custom implementations — fork the repo and modify any part of the source code. You have 100% freedom over the codebase.

​
Key technologies

The SDK is powered by the following npm packages:
TechnologyPurpose
Svelte 5Reactive UI framework for game components
PixiJS 8WebGL-accelerated 2D rendering
pixi-svelteIn-house package combining PixiJS and Svelte for declarative canvas rendering
SvelteKitApplication framework and build pipeline
TurboRepoMonorepo task orchestration
XStateFinite state machine for bet lifecycle management
StorybookComponent isolation and game testing environment
LinguiInternationalisation
TypeScriptType safety across the monorepo
pnpmPackage manager with workspace support

​
The Stake Engine platform

Stake Engine (engine.stake.com) is the RGS that sits behind every game. When a player places a bet, the RGS returns a book—a JSON object containing a sequence of bookEvents that fully describes how that round plays out. The SDK’s architecture is built around consuming those bookEvents in order.

​
Architecture overview

The data flow from RGS to screen follows a single, consistent pipeline: 
RGS → book → bookEvents → bookEventHandlerMap → emitterEvents → Svelte components
  1. RGS returns a book for each game request.
  2. playBookEvents() iterates through book.events in sequence—order matters because it determines the visual behaviour (e.g. spin before win).
  3. Each bookEventHandler in bookEventHandlerMap processes one event type. It typically broadcasts one or more emitterEvents via eventEmitter.
  4. Svelte components subscribe to emitterEvents with eventEmitter.subscribeOnMount() and handle them synchronously or asynchronously—waiting for animations to finish before the sequence continues.
This event-driven architecture (see the bookEvent and emitterEvent concepts) keeps game logic decoupled from rendering and makes every step independently testable in Storybook.

​
Monorepo structure

The repository follows a standard TurboRepo layout: 
root
  |_apps          # Individual game applications
  |  |_cluster
  |  |_lines
  |  |_number-picker
  |  |_price
  |  |_scatter
  |  |_ways
  |
  |_packages     # Shared modules
     |_config-*
     |_constants-*
     |_state-*
     |_utils-*
     |_components-*
     |_pixi-*
/apps — each folder is a complete, runnable game. The lines game is the primary reference implementation used throughout this documentation. /packages — shared modules consumed by apps and other packages via workspace:* dependencies. They follow a <type>-<scope> naming convention (e.g. utils-book, components-ui-pixi).

Quickstart

Get the SDK running locally in minutes with Storybook.

Book and Events

Understand the bookEvent and emitterEvent architecture.

Packages

Explore the shared packages available across the monorepo.

Build docs developers (and LLMs) love

Get started for freeTalk to us