The essence of it is in good application of macros. Macroassemblers were essential tools for software that wanted all three of complex, high-performance, and fast to build on hardware of that era. Although it's a bit intimidating to write a large program without a higher-level syntax backing it, it's possible to invent coding conventions and reuse strategies that get you to the desired level of flexibility and maintainability, but perhaps without as many built-in checks and a simpler strategy with respect to resource usage(a general-purpose "malloc" is not a thing you would want to do casually in an assembly program since it makes everything considerably harder to track - but simpler fixed-buffer or mark-and-release strategies were fair game).

And if you were a little more ambitious you could also write a custom code generator that added whatever additional features you needed - expansions, type checks, expression evaluators, simple optimizations. Code generation is actually far easier today since the scripting languages now are so much more powerful and feature-rich than what a typical early 90's setup would have(assembly, buggy proprietary C or Pascal compiler, Basic variants).

Of course there's nothing stopping you from taking a similar approach now and custom-generating some source instead of using templates or compile-time evaluation or other fancy features - it's just harder to communicate.

There are many large assembly projects.

https://en.wikipedia.org/wiki/Category:Software_written_prim...

Even today a minority prefers writing new projects in assembly.

https://news.ycombinator.com/item?id=15281522

Here you can have a look at Prince of Persia's source for the Apple II: https://github.com/jmechner/Prince-of-Persia-Apple-II

That is impressive, was RCT2 mainly just Sawyer too like TT? Makes you reconsider scale when you say Fred/John/Mary is a 10x'er because she/he got a small line of business CRUD app in some high level language with a battery included opinionated web framework shipped in less than month.

You'd be amazed at how productive you'd become if you're working mostly on your own, uninterrupted, and with a clear vision of what you're building. Look at how much you already churn out in the span of a year, then multiply that.

True, but I also think part of it's the Internet and much more opportunity to procrastination (i.e. now). When I was lad... we had slashdot.org, theregister and theonion, you'd be done within 20 mins. Now we have HN, SO, reddit, podcasts, blogs, twitter, etc.. When Sawyer started on TT I don't think 14.4 modems were even widespread.

How much of the game was actually in assembly? I always heard that it was mostly stuff like the guest AI that was in assembly (which is why you could have hundreds of them running at once), and the graphical stuff was in a higher-level language.

ALL of it. Even the DirectX stuff was hand-written assembly. It's the same core engine going back to the Transport Tycoon days.

There is actually no DirectX at all in RCT2 source code. The game has its own software renderer that outputs direct to the screen buffer.

My understanding is that it was all assembly because he was reusing a lot of code from earlier projects that were written for extremely limited machines.

It's still an impressive achievement. The latest SimCity can't simulate as many people as RCT before crapping itself, even on a machines a million times faster.

The latest SC is kind of a tech experiment in how it works with per-Sim management. Older SimCity iterations are fine on new machines.

Blows my mind. What sorts of optimizations can you do in assembly better than a good C compiler could?

I'm wondering what % performance improvement he saw from doing it this way.

I started working on games in the early 90s and was one of the first to use C instead of asm because my game was targeting Amiga and PC and didn’t involve significant cpu intensive graphics etc. However the rest of the company was working on Super Nintendo, Megadrive etc and these were exclusively asm. C compilers back then actually did add significant overhead to code and you could do much better by hand, especially since cpus in consoles often lacked features such as floating point units or had cut down memory management units. In addition they had custom hardware that you could use (blitter for example on Amiga, gte on PlayStation) that was easy enough to use from asm and the compiler couldn’t help you.

The main advantage that Chris used in RCT2 to optimise his code was that he could vary his calling convention however he felt. Most of the time all variables were passed in registers instead of the stack. This can make for some impressive speed ups.