Zarf Updates

I spin a bunch of verbiage on the Kickstarter page (and in the video) about Glulx and Quixe and other silly words. Long-time IF aficionados (with your bottles of aficiolemonade, yes, I know I've made that joke before)... sorry.

Long-time IF aficionados already know what I mean by all those terms; you can tune out now. Contrariwise, if you have no interest in the software architecture of IF interpreters... you can also tune out now. But if you think APIs are cool, read on.

History: The Z-machine

In the beginning was the Z-machine. It was 1979 or so, and a bunch of Infocom hackers needed a virtual machine design to easily port their planned text adventures to the home computers of the era.

The Z-machine is a nice design, only slightly compromised by the nagging inconsistencies of real life. It's a simple 16-bit architecture, with a stack and up to 64 kilobytes of memory -- not too different from the real CPUs that were about to conquer the world. The instruction set includes a few operations customized for IF, though. It has single opcodes to print out text, and read in lines of text (and keystrokes when desired). There's also built-in handling for the world model, which is a big linked tree of data structures representing objects. These data structures can have flags and property lists.

It's important to understand, coming in, that this was an extremely general design. The Z-machine has no built-in notions of treasures, weapons, light, darkness, or even players or rooms. There is no text parser in the specification. All of that was left up to the game author, who had to implement them in a program which ran on the Z-machine.

(Of course Infocom developed a large library of code, including text parsing, room handling, and so on. They shared that from game to game. But any part of that code could be adjusted or customized, if needed, for a particular game. The underlying game engine didn't care; it was the same for every game.)

On the flip side, the Z-machine was also general about how text should be displayed. That was left up to the implementation on each home computer. Most people are familiar with the fixed-width, terminal-style display of old IF -- but the games played equally well when the Macintosh arrived, with nice proportional fonts and a scroll bar on the window.

Rolling on. In the post-Infocom era, the Z-machine game files and interpreters were deconstructed by fans. That led to the first open-source interpreters, which allowed Infocom games to be played on newer computers. (With nice proportional fonts!) It also led to Inform, a fan-made compiler which could generate new Z-machine games. (The Inform language didn't resemble what Infocom had used, but it offered the same functionality.)

Inform and the Z-machine made excellent partners. They weren't the only platform for amateur IF in the 1990s, but for several years they were the most advanced tools that were completely free to use and port. (TADS was shareware through 1996 and its source code was not released until, I think, 1998.) I have used the Z-machine for all of my released IF -- not counting my high school Applesoft efforts.

However, even ten years ago, it was clear that the Z-machine would not suffice forever. The 64k memory limit was already stretched in Infocom's time. They had used bit-shifting tricks to reach 128k of space, and then 256k. Inform games, with a more powerful (and less finickily parsimonious) library, had doubled that again. But this extra space could only be used in a few limited ways -- for game text and function code. IF games had a lot of game text and function code, so the tricks helped. But the Z-machine was still fundamentally a 16-bit system, and it could only address 64k of writable game state. Imagine a machine with 512k of ROM, but only 64k of RAM.

It was at that point that I started plotting my dark schemes.