With the popularity of large language models/A.I. I was thinking how we approached language based parsers in IF. A few months ago I stumbled on a coding situation where I needed a “Turing Machine” to process some data. And I’ve been reading “Crafting Compilers” book.
These all got me wondering. What about the Z-Machine that makes its machine code uniquely suited to interactive fiction and language parsing compared to other virtual machines like the JVM or WASM?
It was invented first.
That’s it.
EDIT-ADD: Okay, that’s too short an answer. A better answer is that it was invented first and it’s simpler. The Z-machine (and followups like Glulx) can be implemented by one person working from a spec document. The JVM and WASM are complicated enough to require the resources of large companies behind them.
This means that IF interpreters could be developed and extended entirely within the community.
It had an object tree that made for an excellent world model.
I’d add that the Z-machine also had a lot of design optimizations to work in constrained environments and abstract away hardware differences. Most of that is much less irrelevant today, but it did allow the Z-machine to be easily ported to a large variety of hardware, at a time when hardware diversity was probably at its maximum.
Yeah, I agree with that. Those optimizations (which, to be clear, include the object tree) made it possible to build IF for a bunch of 8-bit platforms; they were crucial in the 1980s.
Those features have not been important since 1995 or so, and indeed Glulx discards a lot of them. (No object tree or dictionary in the VM, e.g.)
It also doesn’t generally require any fancy features. The status line can be a bit of a pain, now that fixed-width terminals where you can move the cursor around freely aren’t standard, but it was designed to be easy to implement on different platforms, so the user interface is pretty simple: for the most part, you can print text, you can request a line of input, or you can request a character of input, and that’s it.
Nowadays, that sort of UI stuff tends to be the most different across platforms—implementing an object tree in memory is going to be basically the same on Windows as on Linux, whichever language you choose—so having it be as simple as possible is good for portability.
Version 6 of the Z-machine is the one that tried to get fancier about it, with menus and graphics and fonts and such, and as a result it’s far less portable than the others and most interpreters don’t run it.
I don’t think the WASM VM is that complicated, more the issue is that people expect it to have very good performance, which is where most implementations get complicated as they involve JITs and CPU specific optimisations. But a Z-Code game usually doesn’t need too much performance to run acceptably. Except for some Inform 7 games…
I guess the ability to run games larger than could fit into RAM at once helped to? Even if it meant you needed a floppy drive, which could make them a bit slow. Also, for the computer I grew up with the floppy drive cost a lot more than the computer itself so we never had one. (But it didn’t have Infocom games anyway so who cares, right? 
)