TOP engines on which modern slots are created

The modern slot is a bundle: client engine (render/UX) + game result server (RGS/RNG/mathematics). In this article, we will focus on client engines and HTML5 frameworks through which 2D/pseudo-3D slots, bonuses and intro scenes are collected. In the end - briefly about the server side.

💡 Format: for each engine - when to choose, strengths, limitations, typical slot cases.

1) PixiJS (+ native slot framework)

When to choose: de facto standard for 2D/WebGL slots and light pseudo-3D effects in the browser and WebView.

Strengths

Pure WebGL/Canvas, high performance on mobile.

Flexibility: It's easy to build your own slot framework (state machine, feature hooks, timelines).

A huge ecosystem of plugins, font/sprite rendering, filters/shaders.

Restrictions

There is no built-in "slot logic": everything is with your own hands (or with the in-house SDK).

3D - limited (you need your own shader tricks).

Cases

Fast reels 60 FPS, cascades, hold & spin, "book" extensions, rich side animation.

2) Phaser 3

When to choose: fast start in 2D, prototypes and mid-scale production with good tilling.

Strengths

Scenes, cameras, timelines, out-of-the-box entry; fast team onboarding.

Canvas/WebGL support, good DevTools and plugins.

Convenient for demo/event slots, mini-games and bonus rounds.

Restrictions

AAA polishing of the visual and hard performance goals will require additional low-level work.

Less control over the render than in the "pure" PixiJS.

Cases

Fast prototype → production, in-game "shows," tournament mini-games.

3) Unity (WebGL/mobile)

When to choose: complex visual scenes, 2. 5D/3D, a single code for WebGL + iOS/Android.

Strengths

Rich editor, timeline/animator, VFX Graph, Addressables.

A large command can parallel the UI/art/log; export to native (IL2CPP) and WebGL.

Convenient for live shows/TV-quality intro, complex bonuses, 2. 5D scenes.

Restrictions

WebGL bundles are heavy (split/compression is important), memory requirements.

Web performance is inferior to specialized WebGL engines on weak devices.

Cases

Pseudo-3D drums, cinematic bonus scenes, branded IP.

4) PlayCanvas

When to select: web-first 3D/2. 5D with visual editor and light bundles.

Strengths

Native WebGL engine, cloud editor, excellent boot performance.

Good for 3D elements in the slot: scenes with a camera, parallax, interactive bonuses.

Restrictions

Scenes/materials are simpler than in Unity/Unreal; 2D-UI layer will require discipline.

Cases

3D covers, spinning wheels, light bonus arenas without heavy code.

5) Cocos Creator

When to choose: mobile 2D/2. 5D, export to native and web, strong scene editor.

Strengths

Component model, UI system, Spine/DragonBones, convenient animations.

Good editor ↔ performance balance for slots.

Restrictions

The web part requires careful optimization on weak Android.

Less ready-made "casino" -plagins for Western pipelines.

Cases

Mobile slots with dense animation, mini-games "on top" of the lobby.

6) Defold

When to choose: lightweight, stable 2D slots with very small bundles and strict performance.

Strengths

Small runtime, predictable memory, Lua scripting.

Good for mass web campaigns and entry-level devices.

Restrictions

Less editorial bells and whistles out of the box than Unity/Cocos.

3D/shader exoticism - hands.

Cases

High-frequency 2D slots, event landing pages with demos.

7) Godot (4. x, Web export)

When to choose: open source, convenient timelines, fast iterations; flexible for R&D and internal instruments.

Strengths

Node-based scenes, animation graphs, GDScript/C #/C + +.

Web export has improved, convenient for editors and prototype bonuses.

Restrictions

For a large web program, it is better to test the pen on different browsers; the casino plugin ecosystem is small.

Cases

Designer tools, feature previews, part of 2D production slots.

8) Haxe + OpenFL/Lime

When to choose: cross-compilation, strong typing, "old school" commands from the Flash world.

Strengths

High performance 2D, reuse code between web/desktop/mobile.

It is convenient to write slot logic type-safe.

Restrictions

Fewer ready-made visual editors "like Unity."

