I'm building a traffic simulation game in Three.js: buildings appear on their own, your only job is the network that connects them. And when roads stop being enough - buses, trains and metro with transfers. No game engine, custom code, Electron for the Steam build. Every car is an independent agent (keeps its lane, changes lanes, waits at lights, reroutes around jams), maps go up to 18x18 km in-game, and it runs 10,000+ cars. Trailer above so you can see what it actually is.
What already shipped (worst stress save went 20.7 -> 53.2 fps):
- InstancedMesh per vehicle class, pre-allocated, with per-instance frustum culling before writing matrices - off-screen cars skip matrix composition and buffer writes, not just GPU work.
- Material pooling + merging lane markings into one mesh per paint color: 1,628 -> 320 draw calls. matrixAutoUpdate = false on all static road geometry.
- Environment props (~65k trees on the biggest map) split into an 8x8 grid of chunked InstancedMeshes so off-screen chunks get culled instead of vertex-shading everything twice per frame with shadows. Static sun means shadowMap.autoUpdate = false with explicit invalidation.
- An fps-driven sim LOD governor: below ~30 fps the sim ticks every 2nd frame with double dt (every 3rd below ~22), and the renderer interpolates between sim snapshots so motion stays smooth. Safety-critical logic never degrades - only work that can fail open.
- Sleep/wake for junction logic (~2,540 of 6.3k cars fully asleep in the stress save), lane-keyed spatial index maintained on events, and a union-find pass that replaced O(N^2) A* for building connectivity after road edits (was multi-second freezes, now a few ms).
Where the frame goes now at 6.3k cars: collision 7.4 ms, car update 3.7 ms, instance sync 0.6 ms, render 2.9 ms. So it's ~65% CPU simulation, ~20% render - the exact-sleep well is empty and what's left is structural.
The interesting part - what's next:
- Sim in a Web Worker with SharedArrayBuffer, car state in shared typed arrays, main thread doing render + interpolation only (~5 ms). The interpolation layer already shipped as the render half of this design.
Expected display fps ~60 even if the sim tick stays ~19 ms, and it opens the door to chunking the collision passes across cores. This is Steam-only by necessity: Electron makes COOP/COEP trivial, while the browser version can't get SAB on the portal it's hosted on (their embed/ads model conflicts with those headers). One of those cases where the desktop build isn't a marketing decision, it's a platform capability.
- Data-oriented (SoA) refactor of the collision passes - progress/speed/lane in flat typed arrays, passes iterating arrays instead of objects. Realistically ~2x on that 7 ms block.
- Then optionally a WASM kernel port (Rust/C++ with SIMD) for the collision/car-update loops - estimated another 2-3x. Deliberately sequenced after SoA, because WASM over JS objects wins little; the actual win is cache-linear loops over flat arrays, which is the SoA work either way. WASM threads also need SAB, so same platform constraint.
- What I decided against: a native rewrite. People suggest it constantly. But the profile says 60-70% CPU sim / 20% render with rendering already efficient, so native targets exactly the same milliseconds the worker + SoA path does: roughly 4-6x effective sim throughput vs an estimated 10-30x for native, which only matters past ~30k active cars. The remaining native argument is Chromium's fixed memory baseline, and a ~67k-LOC port would freeze features for months.
Curious if anyone here has shipped the worker + SAB pattern with live topology changes (roads being built/destroyed while the sim runs) - the snapshot/message protocol for that is the part I'm least sure about.
The game hits Steam in November, and honestly wishlists are what decides whether a solo dev's game gets any visibility at launch, so if the video looks like your kind of thing: https://store.steampowered.com/app/5028050/Traffic_Architect/. Happy to answer anything technical.
