Programming in assembly isn't really "hard" it mostly takes lots of discipline. Consistency and patterns are key. The language also provides very little implicit documentation, so always document which arguments are passed how and where, what registers are caller and callee saved. Of course it is also very tedious.
Now writing very optimized assembly is very hard. Because you need to break your consistency and conventions to squeeze out all the possible performance. The larger "kernel" you optimize the more pattern breaking code you need to keep in your head at a time.
This makes sense and it's really that last step. It's one thing to do pattern matching or bit flipping routines. It's a whole different ballgame to build a game engine. Maybe if I knew gamedev better I wouldn't be as intimidated by it, but it really does seem like a herculean task.
I think it'd be cool to do assembler on a Pi Pico or something, that seems like it would be a fun exercise.
>I didn't know there was a fork and I'm excited to look into it
OpenRCT2 isn't a fork, it's like OpenTTD, a recreation.
Go look at GDC's Classic Game Postmortems. They have tens of videos of the people who built famous games from the 80s and 90s who often go into technical details of how they do it. For example, Robotron goes into how the code works.
It's remarkably familiar. They basically built object oriented programming and classes using convention only. You treat every actor you want to work with as a chunk of memory with standard layout that includes pointers for behavior and slots for state, and you just try really hard to only operate on the right "Types" at the right places. From there you have your standard game loop of "Get input, update all Actors, render, loop"
The Pitfall postmortem is wonderful. The Atari 2600 had roughly zero RAM to work with, and barely any cartridge space to hold your game. To make their large, somewhat open world, they made each screen built off just a few parameters, and created a bidirectional psuedorandomish function that would generate the parameters on a cycle, giving you a connected map space!
Yup. I've done a bit of assembly and it's really only a little harder than doing C. You simply have to get familiar with your assembler and the offered macros. Heck, I might even say that it's simpler than basic.
Back then a lot of people started with assembly because that was the only way to make games quick enough. Throughout the years they accumulated tons of experience and routines and tools.
Not saying that it was not a huge feat, but it’s definitely a lot harder to start from scratch nowadays, even for the same platform.
One thing I really don't understand would be the ergonomics of game dev. I mean, I guess it's just an isometric drawing library, and routines for each object (though this obviously isn't OOP game Dev). But like, for example, he talks about simulating the physics of the roller coasters. I get that, and I think I could figure that out in assembly. But, in my head, connecting the dots from simulating the physics to drawing it on the screen is a huge leap. But yeah, having years of background on using assembler for game Dev would obviously be a big part of that equation.
IIRC back then drawing on screen is simply writing into some memory mapped regions. But maybe it is more than that when the game was written, as it was in mid 90s.
I happened to glance over Linux device driver 3e yesterday, and just programming GPIO is ghastly complicated — the programmer needs to request a region, use specific memory in/out functions to write/read, and then release the region, all for just reading and writing some bytes — no real business about.
Not saying that was not a significant feat, but I think it’s almost impossible for anyone to do so nowadays — even with C it is a very good amount of knowledge to write an engine without libraries.
The more I actually started digging into assembly, the more this task seems monumental and impossible.
I didn't know there was a fork and I'm excited to look into it