How Chris Sawyer programmed Transport Tycoon almost entirely in assembly

Transport Tycoon looks straightforward at first. You build a railway. Buy a train. Connect a town to an industry. Then, before long, you’ve got aircraft crossing the map, buses feeding stations, ships carrying cargo and trains stacking up behind signals you probably placed five minutes earlier. Underneath all of that sits one of the more unusual technical stories in PC gaming. Chris Sawyer wrote essentially the entire original Transport Tycoon in x86 assembly language. Not just a few fast graphics routines. Not one especially demanding part of the simulation. Almost the whole game. For something released on MS-DOS in 1994, that was a serious amount of low-level programming.

Building a simulation one instruction at a time

Assembly language works very close to the processor. You deal with registers, memory addresses, individual instructions and exactly how data moves around the machine. That gives you control. Lots of it.

It also means the computer doesn’t do much hand-holding. Higher-level languages let programmers describe fairly complicated behaviour without worrying about every tiny processor operation underneath. Assembly strips much of that away. If something needs to happen, the programmer has to describe it in far more detail. Now apply that to Transport Tycoon.

The game wasn’t just drawing trains on a map. It constantly tracked vehicles, cargo, stations, industries, towns, company finances, running costs and construction. Trains followed routes. Aircraft moved between airports. Factories produced goods. Towns grew. Vehicles aged. And all of those systems kept running together. That’s the part that makes Sawyer’s choice so striking.

Why assembly made sense in 1994

Using assembly for a project this large sounds extreme now, but the hardware situation was very different in the early 1990s. PC processors were slower. Memory was limited. Graphics hardware didn’t take care of nearly as much work as it does today. If a game wasted processor time, players noticed. So efficiency mattered constantly.

Assembly let Sawyer control how much work the CPU did and how memory was used. Tight loops could stay tight. Data structures could be kept compact. Routines could avoid unnecessary overhead. That mattered more as a Transport Tycoon map filled up.

A new game might contain a couple of vehicles and a small network. Later, the same save could have dozens of trains, road vehicles, aircraft and ships moving at once. Stations needed updates. Cargo had to be tracked. Industries had to keep producing. The economy couldn’t simply stop because the player wasn’t looking at that part of the map. The simulation had to keep moving.

It wasn’t just about making graphics fast

Assembly often gets associated with graphics performance, especially when people talk about DOS games. That was certainly part of the picture. Moving pixels around quickly mattered, and programmers regularly used low-level code for drawing routines.

But Transport Tycoon had a different kind of workload too. Think about a railway network with several junctions and signals. Each train has somewhere to go. Stations have cargo waiting. Industries are producing new cargo. Towns may be expanding. Vehicles are costing money every day they run.

Then the player builds another route. That new route becomes part of the same running system. Nothing else stops.

Transport Tycoon had to process thousands of small decisions and updates without making the whole game feel sluggish. That’s where Sawyer’s control over the hardware became useful. The code wasn’t simply trying to draw trains quickly. It was keeping an entire transport economy ticking.

Chris Sawyer worked differently from most developers

Sawyer didn’t approach assembly as something you drop into a project when C isn’t fast enough. For him, it was a normal working language. He already had years of experience with low-level programming before Transport Tycoon, including work on PC conversions and technically demanding software. By the time he started building the game, he knew exactly what assembly could give him.

That changed the way the project came together. Instead of designing everything in a higher-level language and then rewriting the slow parts, Sawyer could think about performance, memory and data organisation from the beginning. The structure of the program and the behaviour of the hardware were closely connected. That’s very different from the way most large games are built now.

A lot was happening behind that simple interface

Transport Tycoon doesn’t constantly advertise its technical complexity. That’s probably why this detail can be surprising. The interface is clear. The graphics are easy to read. You click on a station, buy a vehicle and send it somewhere. The technical machinery stays out of the way.

Behind that, though, the game is handling a large number of connected systems. A factory produces cargo. A station collects it. A train arrives. Money changes hands when the cargo reaches its destination. The company balance changes. A town grows. New construction creates different traffic patterns. None of that looks dramatic on its own. Put it all together and you have a simulation that can become extremely busy.

An unusual piece of MS-DOS engineering

Transport Tycoon arrived at a point when PC developers still had to think carefully about every bit of performance they could get. Sawyer took that requirement further than most. Writing essentially the entire game in x86 assembly gave him direct control over how the simulation used the processor and memory. It also meant building a complicated management game without many of the programming conveniences developers normally relied on, even at the time.

That’s what makes the technical side of Transport Tycoon stand out. The game itself became known for its transport networks, expanding towns and increasingly complicated rail systems. Behind all of that was code written at a level where individual CPU instructions mattered. For a management simulation released in 1994, that’s quite a foundation.