--- name: html5-canvas-game-development description: Class-level patterns for extending HTML5 Canvas games without rewriting core logic, especially mobile/touch adaptation and browser-based online multiplayer. version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [html5, canvas, games, mobile, touch, multiplayer, websocket] related_skills: [systematic-debugging] --- # HTML5 Canvas Game Development ## Overview Use this for the common class of work where an existing browser Canvas game must gain major new capabilities without a full engine rewrite. The reliable strategy is adaptation-by-injection: preserve the game loop and state model, then bridge new inputs, layouts, and networking into it. ## When to Use - Porting a desktop Canvas game to mobile portrait play - Adding touch controls to a keyboard-driven game - Adding online multiplayer to a local-only/deterministic game - Fixing Canvas/HTML overlay interaction issues on responsive layouts ## 1. Mobile/touch adaptation Key pattern: inject touch state into the same `heldKeys` / `pressedKeys` structures the game already reads. Important lessons: - adapt camera width/viewport first; do not rewrite game logic - keep SCENE_HEIGHT unchanged when narrowing mobile view, or portrait letterboxing gets ugly - use HTML controls for touch input instead of Canvas hit-testing - prevent browser scroll/zoom aggressively on the game/control surfaces HUD/layout lesson: - many games call `setTransform(...)` internally, which clobbers parent scale wrappers - scale HUD coordinates directly instead of relying on one outer `context.scale()` wrapper ## 2. Online multiplayer Preferred architecture for existing browser games: - P1 host runs the full simulation - P2 sends inputs via WebSocket relay - P1 injects remote inputs, simulates, and broadcasts state back - server stays a dumb relay, not a full game server This avoids a huge rewrite while still giving usable real-time multiplayer. ## 3. HTML overlays beat Canvas UI For lobbies, room codes, buttons, and actionable text: - use HTML overlays, not canvas-drawn controls - Canvas text becomes fragile under CSS scaling and mobile layouts - HTML is easier for copying links, accessibility, touch handling, and responsive styling ## 4. Performance and sync For multiplayer sync: - send state every second frame when possible - shorten JSON keys / use delta compression - send remote inputs only on change - interpolate positions client-side while snapping discrete animation/state fields ## Common Pitfalls 1. `setTransform()` silently wiping out outer scaling assumptions 2. Canvas-drawn UI becoming unusable under `object-fit` / viewport scaling 3. Using fixed-position HTML controls that overlap mobile touch controls 4. Attempting a headless authoritative server rewrite when P1-host relay would suffice 5. Forgetting to handle Blob/ArrayBuffer WebSocket payloads in browsers ## Verification Checklist - [ ] Touch input maps into existing keyboard-style input state correctly - [ ] Mobile portrait layout leaves room for controls and avoids severe letterboxing/cropping - [ ] HUD elements remain positioned/scaled correctly on mobile - [ ] Multiplayer host/remote flows exchange inputs and render synchronized state - [ ] Lobby and buttons are HTML overlays, not fragile Canvas controls