There are fewer specialists than JS/TS.

Cases

Long-lived 2D company frameworks, slot farms.

9) Three. js (+ native 2D/GUI layer)

When to choose: custom 3D scenes/effects in the browser if you need full control of WebGL.

Strengths

Shader freedom, materials, post-effects; ideal for signature visuals.

Can be combined with PixiJS/Canvas-UI.

Restrictions

There are no "slot" primitives - everything is designed manually.

Requires expertise in rendering and optimizations.

Cases

Wow Intro, custom bonuses, premium IP projects.

10) In-house HTML5 engines (custom)

When to choose: large slot portfolios, strict SLAs, deep integration with RGS/wallet/feature framework.

Strengths

Maximum performance and control: state machines, feature hooks, DSL, replays, WORM logs.

Quick releases from editors, live tuning without changing mathematics.

Restrictions

Cost of ownership: platform team, documentation, certification.

Longer entry for beginners.

Cases

Content providers/operators with dozens of releases per year and uniform guidelines.

Quick selection for the task

Pure 2D web (mobile focus, light bundle): PixiJS/Phaser/Defold

Pseudo-3D and show scenes on the web: PlayCanvas/Three. js (+ PixiJS for UI)

One project for Web + iOS/Android with heavy visuals: Unity

2D + R&D Editorial Development: Cocos Creator/Godot

Type-safe "framework-factory" 2D: Haxe/OpenFL

Large line of slots with common features/editors: In-house engine

What is important over the engine

1) Performance and size

WebGL/Canvas, butching, sprite atlases, lazy-loading bonus scenes.

WASM/SIMD - for simulators/heavy calculations.

Goals: First Playable <5-10 s, stable 60 FPS on reference devices.

2) Command tools

Editors (reels/pay tables/timelines), seed/step replays, logs (WORM/merkle chains).

Feature flags, canary, A/B and dashboards.

3) Honesty and compliance

Server-authoritative outcome, RNG streams, ban '% N' - alias/rejection only.

Jurisdictions: auto-spins, buy-feature, minimal RTP - via configs.

Responsible Gaming: "quiet mode," reality checks, limits.

4) Server Integration (RGS)

Idempotent transactions: lock → outcome → settle.

Telemetry ≠ audit: reporting separately from product analytics.

Scaling: stateless services, low latency spin API.

Mini-FAQ

Does Unity need slots?

Only if you have 2. 5D/3D scenes, heavy intros, a single code base for native applications and the web. For a pure 2D web, PixiJS/Phaser is simpler and lighter.

Where is it better to make "branded" effects?

Three. js/PlayCanvas for 3D, or proprietary shaders and filters in PixiJS. It is important to keep LODs and GPU budgets.

Open-source or commerce?

Opensors (PixiJS, Phaser, Godot, Defold, Three. js) covers 90% of the tasks. Commerce is justified if you need a supported editor/support/plugins for your pipeline.

Engine selection checklist

Target Platforms: Web/iOS/Android/WebView
Visual: 2D/2. 5D/3D, cinematic scenes available
Bundle: Target Size and First Playable
Team: Expertise JS/TS vs Unity/C # vs Lua/Haxe
Tools: do you need a visual editor "for designers"
Integration: RGS, wallet, telemetry, certification
Economics: TCO, licenses, onboarding speed of new developers

Server Side Brief (RGS)

Whichever client you choose, the spin outcome is on the server: RNG/mathematics, symbol mapping, audit logs, idempotent calculations and payments. Typical stacks are: Node/Go/Java/Kotlin, online Feature Store, Kafka/streaming, RNG test batteries (NIST/TestU01), (10 ^ 7-10 ^ 8) spin simulations for RTP/volatility validation.

There is no single "ideal" engine - there is compliance with the tasks. For mass mobile web slots, the leader is PixiJS/Phaser; for 2. 5D/3D and cross-platform production - Unity/PlayCanvas; for light assemblies and stability - Defold/Cocos; for R&D and instruments - Godot; for complete control - in-house. The stack wins, which combines: performance, tilling for the team, honesty of the outcome and speed of releases.