Problem statements I care about — the kind game engines and systems teams live in. Each one is a real problem I understand, the approach I'd take, and the trade-offs that decide whether it works. This is where I think in the open. Pick one to read the full write-up.
The measured follow-up to the cache note below. I built both layouts, held the work identical down to a checksum, and let the numbers settle the argument — 10.4× faster at a million entities, from nothing but where the bytes sit. With a live browser demo.
The intuitive way to model game entities — one object each, behind a pointer — is the way that starves the CPU. How I'm reshaping the update loop so memory access becomes something the hardware can predict.
At 60fps you get 16.6ms a frame, and one heap allocation in the game loop can eat it. Why frame pacing is a worst-case problem, and how an arena removes the risk entirely.
Satellite imagery arrives as terabytes of enormous scenes. How I make that queryable region-by-region — filter before you compute, and never trust a scene you didn't check.
Fixed-point math and a lockstep update so identical inputs always produce an identical frame — the groundwork every replay system and, eventually, every piece of netcode is built on.
Where the bytes actually go, and what really moves the number: aggressive size optimisation, dead-code elimination, and stripping the engine to only what the game calls.