5 ms·

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 inf

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.

baliex 2y ago
This always completely blows my mind. I just can’t fathom how he was able to do that. Brilliant game.
- orthoxerox 2y ago
  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 https://lifeandtimes.games/episodes/files/28
- whartung 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - ylee 2y ago
    >What I did was I wrote a large macro library, inspired by Forth. In an elementary-school BASIC class, I completed an assignment using `READ`/`DATA` when it was not necessary to do so. For a later assignment involving writing a quiz game, I resubmitted the same code with the `DATA` lines appropriately modified!
frozenport 2y ago
They didn't gain anything by doing this.
- willismichael 2y ago
  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.
  - frozenport 2y ago
    From reading the OpenRCT2 code base it was C-style with PUSHA features. You basically need to create a bunch of wrappers over function calls, to construct a sort of domain specific language/macro collection for your specific application. I can respect the dude but in many ways RCT was a continuation of his previous games. As people who study software development we have to sometimes call it like it is. Using ASM was not the right choice as it didn't provide any obvious advantages compared to languages like C. The genius of OpenRCT2 wasn't in the language choice but rather in the immersive world available in your cereal box.
    - aeyes 2y ago
      > Using ASM was not the right choice It was the right choice for the developer because he had years of experience developing other games, he probably had a structure and a good enough library by the time he started working on RCT.
    - willismichael 2y ago
      Where's your series of simulation games?
    - npteljes 2y ago
      There is no right language choice for a game, same how there's no right choice to live a life. There are advantages and disadvantages, and in retrospect, we can see how things turn out. There are language choices in projects where the choice seems to hurt the project, that's for sure. Wrt/ RCT, I don't see a single downside though. The cases I'm thinking about are Minecraft, for example, with its horribly performing Java code. Cities Skylines with their engine choice and usage, resulting in 30-40 fps even on high end hardware. Project Zomboid with LUA - many performance problems, and artificial limitations to keep performance to a reasonable limit. Also consider that often, a project either gets off the ground with the sub-optimal choices, or it doesn't, at all. And as we see from the results, a sub-optimal, but fun game is better than an optimal, but non-existing game. At least if you consider fun and success desirable.
jl6 2y ago
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 2y ago
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 2y ago
  I doubt The Guardian's general readership would know what assembly is. That's all.
remram 2y ago
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 https://www.chrissawyergames.com/faq3.htm You can easily find sources from Wikipedia by following the numbers in brackets (here "[3]").

baliex 2y ago

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

orthoxerox 2y ago
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 https://lifeandtimes.games/episodes/files/28
whartung 2y ago
> 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.
- deleted 2y ago
  [deleted]
- ylee 2y ago
  >What I did was I wrote a large macro library, inspired by Forth. In an elementary-school BASIC class, I completed an assignment using `READ`/`DATA` when it was not necessary to do so. For a later assignment involving writing a quiz game, I resubmitted the same code with the `DATA` lines appropriately modified!

frozenport 2y ago

They didn't gain anything by doing this.

willismichael 2y ago
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.
- frozenport 2y ago
  From reading the OpenRCT2 code base it was C-style with PUSHA features. You basically need to create a bunch of wrappers over function calls, to construct a sort of domain specific language/macro collection for your specific application. I can respect the dude but in many ways RCT was a continuation of his previous games. As people who study software development we have to sometimes call it like it is. Using ASM was not the right choice as it didn't provide any obvious advantages compared to languages like C. The genius of OpenRCT2 wasn't in the language choice but rather in the immersive world available in your cereal box.
  - aeyes 2y ago
    > Using ASM was not the right choice It was the right choice for the developer because he had years of experience developing other games, he probably had a structure and a good enough library by the time he started working on RCT.
  - willismichael 2y ago
    Where's your series of simulation games?
  - npteljes 2y ago
    There is no right language choice for a game, same how there's no right choice to live a life. There are advantages and disadvantages, and in retrospect, we can see how things turn out. There are language choices in projects where the choice seems to hurt the project, that's for sure. Wrt/ RCT, I don't see a single downside though. The cases I'm thinking about are Minecraft, for example, with its horribly performing Java code. Cities Skylines with their engine choice and usage, resulting in 30-40 fps even on high end hardware. Project Zomboid with LUA - many performance problems, and artificial limitations to keep performance to a reasonable limit. Also consider that often, a project either gets off the ground with the sub-optimal choices, or it doesn't, at all. And as we see from the results, a sub-optimal, but fun game is better than an optimal, but non-existing game. At least if you consider fun and success desirable.

jl6 2y ago

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 2y ago

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 2y ago
I doubt The Guardian's general readership would know what assembly is. That's all.

remram 2y ago

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 https://www.chrissawyergames.com/faq3.htm You can easily find sources from Wikipedia by following the numbers in brackets (here "[3]").