The most amazing thing about RCT1 & 2 is that they were written entirely in x86 assembly language. For those who do not know, assembly language is a very low level language within a computer, it is not really human readable, making it very difficult to work with. You have to literally move bits around the CPU and memory to and from registers etc, goes without saying you have to have an extremely good understanding of how the fundamentals of computers work. Even now in 2024 it is an amazing achievement, almost nothing is written in this low level language for a reason, with how difficult it is to use.
The trade off being though is that you get great performance, something the original RCT games did extremely well, 1000's of peeps, huge parks, all running well on what were Pentium 1 and lower machines with no dedicated graphics. You could get away with it now on a much higher level language like C++, or going even higher something like C# or Java, but back then, the only choice you had to make a game like this possible and for it to perform well was by using assembly, one of the lowest levels of code that runs in any computer / phone, to this day. I think one level below assembly in any computer / phone is the physical binary that the machine itself speaks in. The graphics were sprite based and not 3D but made to look 3D and ran completely within the CPU in fact, no GPU of any type needed, to be fair, something that was common around that time period for games, as it was just on the cusp of when proper 3D accelerated graphics took off.
Think of it like layers I guess, the 'lower' level the language, the closer it is to the physical processors, the faster it runs, but the more work you need to do as a programmer to achieve a given task, alongside it being harder to read / write. The higher up you go, the easier the code is to work with, more easier to achieve given tasks with less code, but you trade off speed. As the computer is having to also do more conversion in the background to make the code work, as there is a bigger gap between what you are reading and writing as 'code' and the binary, 1's and 0's, compared to assembly where the gap between what you read and write as 'code' and the 1's and 0's being much smaller, but much harder to read, write and work with. The speed issue is not so much an issue these days due to how blazingly fast computers are, but still a massive consideration depending on what type of software you are writing.
You wouldn't write an operating system's kernel or a server side memory manager in JAVA or C# for example, even today, as the code cannot execute fast enough to make the software work as it should, even on a multi billion, yes billion cycles per second and relatively 'slow' multicore phone processor. You need to go into a 'lower' level language, maybe not as low as assembly, but lower than the high level JAVA or C#...…..anyway that's enough about computer science, a topic I could talk about all day.
No one writes games in assembly, but Chris Sawyer did, he has to hit the hall of fame for that reason alone. Achieving a game on a technical level that was not possible, on the hardware of the day without writing in assembly language. Google Chris Sawyer Games and take a look at his original 20 year old website, the site has some cool information on regarding the games. I cannot link from this computer.