RollerCoaster Tycoon: 99% Assembly, Zero Excuses

Chris Sawyer wrote RollerCoaster Tycoon almost entirely in x86 assembly language. Not as a stunt — as a deliberate engineering decision that produced one of the most commercially successful simulation games of the late '90s, running smoothly on hardware that modern developers would consider a rounding error.

A new deep-dive from Lars Tofus examines exactly what made Sawyer's approach work, and why it still holds up as a masterclass in constrained optimization — the kind most of us claim to care about but rarely practice.

The facts bear repeating: RollerCoaster Tycoon shipped in 1999, simulating thousands of individual guests with distinct AI behaviors, rendering an isometric 3D world with real-time physics for dozens of coasters, all on a Pentium 133 MHz with 16 MB of RAM. The entire game was written by one person over roughly two years, with only the audio and video components handled in C. Everything else — the rendering pipeline, the simulation engine, the pathfinding, the UI — was hand-rolled assembly.

What makes this more than nostalgia bait is the specific technique catalog. Sawyer's sprite rendering used pre-clipped draw routines that eliminated per-pixel boundary checks. The guest simulation batched AI updates across frames rather than ticking every agent every cycle — a technique that modern ECS architectures rediscovered decades later. Memory was managed with fixed-size pools, avoiding allocation overhead entirely during gameplay. The isometric renderer exploited the fixed camera angle to pre-sort draw order at map-build time, turning what would normally be a per-frame O(n log n) sort into an O(1) lookup.

The implicit argument is uncomfortable for 2026: we've mass-adopted languages, frameworks, and abstractions that trade 100x-1000x performance overhead for developer productivity — and then solve the resulting performance problems with hardware. Sawyer's approach was the inverse. Maximize what the hardware can do, accept the developer productivity cost.

Neither extreme is the right answer for most teams. But the article lands at a moment when the industry is shipping Electron apps that consume 500 MB of RAM to display a chat window, and when 'performance engineering' increasingly means 'throw it behind a CDN and hope.' Sawyer's work is a reminder that understanding what the machine actually does — not what your abstraction pretends it does — is a skill, not a phase the industry graduated from.

The piece is worth reading in full for the rendering diagrams alone. But the real takeaway is simpler: constraints aren't limitations. They're design parameters. The best optimization isn't making slow code faster — it's writing code that was never slow in the first place.