Three.js WebGPU skills for browser games

Own the graphics layer without pretending to own the game

The browser-game route begins at the visual boundary. The application owns gameplay rules, authoritative entity state, input, networking, collision policy, physics-engine selection, save state, audio, UI, and asset delivery. The rendering route consumes declared state and turns it into a reproducible visual presentation.

Start with Choose Skills. Classify the actual truth, interaction, camera, temporal behavior, scale, entity topology, and deployment matrix. Do not call a workload game-like to justify weaker evidence or stronger hardware assumptions.

Use a concrete reference workload

The repository's reference workload is Creature Habitat, not an imaginary shipped game. It uses one world unit per metre, seconds for the shared timebase, an 80 m × 80 m ground plane, a bounded eight-contact registry, one lit scene submission, and one primary MRT with output, normal, emissive, and velocity signals. The scene integrates creatures, vegetation, bounded water, weather, camera state, shadows, and final presentation.

Its accepted correctness evidence covers the current source, native WebGPURenderer, the owner graph, contact and subject readbacks, fixed cameras, two deterministic seeds, resource inventories, and lifecycle closure. It does not contain finite GPU timestamp windows, named-adapter performance, input latency, a production asset stream, networking, or a representative player trace. Its declared 16.67 ms tier target is a design gate, not a measured result.

Use the same kind of contract for a real game:

• Positions, distances, bounds, and contact radii use metres in one declared world frame; velocity uses metres per second and time uses seconds.
• Gameplay publishes immutable current and previous entity transforms, stable entity IDs, bounded contact events, and camera intent. Rendering never becomes the authority for collision or reconciliation.
• The representative play trace names the camera path, input sequence, spawn set, weather state, event burst, quality tier, canvas size in physical pixels, DPR, and target browser/device.
• Visual acceptance names what must survive degradation: readable subject silhouette, stable camera control, collision-consistent contact effects, shadow/subject parity, and one correct final output.

Assign one owner to every visible cause

Build camera behavior around play and inspection

Use Three.js Camera Controls and Rigs when player follow, orbit, inspection, cutscene handoff, collision response, projection, depth, or floating origin changes the scene contract.

Define the source of input, update order, collision authority, interpolation, reset behavior, and exact handoff between modes. A camera discontinuity must invalidate any velocity or temporal history that depended on the previous projection. Reproducible design and far views are useful for validation, but the project also needs its representative play path.

Separate gameplay state from authored motion

Use Three.js Procedural Motion Systems for authored launch phases, recoil, spin, springs, orbiting parts, staged destruction, and deterministic transform sequences. Keep authoritative movement, physics, and network reconciliation in the game layer.

The procedural timelines demo has a current-source passing mechanism verdict for launch, spin, quaternion, interpolation, debris, and compute-storage routes. Visual correctness and lifecycle remain insufficient and GPU timing is not claimed, so it cannot set a frame budget for another game.

Route world systems by the state they own

Use Three.js Procedural Creatures when the visual workload requires generated bodies, semantic rigs, authored locomotion, or repeated creature populations. Keep authoritative entity position, collision, and reconciliation in the game layer.

Vegetation, water, and weather keep separate state and validity contracts. Use Three.js Procedural Vegetation for generated plants and population LOD, Three.js Water Optics for bounded or coastal water state and presentation, and Three.js Rain, Snow, and Wet Surfaces for precipitation, deposition, wetness, and their handoffs. Creature Habitat has source-matched accepted evidence for integrating those four domains under shared units, wind, contact snapshots, and output ownership.

The composed cause-to-image path is:

authoritative game state in metres and seconds
  -> current/previous creature pose, bounds, and bounded contact snapshot
  -> vegetation deformation + water ripples + weather receiver state
  -> camera pose/projection + one shadow owner
  -> one lit scene submission into output/normal/emissive/velocity signals
  -> admitted outline, temporal, and presentation consumers
  -> one tone-map and one output conversion
  -> physical canvas pixels

Every arrow needs a producer, consumer, units, frame or origin, sample time, version, reset condition, and lifetime owner. A contact event may affect water and grass, but it must remain the same frozen event snapshot rather than being independently rediscovered by each renderer.

Treat event effects as bounded systems

Use Three.js Particles, Trails, and Effects for sparks, debris, trails, plasma, shockwaves, and other transient visual events. Define stable event identity, pool capacity, overflow behavior, dropped-event policy, lifetime, compaction, and the relationship to scene depth.

