Web Game Foundations
Overview
Use this skill to establish the non-negotiable architecture before implementation starts. Browser games degrade quickly when simulation, rendering, UI, asset loading, and input handling are mixed together.
Default rule: simulation state is owned outside the renderer, browser UI is not forced into the canvas unless there is a clear reason, and shipped 3D assets default to GLB or glTF 2.0 rather than ad hoc model formats.
Use This Skill When
- the user has not settled the engine or renderer choice
- the task is about boundaries, module shape, state ownership, or asset policy
- multiple specialist skills need one shared architectural frame
Do Not Stay Here When
- the runtime track is clearly Phaser
- the runtime track is clearly vanilla Three.js
- the runtime track is clearly React Three Fiber
- the task is purely about shipped 3D assets
Once the stack is clear, hand off to the runtime or asset specialist skill.
Architecture Rules
- Separate simulation from rendering.
- Simulation owns entities, turns, timers, collisions, progression, and saveable state.
- The renderer owns scene composition, animation playback, camera, particles, and input plumbing.
- Keep input mapping explicit.
- Define actions such as
move, confirm, cancel, ability-1, and pause.
- Map physical inputs to actions in one place.
- Treat asset loading as a first-class system.
- Use stable manifest keys.
- Group by domain: characters, environment, UI, audio, FX.
- For 3D content, standardize on GLB or glTF 2.0 unless the chosen engine ecosystem requires another format upstream.
- Define save/debug/perf boundaries up front.
- Save serializable simulation state, not renderer objects.
- Keep debug overlays and perf probes easy to toggle.
- Use DOM overlays for menus and HUD by default.
- Canvas or WebGL should handle the playfield.
- DOM should handle text-heavy HUD, menus, settings, and accessibility-sensitive controls.
- In 3D, keep the persistent UI budget small so the scene stays readable and interactive.
- Lock 3D runtime conventions early.
- Choose consistent units, origins, pivots, and naming conventions.
- Decide how collision proxies, LODs, and baked lighting data are authored before runtime integration starts.
Engine Selection
- Default to Phaser for 2D games with sprites, tilemaps, top-down or side-view action, turn-based grids, and classic browser arcade flows.
- Default to vanilla Three.js for explicit 3D scenes that want direct scene, camera, renderer, and loop control in plain TypeScript or Vite.
- Default to React Three Fiber when the 3D scene lives inside a React application and needs declarative composition, shared app state, or React-first UI coordination.
- Use raw WebGL only for shader-heavy or renderer-first projects where engine abstractions would get in the way.
- Keep Babylon.js and PlayCanvas as alternative-engine paths rather than the default code-generation target.
See ../../references/engine-selection.md for the default decision table.
Implementation Checklist
Define these before writing core code:
- Player fantasy and primary verbs
- Core loop and loss or reset states
- Camera model
- Input action map
- Simulation modules
- Renderer modules
- Asset manifest layout
- 3D asset format and optimization rules
- HUD and menu surfaces
- Save data boundary
- Debug and perf surfaces
Anti-Patterns
- Mixing gameplay rules directly into scene callbacks
- Treating the renderer as the source of truth for game state
- Putting all HUD and menu UI into the canvas by default
- Letting asset filenames become the public API instead of manifest keys
- Shipping unoptimized 3D assets straight from the DCC tool into the browser
- Mixing camera-control state and menu or modal state without an explicit input boundary
- Rebuilding architecture every time the game changes genre
References
- Engine selection:
../../references/engine-selection.md
- Phaser structure:
../../references/phaser-architecture.md
- Three.js structure:
../../references/three-webgl-architecture.md
- Three.js ecosystem stack:
../../references/threejs-stack.md
- React Three Fiber stack:
../../references/react-three-fiber-stack.md
- 3D asset shipping:
../../references/web-3d-asset-pipeline.md
1---2name: web-game-foundations3description: Set browser-game architecture before implementation. Use when the user needs engine choice, simulation and render boundaries, input model, asset organization, or save/debug/performance strategy.4---56# Web Game Foundations78## Overview910Use this skill to establish the non-negotiable architecture before implementation starts. Browser games degrade quickly when simulation, rendering, UI, asset loading, and input handling are mixed together.1112Default rule: simulation state is owned outside the renderer, browser UI is not forced into the canvas unless there is a clear reason, and shipped 3D assets default to GLB or glTF 2.0 rather than ad hoc model formats.1314## Use This Skill When1516- the user has not settled the engine or renderer choice17- the task is about boundaries, module shape, state ownership, or asset policy18- multiple specialist skills need one shared architectural frame1920## Do Not Stay Here When2122- the runtime track is clearly Phaser23- the runtime track is clearly vanilla Three.js24- the runtime track is clearly React Three Fiber25- the task is purely about shipped 3D assets2627Once the stack is clear, hand off to the runtime or asset specialist skill.2829## Architecture Rules30311. Separate simulation from rendering.32 - Simulation owns entities, turns, timers, collisions, progression, and saveable state.33 - The renderer owns scene composition, animation playback, camera, particles, and input plumbing.342. Keep input mapping explicit.35 - Define actions such as `move`, `confirm`, `cancel`, `ability-1`, and `pause`.36 - Map physical inputs to actions in one place.373. Treat asset loading as a first-class system.38 - Use stable manifest keys.39 - Group by domain: characters, environment, UI, audio, FX.40 - For 3D content, standardize on GLB or glTF 2.0 unless the chosen engine ecosystem requires another format upstream.414. Define save/debug/perf boundaries up front.42 - Save serializable simulation state, not renderer objects.43 - Keep debug overlays and perf probes easy to toggle.445. Use DOM overlays for menus and HUD by default.45 - Canvas or WebGL should handle the playfield.46 - DOM should handle text-heavy HUD, menus, settings, and accessibility-sensitive controls.47 - In 3D, keep the persistent UI budget small so the scene stays readable and interactive.486. Lock 3D runtime conventions early.49 - Choose consistent units, origins, pivots, and naming conventions.50 - Decide how collision proxies, LODs, and baked lighting data are authored before runtime integration starts.5152## Engine Selection5354- Default to Phaser for 2D games with sprites, tilemaps, top-down or side-view action, turn-based grids, and classic browser arcade flows.55- Default to vanilla Three.js for explicit 3D scenes that want direct scene, camera, renderer, and loop control in plain TypeScript or Vite.56- Default to React Three Fiber when the 3D scene lives inside a React application and needs declarative composition, shared app state, or React-first UI coordination.57- Use raw WebGL only for shader-heavy or renderer-first projects where engine abstractions would get in the way.58- Keep Babylon.js and PlayCanvas as alternative-engine paths rather than the default code-generation target.5960See `../../references/engine-selection.md` for the default decision table.6162## Implementation Checklist6364Define these before writing core code:6566- Player fantasy and primary verbs67- Core loop and loss or reset states68- Camera model69- Input action map70- Simulation modules71- Renderer modules72- Asset manifest layout73- 3D asset format and optimization rules74- HUD and menu surfaces75- Save data boundary76- Debug and perf surfaces7778## Anti-Patterns7980- Mixing gameplay rules directly into scene callbacks81- Treating the renderer as the source of truth for game state82- Putting all HUD and menu UI into the canvas by default83- Letting asset filenames become the public API instead of manifest keys84- Shipping unoptimized 3D assets straight from the DCC tool into the browser85- Mixing camera-control state and menu or modal state without an explicit input boundary86- Rebuilding architecture every time the game changes genre8788## References8990- Engine selection: `../../references/engine-selection.md`91- Phaser structure: `../../references/phaser-architecture.md`92- Three.js structure: `../../references/three-webgl-architecture.md`93- Three.js ecosystem stack: `../../references/threejs-stack.md`94- React Three Fiber stack: `../../references/react-three-fiber-stack.md`95- 3D asset shipping: `../../references/web-3d-asset-pipeline.md`