pn-gamedev-philosophy

Game Development Philosophy

Purpose

Use this as a game and real-time 3D design rulebook for:

• Game loops and state machines
• Three.js / WebGL / WebGPU scenes
• Real-time physics and animation
• Asset loading and disposal
• Performance-critical rendering
• Input handling and update order

It is engine-agnostic where possible and aligned with current industry practices.

When to use

• Designing game architecture or real-time loops
• Structuring Three.js/R3F scenes or WebGL projects
• Reviewing performance, disposal, or timestep logic
• Establishing gamedev standards for a team or AI agent
• Auditing frame budget, LOD, or memory management
• Building tools, prototypes, or shipped games

For workflow, audit checklist, and templates, see reference.md.

---

Core Philosophy (non-negotiables)

Fixed timestep for physics

Physics and deterministic logic use a fixed delta (e.g. 1/60s). Variable delta causes numerical drift, collision tunneling, and non-determinism across hardware. Accumulate elapsed time; step in fixed increments; cap accumulator to avoid spiral of death.

Frame budget is law

Target refresh rate defines the budget (60 FPS ≈ 16.7ms, 120 Hz ≈ 8.3ms per frame). Profile to identify CPU vs GPU bottlenecks. Leave 1–2ms safety margin for spikes. Optimize the dominant cost first.

Disposal before allocation

WebGL does not auto-free. Geometries, materials, textures, render targets must be disposed when no longer needed. Dispose before removing references. Monitor renderer.info.memory; avoid per-frame allocations in hot paths.

Update order is explicit

Define and document: input → physics → game logic → animation → render. Systems that depend on others run after. No hidden ordering; deterministic and testable.

Hierarchy carries intent

Group objects logically (environment, characters, UI, effects). Use consistent naming (e.g. env_ground, char_player). Hierarchy enables correct transforms, visibility toggles, and disposal.