Sunday, September 6, 2009

Rebuilding the Z-machine


  I've created this blog to share my experiences in building a Z-machine interpreter. My name is Mike Greger and I am a C# developer and a gamer. I got started with computers in the early 1980's when I became fascinated by the worlds found within so-called 'text adventures'. Some of my favorites were written by a company called Infocom.

What is a Z-machine?
  Infocom created a clever way of making their games available for the many types of computers on the market at that time by designing a virtual machine now known as the Z-machine. Each game only needed to be written once, for the Z-machine. A Z-machine interpreter was then written for each platform to run the games.
  Fast forward to 2009: Infocom is long gone. The Z-machine format has been reverse engineered by talented people and the specifications made available. Armed with this information developers have created Z-machine interpreters for platforms big and small.

If it's already been done, then why do it?
  The short answer is because of the challenge and learning opportunities it presents. I also like to think I can improve on some things. Some time ago I set out to write my own interpreter and succeeded, sort of. My interpreter played all the infocom games just as I remembered them. However, when I first started my project I did not have a lot of programming experience. Looking back later at what I had written I found the code amateurish and not suitable for easy reuse. I decided to rebuild it and came up with a set of design criteria for a class library written in C# 3.0 which implements the Z-machine:
  • Complete. Supports all features and Z-machine versions
  • Easy to use and extend
  • Decoupled from any particular interface (console, windows forms, WPF, etc.)
  • CLS compliant
  • Well documented
  • Thread-safe
  • Memory efficient for multiple instances
  • Not overly dependent on framework types
The last requirement is to help ensure portability to platforms like Mono or others which may not implement the entire .Net framework. Thread safety and multiple instance support allows the library to be useful in a web server or other multi-user environment.

Why write a blog about it?
  In the hope that someone will find something useful, maybe for their own interpreter or other project. While the published specifications contain a lot of useful information, Z-machine behavior can be complex and seeing a working example can be beneficial. Additionally I hope to make clear why I chose certain designs, rather than just publishing source code. Code comments tend to explain how something works, not why it was written that way in the first place.

Next time: Z-machine architecture.


  1. Looks like fun! I'll definitely start following this blog.

  2. Subscribed (thanks Eric for pointing this out). I've always wanted to do this myself, just never had the tuits.

    > take popcorn
    You have taken the popcorn

    > eat popcorn
    You settle in to watch the show with a bag of hot, buttery popcorn.

  3. Will you perchance be making the source available perchance. (An SVN repo would be great!) In any case I will be following!

  4. I will make the source available eventually. My original was available once but I took it down because I knew it could be a lot better.
    At the moment the source is in such flux I doubt it would do anyone any good as it is missing big chunks I am in the process of rewriting.

  5. Hey, just found your blog via Eric Lippert's post. Really cool! Kind of funny, but I started my own project that's been done before in C# for pretty much all the same reasons you listed here, and also just started blogging about it.
    I've been interested in IF languages/engines for quite a while and will be following your blog...

  6. wow, this is very interesting, cant wait to follow all your work.