I’m wondering if the Inform games I chose were representative or not.
If they were all older games, they were not representative by definition!
Okay, there’s several things going on here.
Infocom games:
Remember that through the v5 era, Infocom was still targetting 8-bit machines. A stock Apple 2e had 64k of (real) RAM. Infocom’s interpreter had to divide that between interpreter code, Z-machine RAM (kept in hardware RAM), and Z-machine ROM (swapped from floppy). That meant a tight practical RAM limit for their games. Practical ROM limit too, given that a floppy was 140k. I don’t remember these limits were but they definitely kept track of them for all their target platforms.
For the v6 games (Zork Zero, Journey, Arthur, Shogun), I believe they only targetted 16-bit machines like the Amiga and Apple 2gs. That changed the playing field, but I haven’t dug into how.
Inform:
Inform started with the idea of replicating Infocom’s capabilities, so it took the original limitations as an assumption.
By the time people were using Inform 5 and 6, that was no longer true. Most authors’ practical target was z5 running on a modern machine (32-bit addressing, hundreds of megabytes of RAM). So there was no reason not to use 64k of RAM.
However, Inform was still pretty good at optimizing RAM use. The “normal” design patterns of Inform 6 – the kind of programming taught in the DM4 – did not eat gobs of RAM. You added objects one at a time. An object had some RAM cost (properties, attributes, dict words) and some ROM cost (game text and code), but the ROM cost was usually much higher. So most games ran into the 256k z5 ROM limit before the 64k RAM limit. Graham added z8 to address that, but it turned out that you still had to be making a frickin’ huge game to worry about RAM.
Now, I said “normal” design patterns. There were of course plenty of ways to use gobs of RAM if you wanted to. (They all started with “define some gigantic arrays.”)
I7 began to adopt some of those patterns into common use. Many-to-many relations required a lot of RAM. Dynamic strings and lists required a RAM heap, which was (under the hood) a gigantic array.
Up through Inform 7 6G60, these features were considered “extra”. The compiler went to some effort to not build them into a game unless the author explicitly invoked them. If you did, your RAM usage probably approached 64k.
However, the fact was that if you wanted to do stuff like this, 64k wasn’t good enough. The exact amount of RAM needed for dynamic memory features was, well, dynamic. The compiler made an estimate based on how much stuff your game contained. These estimates were generous. You didn’t have to be writing a very large game before Inform said “Uh, it’s getting to be time for Glulx.”
So, starting with 6L02, the Z-machine just wasn’t the primary development target. Inform normalized the used of dynamic memory features. (“Indexed text” became just “text”, for example.) You could still target the Z-machine but it was easier to switch to Glulx than to try to scrape out every byte of Z-machine RAM.
TDLR: There has never been a time when the 64k RAM limit was the critical bar-to-duck-under for the majority of IF authors. Either the critical limit was lower, or ROM was more important, or it was easier to dodge the whole shebang by leaving the Z-machine behind.