RollerCoaster Tycoon 2 (2002) was built by one person. Chris Sawyer designed and programmed the whole thing solo, with art from Simon Foster and music from Allister Brimble. Thousands of AI guests, full ride physics, a park economy, all running in real time.

And according to Sawyer’s own site, 99% of it was written in x86 assembly language.

That fact tends to produce disbelief. The real story is more pragmatic than it sounds.

What Even Is Assembly?

Assembly maps almost directly to the instructions a CPU actually executes. No garbage collector, no runtime, no abstraction layer. You work with registers and memory addresses directly. The processor does exactly what you tell it.

That directness is the point. The tradeoff is that it’s extremely verbose. A simple loop takes many more lines than the equivalent in C. But verbosity, on its own, is a solvable problem.

The Macro-Assembler Trick

Assembly was used in commercial game dev far longer than people assume. Through the late 80s and well into the 90s it was common, often mixed with C or other languages. The demoscene group Future Crew built their famous 1993 demo Second Reality in a blend of assembly, C, and Pascal. The source is on GitHub if you’re curious.

The trick to managing assembly at scale is tooling. You don’t write a full new language, you build a layer on top: a macro processor, some syntax shortcuts, some checks. Your macros handle the boilerplate. You think at a higher level, but the output is still raw, tight machine code. Games in the 80s were routinely ported between platforms this way, by automating the assembler translation and swapping out the platform-specific I/O calls.

How Sawyer Got There

Sawyer didn’t decide to write a full game in assembly from scratch. He arrived at it gradually.

His PC background was in porting nine Amiga games to MS-DOS through the late 80s and early 90s. That work means understanding exactly what each machine does with each instruction, and building tools to bridge the gap. Libraries accumulate. Patterns that work get reused. From there he built Transport Tycoon, then RollerCoaster Tycoon, then RCT2. Each project extended the last.

PCGamesN describes it well: Sawyer had two PCs on his desk, one fast machine for coding and one slower one for testing, a pocket guide to x86, and a 500-page desktop reference. He was working alone, which meant he didn’t need to worry about whether anyone else could read or maintain his code. The calculus that pushes teams toward portable, standardised languages simply didn’t apply to him.

Why Not Just Use C?

The compilers of the late 90s weren’t the optimizing monsters of today. Sawyer addressed this directly in an interview:

I was struggling to keep performance at a reasonable level on PCs of the era even using highly optimised machine code, and writing in a high level language would have made the game far too slow.

The performance stakes were real. With thousands of guests being simulated simultaneously, even tiny per-object inefficiency multiplied out and tanked the frame rate. And on a personal level, he could write machine code faster and more reliably than C. When you’re working solo, the language you’re most fluent in is often the right call.

The Portability Question

x86 assembly is processor-specific, so how did the game run on so many machines?

Simple: x86 is backward compatible. Code written for an older x86 CPU runs on newer ones. Sawyer was targeting one ecosystem, and it held. The problem only appeared later, when RollerCoaster Tycoon Classic needed to run on ARM-based mobile hardware. The assembly couldn’t be translated. The whole game had to be rewritten in C++ from scratch, and as Sawyer noted, it took a small team several years, longer than the original had taken him.

What RCT2 Actually Added

RCT2 extended the first game’s engine rather than rebuilding it. The headline additions were a full Scenario Editor, improved building tools with per-height object placement, more ride types, user-created scenery, and five licensed Six Flags parks. It shipped in October 2002 via Infogrames, with two expansion packs following in 2003.

Critics noted the engine looked dated and that a 3D shift was overdue. GameSpot gave it 7/10, IGN gave it 8/10. It sold well regardless, landing into a series that had already cleared 6 million units before RCT2 arrived.

The community has kept it alive ever since through OpenRCT2, an open-source engine recreation with modern resolutions, multiplayer, and bug fixes, all built by reverse-engineering that tight assembly codebase.

TLDR

RollerCoaster Tycoon 2 was 99% x86 assembly, written by one person. This wasn’t stubbornness. Late-90s compilers couldn’t match hand-optimized assembly for a simulation running thousands of objects per frame on modest hardware. Sawyer had also spent years building up personal tooling, libraries, and macro-assembler infrastructure, so switching to C offered no obvious payoff.

The long-term cost came when porting to mobile: x86 assembly doesn’t run on ARM, so the whole game had to be rewritten in C++, a process that took longer than the original development.

The lesson isn’t “use assembly.” It’s that the right tool depends on what you already know, what you’ve already built, and what constraints you’re actually working under.