For the duration, this blog will move in a slightly different direction than it has in the past. I’ll use this oddly titled post to explain what that means and why that is. By the end of the post, the title won’t seem so odd. And even if it still seems odd, it will at least be understandable.
To save someone having to wade through this to determine if they’re interested, the short version is this: I’m going to start a series of posts on how to build a Z-Machine emulator and interpreter, which you can classify as a retrogaming endeavor.First, Some Context…
In terms of my career, I’ve often moved relatively orthogonal to the broader test industry. I’ve found value in that, but I’ve also found that there’s only so long you can sustain being a cultural gadfly. I’m one of those people who feels the testing industry is in the most danger from its own practitioners. I’m also one of those who think that many of the most vocal advocates for testing are actually doing more harm than good to the testing discipline.
I could be very wrong on all that. But that is how I feel.
In terms of the blog, coupled with the above feeling, I have more and more often felt like I’ve said all that I can say right now in the arena of quality assurance and testing. Or, I have little more to say that differs from what everyone else is already saying. That’s been one of the critical conceits of my blog: to not just sound like every other tester out there.
At some point, I want to undertake a historical revisit of my various posts and update them with what I’ve learned as a way of keeping myself not only intellectually curious but also intellectually honest. However, I will take this blog down a slightly orthogonal path for now. This means the blog will likely become an even more self-contained vanity project than it already is. That entirely risks losing any readers.
Perhaps oddly, I’m okay with that for now.
All that being said, let me explain what I’m going to be doing since it is related to the broader themes of testing and development that I’ve talked about for many years now.
Grue: A Z-Machine
The project will be called Grue, and you can read up more on the concept of a “grue” in this context, should you find yourself curious.
I’m going to work on creating a working emulator of the Z-Machine and an interpreter for zcode programs that will run on that machine. This means I will be building an Interactive Fiction interpreter. Depending on your age and/or nostalgia factor, you might better know “interactive fiction” by the name “text adventure.”
Fun fact for nostalgia retrogamers: the term “interactive fiction” was likely first used by Robert Lafore.
The Z-Machine was originally created by a company called Infocom back in the late 1970s to play their adventure game Zork on microcomputers (which were the first “personal computers” with a side evolution into “home computers”). Eventually, this Z-Machine was used to play many text adventure games created by the same company throughout the 1980s.
Starting in the 1990s, after Infocom was acquired by Activision and effectively dissolved, hobbyists reverse-engineered the Z-Machine and games have been created for it ever since.
These “games” are often referred to as “stories,” keeping with the focus on interactive fiction.
But … Why Do This?
A while back, I wrote my testability series. In that series, I showed how it was easy for bugs and bad design decisions to crop up in even the most straightforward examples. But that was very much a toy example to demonstrate some points. The Grue project will be more illustrative because, in the end, I fully intend to have something that demonstrably works in a realistic context.
There are a couple of interesting challenges to this project.
It became clear to me that the Z-Machine Standards Document — which is essentially the requirements — is probably one of the poorest written specifications I’ve ever seen. A document was created — “The Z-machine, And How To Emulate It” — in an attempt to remedy some of the many ambiguities in the official specification. This latter document is even more poorly written and gets a few things wrong to top it off.
A challenge is that only a few complete reference implementations are available for study. In fact, the only one I could find that was broadly specification complete and accurate was Frotz. However, this code base has a long pedigree. It’s tricky to use in a way that is pedagogically useful for learning. There was a Z-Machine Preservation Project that aimed to provide an “implementation that is easy to understand maintain and extend.” In the end, the project was ported from Java to Scala — zmpp2 — which didn’t do much for the “easy to understand” part.
Eric Lippert started a “How to Write a Z-Machine” series, but he chose OCaml as his language, which pretty much no one uses seriously, and, probably due to shifting interests, left the series entirely unfinished. There’s good stuff there, but, on the whole, it could be more helpful. Gerben Castel did an excellent “Discover Rust with Zork” article but that was more about learning Rust than the implementation of a Z-Machine. Most recently, Hugh Davenport has been working on odinz, which is a Z-Machine implementation written in Odin, and he has a series of videos detailing his journey. The problem is that Odin, much like Rust or Go, differs from a language I would choose if part of your code base is designed to be pedagogically valuable.
Ultimately, I found nothing beneficial in helping construct a Z-Machine beyond the open-source implementations on GitHub or GitLab. And those implementations often remain incomplete, certainly in terms of supporting the Z-Machine specification. So that’s where this project comes in: an attempt to create just enough of a Z-Machine emulator and interpreter to ensure I understand how the thing works and where I can make a working implementation. This will be something that I can share that is (apparently) unique in terms of being available.
Along the way, I’d like to see how to test this thing as I develop it. This helps me be a student of my own craft. To be an effective tester, I often have to understand the theory of error and categories of error when people create complex things like software. This helps me understand why it’s hard to build software — not just at the common sense level but as an actual practitioner. The fact that I will be dealing with a less-than-ideal specification also matches what I deal with in my professional capacity.
Who Is the Audience?
I hope this project will be of interest to various audiences. One audience might be software developers in general. Another audience might be a more specific band of developers interested in learning how to create a Z-Machine emulator and interpreter. Yet another audience might be testers who, like me, believe you have to understand the development craft from the inside out to be the most effective tester you need to be in our industry. This includes engaging with developers on design and, more particularly, on testable design.
It could be a lot of fun for those who want to join me on this journey. The adventure begins in the next post where I’ll talk about the programming ecosystem I’ll use for this.
