Develop Web Browser Games with Optimized Frameworks

This skill guides browser game framework selection and design around browser constraints. It distinguishes full game engines, rendering libraries, small toolkits, low-level canvas implementations, narrative systems, and hybrid applications with HTML interfaces around a canvas guest. The aim is to select a fitting runtime and manage its resources deliberately.

Match fuller 2D engine needs to Phaser 4, rapid prototypes to Kaplay, rendering-focused work to PixiJS 8, and very small or custom implementations to Canvas or WebGL. Three.js covers rendering-focused 3D, while Babylon.js covers fuller engine and XR needs. Ink through inkjs and Twine exports are listed for narrative-first experiences.

Use it when building an HTML5, WebGL, or WebGPU game, choosing a browser runtime, or embedding play inside a DOM application. A hybrid host should keep application routing while the guest runs a local game loop inside its container. Pass context in, return results, then destroy animation callbacks, listeners, and graphics resources as appropriate.

WebGPU availability depends on browser version, operating system, adapter, driver, and secure context. A browser-name table or historical adoption percentage cannot establish support. Check navigator.gpu, handle a missing adapter, device-creation failure, and device loss, and provide a tested fallback. Simple 2D or broad legacy support may fit Canvas or WebGL first.

Inputs include game type, engine requirements, interface structure, target devices, asset budget, and connectivity needs. Outputs are a runtime choice, resource lifecycle plan, progressive loading strategy, and browser-specific validation requirements. A separate engine-selection resource offers deeper guidance on choosing a suitable stack.

Performance priorities include compressed assets, lazy loading, object pooling, draw-call batching, and Web Workers for heavy computation. Suggested formats include KTX2 with Basis Universal for textures, WebP or PNG for simple 2D, WebM or Opus with MP3 fallback for audio, and glTF with Draco or Meshopt for models. Load core assets first, stream gameplay assets as needed, and prefetch later content.

Pause when the tab is hidden and respect user-granted file access. Audio begins from a click or tap; reuse decoded buffers but create a fresh one-shot AudioBufferSourceNode for each playback. Avoid blocking initial interaction on all audio loading.

PWA installation, offline play, fullscreen, and optional push are separate capabilities. Installation requirements vary by browser. A service worker can support offline behavior, but installation alone does not make gameplay work offline. Implement and test cache updates, version transitions, and recovery from offline failures before claiming those behaviors.