threejs-game

Structure a three.js game around explicit services: a GameApp entry, renderer, camera, and scene services, an input layer, an asset registry, and a UI root. Keep one time source, an explicit loop order, and init, start, pause, resume, and dispose semantics for every service.

Use glTF or GLB as the production runtime format, treating FBX, OBJ, and DCC files as sources. Choose Draco, Meshopt, or KTX2 compression deliberately, and validate assets with glTF validation, runtime loading, and clip and prefab node checks.

Prefer stable WebGL unless WebGPU or TSL provides a demonstrated benefit for your project. State compatibility and fallback boundaries explicitly, and only adopt custom shaders, TSL, or compute when there is a concrete need.

Use Octree, BVH, or a lightweight custom layer for mostly static worlds, and Rapier when you need rigid bodies, character controllers, scene queries, or snapshots. Keep render meshes, collision proxies, and gameplay rules separate behind a PhysicsAdapter.

Do not use it for static product viewers, marketing scenes, data visualization, or decorative 3D pages. It applies only when game-like runtime constraints exist, such as a persistent frame loop, gameplay state, player control, collision, saving, networking, or XR.

Separate persistent game state from transient, derived, and session state, and never serialize the three.js scene graph. Use a versioned save schema with migration hooks, IndexedDB for substantial saves, and localStorage only for small settings.