RollerCoaster Tycoon at 25: 'It's mind-blowing how it inspired me'

Aiming for EA by the end of the year :)

I plan on porting at some point during early access. The graphics engine already supports Mac, and the game is C++, so shouldn't be too difficult

And Linux/SteamOS? If it's Windows it could "just work" with Proton, but a native Linux build would be amazing

I plan on diving deep into economics at some point, but not immediately.

I have mixed feelings about that one. The building is much better than RCT (1-3, the ones that I've played) both coasters and buildings, however I don't like the art style at all and the terrain is mostly flat and much less interesting. Also the additional goods movement and service building hiding aspects that they added somewhat detract from the fun in my opinion. In the first RCT only the entrance (and possibly exit, I don't remember) had to be above ground, so with a bit of coaxing you could build rides that are underground except for a hole above the entrance, which was neat. Also, unlike RCT3, Parkitect doesn't let you move the camera to a path view (grid layout and isometric view are not really related), which is something I like to do.

One thing RCT does better than other sim games I've played is having a ton of customization options (Parkitect does this too). I like Timberborn also and wish it would have more customization possibilities like the RCT games. There are some limitations in the RCT games, like setting up a free monorail system doesn't cause anyone to use it to get to the next ride they are heading to, but in terms of decorations there is quite a bit you can do with it.

Nice, this seems very much like what I was talking about. I will keep an eye on it, thanks.

I played about 80h of that game and you bringing it up in this context is quiet strange. I mean is not even a city builder...? The whole stick is that it's rogue-like and each game lasts at most 30-40 minutes, which is antithetical to the game loop of building a city

You can hold down a key (Ctrl I think) to force snapping to the "world grid" now. That makes everything you place line up even halfway across the map.

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

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

> 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.

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.

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

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.

One of the biggest problems with AAA games is that they are trying to be Hollywood movies rather than games. Indie games are where its at unfortunately (or fortunately) there's so many of them being published now due to the readily available unity/gamemaker/ue5 that it's hard to find the good ones in the sea of bad ones.

> It's just impossible in an environment where nearly every major game is expected to be 3D, action-focused, and playable on console.

There are quite a few counter examples of this, even glossing over mobile, but what makes you think this?

There is a segment who want those 2D games.

While those are all great, I do not think they quite measure up to 1999.

2004 also brought Doom 3. It was significant for competing with Half-Life 2 for "best graphics" at the time. Even today, Doom 3 is still a visually stunning game.

2004 also had V:tM Bloodlines, as flawed as it was on release.

Yeah, but I only included ~Q4 of 1998, as I consider those games "morally" 1999 titles given the pressure to publish in time for Christmas. In any case, both 1998 and 2000 were very good years for PC gamers as well.

SCV good to go, sir!

Where did I get the time to play it all?