[affgrff2]

According to Wikipedia, the code of the game is written 99% in assembly, too bad the article doesn't mention that. Maybe they decided that is not a valuable information for their readership but I guess, here, lots of people will be as impressed by that.

[jl6]

I believe Chris Sawyer was also responsible for the PC port of Frontier Elite II (from the Amiga original by David Braben), and he put an advert in some of the spaceports, along the lines of “Coming soon: Chris Sawyer’s Transport Game”.

One assumes he was an expert in 68k and x86 assembly.

What a legend!

[xboxnolifes]

That fact comes up in every single rollercoaster tycoon discussion, so maybe they just assumed most knew about it. It also doesn't seem relevant to the point of the article.

[robertlagrant]

I doubt The Guardian's general readership would know what assembly is. That's all.

[baliex]

This always completely blows my mind. I just can’t fathom how he was able to do that. Brilliant game.

[orthoxerox]

He used a relatively high level macroassembler. It's not HLA, but it could do things like dereference struct fields and reference various (global?) variables. See here, for example: https://lifeandtimes.games/episodes/files/28

[whartung]

> I just can’t fathom how he was able to do that.

Honestly, it's not that hard. Not for a decent assembler.

The "hard parts" of assembly are things like trying to do multi-precision stuff on smaller precision machines (like 16- 32- bit math on an 8-bit processor). Just coming up with the tiny algorithms we all take for granted. Of course, today, you don't have to invent those.

Folks think that written in assembly is all bit twiddling and high, dense data structures. But that's not necessarily true.

On a modern x86, it's not that much different from normal C in terms of data sizes and data structures. 16- and 32-bit registers. Add/Sub/Mult/Divide instructions. Block move instructions. Modern assemblers handle structured data. Stupid assemblers handle offsets readily. Assemblers handle local and private symbols, exporting routines, code modularity. You don't have to worry about addresses and what not, linkers do all of that. Symbolic debuggers like anything else. Not like they have to burn a PROM and shove it into a board every dev cycle.

But, most important, once you've got started, once you have the common elements of programming (parameter passing, looping, math, structures, pointer dereferencing), I mean, that's it, right? Rinse and repeat. That's what higher level languages give you "for free". Not every line is hand crafted, hand optimized, etc. Much of it can be stomped out with macros for anything that takes more than a few instructions. Tada -- you now have a higher level language (for small values of "higher").

If anything it's just more tedious. Less code density (assuming little macro use) per screen, etc. But even then, once you have your momentum, once you have your routine patterns, they just fall out of the code as you read it.

I remember my assembly class in college (I was not a good college student). I stopped going to class because the teacher kept asking me system questions. She gave me an incomplete, and I had to do all the projects again next term (that was, honestly, quite nice of her -- she could have just failed me).

So, I did those projects. Those simple Assembly class projects. Trivial little programs "Convert decimal to binary" type stuff.

What I did was I wrote a large macro library, inspired by Forth. I basically ported a rough Forth vocabulary to assembler macros. That "convert decimal to binary" project?

    ; Convert 10 to Binary and print it
    PUSH 10; PUSH 2; PUSH BASE; STORE; PUSH BUFFER; NUMBER; PUSH BUFFER; PRINT

So I turned in my projects, each one was like that -- 10, 20 "instructions". I said "Here's my projects", handing 10, small, 2-3 page printouts, "but you'll need this to understand them" and I gave her a 3/4" thick printout of the macro library.

Yea, I was kind of a jerk. Just where my head was at.

Figured I'd get an F or and A. She gave me an A. (I mean, if nothing else, I did demonstrate a solid understanding of assembly language programming!)

But the underlying point is that it's just patterns, patterns we get used to using and writing. It can be inscrutable to the uninitiated, but the curve, particularly on modern processors, is not that steep. Like I said, you're not just shifting and adding to multiply anymore like the old days. And staring at a disassembly of raw code is not the same thing as writing assembly language with modern assemblers.

[remram]

Obligatory reminder that wikipedia is NOT (trying to be) a source. This particular fact comes from Chris Sawyer's own website, that has some more interesting details as well: https://www.chrissawyergames.com/faq3.htm

You can easily find sources from Wikipedia by following the numbers in brackets (here "[3]").

[frozenport]

They didn't gain anything by doing this.

[gambiting]

Having worked with people who wrote games like the original Driver - large chunks of code used to be re-written by hand in assembly for performance late in development, or the game just didn't run fast enough. 90s compilers just weren't that good. I think in 2024 if you think you can do better than the compiler you're mostly fooling yourself, but 25 years ago that wasn't the case.

[leokennis]

The game ran on my Pentium 166 with 32 MB of RAM. That was enough for me.

[willismichael]

Chris Sawyer knew how to crank out assembly code. He'd been doing it for several games, so maybe it really was the best way for him to develop this rather than futz about with C++ or whatever.