Web Browser Game Development
Framework selection and browser-specific principles. For stack choice details see game-development/engine-selection.
1. Framework Selection
Decision Tree
What type of game?
│
├── 2D Game
│ ├── Full game engine features? → Phaser 4
│ ├── Fast prototype / jam? → Kaplay
│ ├── Raw rendering power? → PixiJS 8
│ └── Tiny / no dependency? → Raw Canvas / WebGL
│
├── 3D Game
│ ├── Full engine (physics, XR)? → Babylon.js
│ └── Rendering focused? → Three.js
│
├── Hybrid (DOM UI + canvas moments)
│ └── Custom shell + guest viewport
│ (Canvas/Kaplay/Phaser/Pixi inside a region/modal)
│
└── Narrative-first
└── Ink (inkjs) or Twine export + DOM host
Comparison
| Framework |
Type |
Best For |
| Raw Canvas / WebGL |
2D / low-level |
Small scope, full control |
| Kaplay |
2D toolkit |
Rapid prototypes |
| Phaser 4 |
2D engine |
Full game features |
| PixiJS 8 |
2D renderer |
Rendering, custom systems |
| Three.js |
3D renderer |
Visualizations, lightweight 3D |
| Babylon.js |
3D engine |
Full engine, XR |
Hybrid shell + guest
Use when chrome is HTML (menus, inventories, text, dashboards) but bursts of play need a canvas:
- Mount guest in a container; pass context in.
- Run a local game loop in the guest.
- Return results (score, pass/fail); destroy guest (RAF, listeners, GL context as needed).
Do not let the guest own global app routing unless the product is a full-screen game.
2. WebGPU Adoption
Browser Support (2025)
| Browser |
Support |
| Chrome |
✅ Since v113 |
| Edge |
✅ Since v113 |
| Firefox |
✅ Since v131 |
| Safari |
✅ Since 18.0 |
| Total |
~73% global |
Decision
- New GPU-heavy projects: Use WebGPU with WebGL fallback
- Broad legacy / simple 2D: Start with WebGL or Canvas 2D
- Feature detection: Check
navigator.gpu
3. Performance Principles
Browser Constraints
| Constraint |
Strategy |
| No local file access |
Asset bundling, CDN |
| Tab throttling |
Pause when hidden (visibilitychange) |
| Mobile data limits |
Compress assets |
| Audio autoplay |
Require user interaction |
Optimization Priority
- Asset compression - KTX2, Draco, WebP
- Lazy loading - Load on demand
- Object pooling - Avoid GC
- Draw call batching - Reduce state changes
- Web Workers - Offload heavy computation
4. Asset Strategy
| Type |
Format |
| Textures |
KTX2 + Basis Universal (or WebP/PNG for simple 2D) |
| Audio |
WebM/Opus (fallback: MP3) |
| 3D Models |
glTF + Draco/Meshopt |
| Phase |
Load |
| Startup |
Core assets, <2MB |
| Gameplay |
Stream on demand |
| Background |
Prefetch next level |
5. PWA for Games
Benefits: offline play, install, fullscreen, optional push.
Requirements: service worker, web app manifest, HTTPS.
6. Audio Handling
- Create/resume
AudioContext on first click/tap
- Prefer Web Audio API; pool sources; preload common SFX
- Compress with WebM/Opus when possible
7. Anti-Patterns
| ❌ Don't |
✅ Do |
| Load all assets upfront |
Progressive loading |
| Ignore tab visibility |
Pause when hidden |
| Block on audio load |
Lazy load audio |
| Skip compression |
Compress everything |
| Assume fast connection |
Handle slow networks |
| Leave canvas engines running off-screen |
Tear down guests |
Remember: Browser is the most accessible platform. Respect its constraints.
When to Use
Use when building HTML5/WebGL/WebGPU games, choosing a browser runtime, or wiring hybrid DOM+canvas guests.
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
1---2name: web-games3description: Web browser game development. Framework selection (Phaser, PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js), hybrid DOM+canvas, WebGPU, optimization, PWA, audio unlock. Use when building HTML5/WebG4---567# Web Browser Game Development89> Framework selection and browser-specific principles. For stack choice details see `game-development/engine-selection`.1011---1213## 1. Framework Selection1415### Decision Tree1617```18What type of game?19│20├── 2D Game21│ ├── Full game engine features? → Phaser 422│ ├── Fast prototype / jam? → Kaplay23│ ├── Raw rendering power? → PixiJS 824│ └── Tiny / no dependency? → Raw Canvas / WebGL25│26├── 3D Game27│ ├── Full engine (physics, XR)? → Babylon.js28│ └── Rendering focused? → Three.js29│30├── Hybrid (DOM UI + canvas moments)31│ └── Custom shell + guest viewport32│ (Canvas/Kaplay/Phaser/Pixi inside a region/modal)33│34└── Narrative-first35 └── Ink (inkjs) or Twine export + DOM host36```3738### Comparison3940| Framework | Type | Best For |41|-----------|------|----------|42| **Raw Canvas / WebGL** | 2D / low-level | Small scope, full control |43| **Kaplay** | 2D toolkit | Rapid prototypes |44| **Phaser 4** | 2D engine | Full game features |45| **PixiJS 8** | 2D renderer | Rendering, custom systems |46| **Three.js** | 3D renderer | Visualizations, lightweight 3D |47| **Babylon.js** | 3D engine | Full engine, XR |4849### Hybrid shell + guest5051Use when chrome is HTML (menus, inventories, text, dashboards) but bursts of play need a canvas:52531. Mount guest in a container; pass context in.542. Run a **local** game loop in the guest.553. Return results (score, pass/fail); **destroy** guest (RAF, listeners, GL context as needed).5657Do not let the guest own global app routing unless the product *is* a full-screen game.5859---6061## 2. WebGPU Adoption6263### Browser Support (2025)6465| Browser | Support |66|---------|---------|67| Chrome | ✅ Since v113 |68| Edge | ✅ Since v113 |69| Firefox | ✅ Since v131 |70| Safari | ✅ Since 18.0 |71| **Total** | **~73%** global |7273### Decision7475- **New GPU-heavy projects**: Use WebGPU with WebGL fallback76- **Broad legacy / simple 2D**: Start with WebGL or Canvas 2D77- **Feature detection**: Check `navigator.gpu`7879---8081## 3. Performance Principles8283### Browser Constraints8485| Constraint | Strategy |86|------------|----------|87| No local file access | Asset bundling, CDN |88| Tab throttling | Pause when hidden (`visibilitychange`) |89| Mobile data limits | Compress assets |90| Audio autoplay | Require user interaction |9192### Optimization Priority93941. **Asset compression** - KTX2, Draco, WebP952. **Lazy loading** - Load on demand963. **Object pooling** - Avoid GC974. **Draw call batching** - Reduce state changes985. **Web Workers** - Offload heavy computation99100---101102## 4. Asset Strategy103104| Type | Format |105|------|--------|106| Textures | KTX2 + Basis Universal (or WebP/PNG for simple 2D) |107| Audio | WebM/Opus (fallback: MP3) |108| 3D Models | glTF + Draco/Meshopt |109110| Phase | Load |111|-------|------|112| Startup | Core assets, <2MB |113| Gameplay | Stream on demand |114| Background | Prefetch next level |115116---117118## 5. PWA for Games119120**Benefits:** offline play, install, fullscreen, optional push.121**Requirements:** service worker, web app manifest, HTTPS.122123---124125## 6. Audio Handling126127- Create/resume `AudioContext` on first click/tap128- Prefer Web Audio API; pool sources; preload common SFX129- Compress with WebM/Opus when possible130131---132133## 7. Anti-Patterns134135| ❌ Don't | ✅ Do |136|----------|-------|137| Load all assets upfront | Progressive loading |138| Ignore tab visibility | Pause when hidden |139| Block on audio load | Lazy load audio |140| Skip compression | Compress everything |141| Assume fast connection | Handle slow networks |142| Leave canvas engines running off-screen | Tear down guests |143144---145146> **Remember:** Browser is the most accessible platform. Respect its constraints.147148## When to Use149150Use when building HTML5/WebGL/WebGPU games, choosing a browser runtime, or wiring hybrid DOM+canvas guests.151152## Limitations153154- Use this skill only when the task clearly matches the scope described above.155- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.156- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
ranbot-ai