The choice that looks insane
Writing a commercial game in assembly in the late 1990s reads today as an eccentricity — the programming equivalent of building a house with hand tools. High-level languages existed and were mature, C and C++ were the industry standard, and compilers were good. Sawyer wrote 99 percent of RollerCoaster Tycoon in x86 assembly for the Microsoft Macro Assembler, leaving roughly one percent in C, and he did it for a reason that had nothing to do with preference.
The reason was that the game he wanted did not fit. Sawyer has explained that he struggled to keep performance reasonable on PCs of the era even using highly optimised machine code, and that a high-level language would have made the game far too slow or forced him to simplify the simulation. That is a specific technical claim, not a boast. RollerCoaster Tycoon tracks every guest in the park as an individual with their own state, preferences, nausea, and pathfinding, and doing that for thousands of guests on a 1999 consumer PC sat at the edge of what the hardware could do. The language was not a stylistic choice. It was the difference between the game existing and not existing.
What the simulation bought
The payoff is visible in what the game lets you notice. Guests in RollerCoaster Tycoon are not crowd texture. Each one has a name, a wallet, an opinion about your park, and a set of internal states that respond to what you build. A guest gets thirsty, walks to a drink stall, finds it too expensive, gets annoyed, and eventually drops litter on a path — and you can click on them and read all of it. Players spent enormous amounts of time doing exactly that, following individuals around, and the game's reputation rests substantially on that granularity.
None of it works at half the frame rate. The whole design depends on simulating thousands of independent agents fast enough that the park feels alive rather than sluggish, which puts the performance budget directly upstream of the creative concept. Sawyer's assembly is therefore not separable from what the game is: he chose a punishing implementation because the punishing implementation was what allowed the idea. Most developers make the opposite trade without noticing, scaling the ambition down to fit the tools.
Almost alone
The staffing is as striking as the language. Sawyer built RollerCoaster Tycoon essentially by himself, using only freelance graphic artist Simon Foster and composer Allister Brimble — a three-person credit list, one of whom wrote the entire game, on a title that became one of the best-selling PC games of its era. He arrived there sideways, too. He was working on the engine for a Transport Tycoon sequel, developed an interest in roller coasters and their design, and took a break from Transport Tycoon 2 to explore the idea.
The royalties came to roughly $30 million. It is worth sitting with that number in the context of what produced it: one programmer, an interest in roller coasters, a side project taken up as a break from the real work, and a language nobody else was using for games. The modern industry's structure makes this combination close to impossible to repeat — not because the talent does not exist, but because nothing about a large production pipeline permits a single person to hold an entire game in their head. Sawyer could write RollerCoaster Tycoon in assembly because he was the only one who ever had to read it.
The code as artefact
RollerCoaster Tycoon has become a standing reference in arguments about programming productivity, usually deployed as evidence that individual capability varies by more than the profession likes to admit. The example is genuinely striking, but the lesson most often drawn from it is the wrong one. Sawyer did not succeed because assembly is good. Assembly is a terrible way to build most software: unmaintainable by teams, hostile to change, and punishing to debug.
He succeeded because he correctly identified a case where the constraint was real. The simulation was performance-bound, the performance ceiling determined the design, and he had the specific skill to move that ceiling. That is a diagnosis, not a preference, and the reason the game remains remarkable is that the diagnosis was right — the finished product does something the hardware of 1999 should not have permitted. The eventual open-source reimplementations, built by fans painstakingly decompiling his work, are their own kind of tribute: it took a community years to unpick what one person wrote alone.