Game Optimization

Game Optimization — 60fps is a feature, not an accident

A browser game that hits 60fps empty and drops to 20 when the action starts isn't optimized, it's lucky. And a game where movement is faster on a 144Hz monitor than a 60Hz one isn't just slow — it's wrong. Performance and correctness are the same problem here: both come from decoupling the simulation from the frame.

BANNED (the default AI-game performance failures)

• x += speed per frame. Framerate-dependent: double-speed at 120Hz, half under load, non-reproducible bugs. Everything moves by dt or on a fixed timestep.
• Physics tied to render rate. Simulating "once per drawn frame" makes physics jitter and behave differently on every machine. Fixed timestep, always.
• Allocating in the loop. new, [], {}, .map/.filter/.forEach closures, template strings for UI — every frame. Feeds the GC until it stalls mid-fight. Pool and reuse.
• One draw call per sprite. Switching texture/state per object murders throughput. Batch via a texture atlas.
• O(n²) everything. Collision, AI target-finding, nearest-neighbour by scanning all entities. Spatial-partition it.
• Rendering at full DPR on 4K/mobile. 3–4× the fill cost for no visible gain, then thermal throttling. Cap DPR.
• "Runs fine for me." Never profiled, never stress-tested, never run at 60Hz or on a phone.

The two root causes of almost every game perf problem

1. The loop is wrong → speed varies, physics jitters, one big frame teleports things. Fix: fixed-timestep accumulator + interpolated render. See [references/game-loop.md](references/game-loop.md).
2. The loop allocates → periodic GC hitches. Fix: object pools, zero steady-state garbage. See [references/pooling-and-gc.md](references/pooling-and-gc.md).

Fix these two and most "it stutters" complaints vanish. Everything else (batching, partitioning) is for scaling entity/draw counts higher.

Process

1. Get the loop right first — fixed timestep for simulation, delta/interpolation for render. [tools/game-loop.js](tools/game-loop.js), [references/game-loop.md](references/game-loop.md). This alone fixes speed-varies-by-monitor and most physics jitter. Non-negotiable foundation.
2. Pool everything that spawns — bullets, enemies, particles, damage numbers, vectors. [tools/object-pool.js](tools/object-pool.js), [references/pooling-and-gc.md](references/pooling-and-gc.md). Target: heap flat during play.
3. Cut draw calls — texture atlas + sprite batching; tilemap layers batch to 1–2 calls; instance repeated 3D meshes. [references/rendering-perf.md](references/rendering-perf.md).
4. Spatial-partition the O(n²) — grid/quadtree for collision and neighbour queries (shared with game-collision's broad-phase). [references/rendering-perf.md](references/rendering-perf.md).
5. Profile, don't guess — Chrome DevTools Performance, an fps/frame-time meter, draw-call count. Find the actual bottleneck before optimizing. [references/profiling.md](references/profiling.md).
6. Stress + reality test — 200+ entities, 60Hz and 144Hz, throttled tab, mid-tier phone. If it only holds 60fps empty on your desktop, it's not done.

The 16ms budget (60fps)

Each frame has ~16.6ms for everything — input, simulation, render, GC. Realistically keep game logic under ~8–10ms to leave room for the browser. When you blow the budget: profile → find the spike → is it allocation (pool it), draw calls (batch), or an O(n²) scan (partition)? Optimize that, re-measure. Never optimize by vibes.

Companion

Pairs with [browser-engine](../browser-engine/SKILL.md) (the constraints and loop context) and [game-collision](../game-collision/SKILL.md) (its broad-phase is the same spatial partition you use here). Optimization and correct collision share the same structures — build them together.

The 60fps checklist (before claiming done)

• [ ] Simulation on a fixed timestep; render interpolates — speed identical at 60Hz, 144Hz, throttled
• [ ] dt clamped so a background-tab return can't teleport or explode the sim
• [ ] Steady-state loop allocates nothing — heap is flat in DevTools during play
• [ ] Everything that spawns comes from a pool (bullets, particles, enemies, vectors)
• [ ] Draw calls minimized — atlas/batching in 2D, instancing for repeated 3D meshes
• [ ] O(n²) work replaced with a spatial partition
• [ ] DPR capped (~2); resize handled; logical resolution fixed
• [ ] Profiled: bottleneck identified and measured, not guessed; holds 60fps at realistic load on a mid device

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: StarchyBomb
• Source: StarchyBomb/browser-engine
• License: MIT

Install and usage instructions live in the source repository linked above.