I knew that the Gameboys were Zilog machines, but I never really put any thought into game development. I imagined they used a higher level language during actual development and ran the code through something that would result in the assembly for use in whatever. Pretty cool stuff.
General purpose high level languages[1] didn't become practical in commercial game development[2] for even what we would consider to be "non-critical" code until Doom, the PlayStation era for consoles, and the Game Boy Advance era for handhelds. Pretty much everything produced for the systems before them was done completely in assembly, and the practice remained relatively common for a while afterward.
This is partially because C compilers of the time weren't that great, partially because "everything is a critical section" when you're pushing the limits of extremely limited hardware, and partially because C's virtual machine model does not fit the average 8-bit CPU architecture at all, making pretty much impossible to this day to compile regular C code to (say) 6502 machine code that is anywhere close to optimal.[3]
[1] Ok, many games had custom bytecode interpreters, like SCUMM or the typical RPG's textbox language, but that's not quite the same thing. They could have used FORTH more (were there any games that used FORTH?), but I guess even in the days of HP calculators, people hated RPN.
[2] I guess I'm ignoring the many games done in BASIC for the 8-bit micros, but there's a clear difference in quality between these games and the average NES action game.
[3] There is a C compiler for various 8-bit architectures called cc65, but it chokes on anything resembling modern C. To get anywhere close to the performance of even naively written assembly, you have to hold its hand with machine-specific annotations (like "stick this variable in the zero page," or "make every variable static because the machine has no stack-relative address modes") to the point that it's easier to just write in assembly from the start.
Actually Pokémon Crystal itself, the rom we were discussing, has an extensive higher-level scripting language built-in for events, messages and movement. It still looks very much like assembly, but it is built up of Pokémon commands instead of machine code.
Not truly zilog z80. The GB processor lack the IX/IY registers and associated addressing modes of the z80 and it added a few instructions. It's closer to the i8080. The GB did use the z80 assembler syntax (thankfully!).
Some people still do z80 development. The community around TI graphing calculators has lots of people still doing wild stuff in z80 assembly. It's a fun platform.