The pooled-effects demo shows ordered compute dispatch, stable free-list identity, indirect counts, and captured output. Its overall evidence status remains incomplete because live soft-depth and GPU timestamp claims are not accepted. If the page displays this demo, the incomplete status must remain visible.

Select shadows for a moving camera

Begin with ordinary light shadows. Add cascaded, tiled, or cached coverage only when the moving camera, world extent, invalidation pattern, and measured target cost require it. Tile shadows solve coverage; they are not evidence of tile-GPU performance.

Use Three.js Scalable Real-Time Shadows for that decision. The shadow-pipeline integration demo has accepted evidence that child shadow targets feed a single final-output graph with one tone-map and output-transform owner.

Compose one final image graph

Use Three.js Image Pipeline when multiple consumers need scene color, depth, normals, velocity, emissive data, identifiers, or histories. Allocate only signals with named consumers. An outline or pick path may justify an identifier; bloom alone does not justify an emissive attachment unless selective emission is required.

Keep output conversion single-owned and reset histories after camera cuts, tier transitions, projection changes, or disocclusion conditions defined by the project. Creature Habitat provides current accepted evidence for its subject, environment, camera, shadow, and output composition. It is an integration demo, not a game benchmark, latency test, or target-device performance claim.

Trade quality against named resources

Define named quality tiers only when the project configuration or an owner manifest defines them, and state the primary play observable each tier must preserve. Classify pressure before changing quality. Fill pressure suggests DPR, overdraw, or pass scale. CPU submit pressure suggests culling or representation changes. Compute pressure suggests solver extent or dispatch cadence. Memory pressure suggests attachment, history, or residency changes.

Creature Habitat exposes three executable configurations. These are reference resource policies, not measured hardware classes:

Account for each lever explicitly:

Use Three.js Visual Validation with a fixed input trace, camera path, seed, event sequence, and quality state. Measure the composed frame on named desktop and mobile targets, including sustained behavior. Do not add timings from isolated demos.

Close deployment and interaction constraints

• Browser and device: initialize WebGPURenderer asynchronously and prove the native WebGPU backend on every claimed browser/device class. Define physical canvas size, DPR cap, GPU memory ceiling, sustained power/thermal observation window, and behavior when WebGPU is unavailable. Creature Habitat deliberately blocks fallback; it cannot prove a WebGL route.
• Assets and delivery: the game owns mesh, animation, texture, audio, compression, streaming, cache, and license policy. Record source scale, coordinate conversion, LOD bounds, texture encodings, upload peaks, and the state shown while assets are missing or evicted.
• Controls: provide one input-to-intent layer for mouse, keyboard, touch, gamepad, pointer lock, and focus changes. Only the active camera owner writes the pose. Pause or resynchronize on lost focus instead of integrating a large wall-clock delta.
• Lifecycle: define resize and DPR transactions, quality-tier rebuilds, camera-cut and respawn resets, background-tab behavior, route teardown, device-loss recovery, and disposal of render targets, storage, listeners, controls, and animation loops.
• Accessibility: expose instructions, status, menus, and critical game state in DOM or another assistive channel; support keyboard and remappable controls; do not encode essential state only through color, particles, camera shake, or audio; honor reduced-motion needs for shake, flashes, trails, and weather intensity. These remain application responsibilities.

Know when this route is a poor fit

Choose a full game engine when the primary need is an editor, physics, navigation, networking, console deployment, asset cooking, or an integrated gameplay framework. Choose a simpler Three.js/WebGL or 2D/DOM/Canvas route when the target browser matrix cannot require WebGPU or the workload does not need the specialist rendering systems. Prefer baked animation, sprite sheets, or authored assets when runtime procedural generation adds cost without required variation. Use a dedicated physics or simulation library when visual motion must affect authoritative collisions.

What this page does not claim

The pack is not a game engine. It does not own ECS architecture, networking, anticheat, physics-engine choice, collision truth, audio, UI, accessibility, asset import, compression, build delivery, or browser fallback unless fallback teaching is explicitly requested.

No local demo is a shipped customer game. Even source-matched correctness images do not prove input latency, thermal behavior, device coverage, or production frame time. The project must supply its own target matrix, representative content, play trace, failure controls, and acceptance limits.

Relevant product evidence