Browser Game Development
A browser game — any game running without installation. Behind this simple definition are three fundamentally different technologies: Unity WebGL, three.js / Babylon.js (native WebGL), and Phaser (2D Canvas/WebGL). Stack choice determines both possibilities and limitations.
When to choose what
Unity WebGL — if team already works with Unity, if porting from mobile/PC, if complex physics or 3D needed. Compiles to WebAssembly, heavy initial build (10-50 MB), but full Unity ecosystem access.
Phaser 3 — for 2D games created for browser from start. JavaScript/TypeScript, light build (few MB), excellent SpriteBatch, Tilemaps (Tiled integration) support, physics via Arcade (simple) or Matter.js (complex). Good choice for casual games, puzzles, platformer demos.
Three.js / Babylon.js — for interactive 3D experiences, not classic games. Marketing demos, configurators, showrooms. Babylon.js has more complete game framework; Three.js — better plugin ecosystem.
PixiJS — pure 2D WebGL renderer, maximum performance for 2D. No game logic from box, but fantastically fast for sprites and particles.
Technical constraints of browser games
What can't be done in browser
- Direct file system access (only IndexedDB via Web Storage API, or File System Access API with explicit permission)
- UDP sockets for multiplayer — only WebSocket (TCP) or WebRTC DataChannel (UDP-like, via STUN/TURN)
- Background threads without WebWorker — all JavaScript single-threaded by default
- Persistent processes — tab closed, game dead. State — only in LocalStorage/IndexedDB/Cookie
Loading and TTFP (Time To First Play)
User opened link. If after 5 seconds they see nothing interesting — some close the tab. Load optimization — not optional task.
Progressive loading pattern: first load minimum for first screen display (logo, loading screen with animation), background — main assets. For Unity WebGL: first frame via compressed data.unity3d with Bootstrap loader. For Phaser: Phaser.Loader with onProgress callback + preloaded scene.
Service Worker for caching: after first load assets cache, second visit — instant. Via Workbox or manually via Cache API. Important: cache versioning on game update.
Saves and persistence
For browser games no standard PlayerPrefs equivalent. Options:
- LocalStorage — 5-10 MB, synchronous, strings only. For small saves.
- IndexedDB — practically unlimited, async, structured data. For full save files. Access via Dexie.js (wrapper with normal API).
- Cloud saves — only way to transfer progress between devices. Firebase Firestore, PlayFab CloudSave, or custom API.
Unity WebGL IndexedDB access — via jslib plugin with JS call from C#.
Multiplayer in browser
Most non-trivial part. UDP unavailable directly.
WebSocket — TCP, slightly higher latency than UDP, but stable. For turn-based games, chat, async PvP — sufficient. Socket.io on server (Node.js) or Photon Realtime with WebSocket transport.
WebRTC DataChannel — UDP-like data transmission peer-to-peer or through server. Used in games where latency critical (shooters, racing). Requires STUN/TURN infrastructure (coturn — open source TURN server). Significantly more complex than WebSocket.
For Unity WebGL multiplayer — Mirror with SimpleWebTransport (WebSocket) or Photon Fusion (WebSocket relay). UDP-rollback netcode in browser unavailable without WebRTC.
Platform integration
Browser games often embedded in third-party platforms: Yandex Games, VK Play, CrazyGames, itch.io, Kongregate.
Each platform has own SDK for:
- Auth (OAuth via postMessage between iframe)
- Leaderboards
- Ads (rewarded video, interstitial)
- Payments (Yandex Games and VK Play — own currency)
Yandex SDK: ysdk.init() → auth via ysdk.getPlayer() → ads via ysdk.adv.showRewardedVideo(). For Unity — Yandex provides official plugin, but works only with IL2CPP build (not Mono).
Development process
Stack choice and architecture (1-3 days). Genre, target platform, team — all determine Unity WebGL vs. Phaser vs. native WebGL.
Development with browser-first mindset. Weekly — test in browser, not only in editor/local server. Browser behavior differs from native: audio context requires user gesture to start, iframe limits API access.
Build optimization (1-3 days before release). Size, load time, browser compatibility.
QA. Chrome, Firefox, Safari Desktop, Chrome Mobile, Safari iOS. BrowserStack for automation.
| Game Type | Stack | Approximate Timeline |
|---|---|---|
| 2D casual | Phaser 3 | 1-4 weeks |
| Marketing 3D demo | Three.js / Babylon.js | 1-3 weeks |
| Mobile game port | Unity WebGL | 1-4 weeks (depends on adaptation) |
| Midcore with multiplayer | Unity WebGL + Photon | 1-2 months |
| Platform integration | Depends on platform | +1-2 weeks to main development |
Cost calculated after clarifying genre, target platform, and multiplayer or payment integration requirements.