Skip to content
SlotShop/dev

· 2 min read

Building for Stake Engine: the short version

A primer on what shipping a slot game to Stake Engine actually involves — and where most builds get caught.

Stake Engine is Stake.com's slot game platform — a CDN-served, fully client-side runtime that talks to an external RGS over HTTP. The deployment shape is simple: zip a static out/ bundle and upload it. The substance is anything but.

The actual deliverable

A Stake Engine game is a single static site. That's it. No server. No backend. Everything is the browser.

// next.config.ts
const nextConfig = {
  output: 'export',
  images: { unoptimized: true },
  assetPrefix: './',
}

That assetPrefix: './' is non-negotiable — Stake serves your game from a subdirectory CDN path. Without relative chunks, every _next/ URL 404s on production.

What fails in review

The same things, every time:

  • Restricted words. "buy", "bet", "cost", "wager", "cash" — anywhere in user-facing text outside the social-mode guard. The word "cost" is the one that slips through.
  • Zero-win endRound. A round with zero payout must not call endRound. The RGS doesn't expect it.
  • Insufficient-balance play. Same rule, other side — block the call client-side.
  • Hardcoded bet levels. Bet levels come from the authenticate response. Hardcoding them anywhere fails the multi-currency tests.
  • Replay panel. Event ID = csv_id − 1. Final multiplier = total win ÷ base bet, never ÷ cost multiplier. The panel must counter-scale at the smallest popout size without covering the reels.

Every game I ship goes through a hand-written checklist before submission that catches each of these. The list grew from the things that have failed in the past. That list is now the gate.

Why this site exists

So clients can watch this process happen instead of waiting for a zip.