You are standing in an open field west of a white house, with a boarded front door. You could circle the house to the north or south. There is a small mailbox here.
> open the mailbox
Opening the small mailbox reveals a leaflet.
> read the leaflet
“WELCOME TO ZORK, a game of adventure, danger, and low cunning. No computer should be without one!”
Thus begins Zork, perhaps the most famous of the classic Infocom text adventures of the 1980s. I grew up playing all the Infocom games. The puzzles, the sense of humour, the cleverness in a computer program that appears to understand English commands, all enchanted me in my youth, and still do.
As a child who could write programs that animated rocket ships flying around the screen, I was mystified as to how anyone could write a program that could understand English. What I only came to appreciate much later in life was that this was not the major technical achievement of the geniuses at Infocom. The real deal was that they solved in a stroke two major problems in the video game industry of the late 1970s and early 1980s:
- How do we write games once that can run on multiple platforms?
- How can we write games with code larger than the limited memory size of 1980’s era 8 bit computers? 64KB of memory is not much to work with.
The solution they came up with anticipated the Java VM and the CLR by decades:
- Solve the portability problem by compiling the games to a virtual machine bytecode language, not to any particular architecture. Then write an interpreter for every target machine. Now you can write n games and m interpreters at a cost of n + m instead of writing n games m times each for a cost of n * m.
- Solve the memory problem by implementing a virtual memory system in the virtual machine. Unused code or resources can stay on disk and be paged in when needed; code that hasn’t been used for a while can be abandoned and read back in later.
Genius! And this is what they did. The VM is now known as the Z-machine, Z for Zork, of course. This solution is ideal for text adventures which have huge-for-the-time code and text resources but do not have down-to-the-tenth-of-a-second timing requirements that most video games have.
Long after that, more super smart people reverse-engineered the six different versions of the Z-machine that Infocom created over the years and published a specification. So now anyone can write an interpreter for the Z-machine and run the old Infocom games.
Anyone, including me!
I have been meaning for some time now to implement a Z-machine, just for fun. My goal is certainly not to compete with any existing Z-machine implementations; there are plenty that do a better job than mine will at providing a pleasant gaming environment with beautiful text rendering, that support all of the later Infocom games with their graphics and sound effects and whatnot. Rather, my goals for this project are:
- Learn about the Z-machine
- Have fun writing some code and blogging about it
But there’s more. I’ve talked for years about functional programming in this blog, and large parts of Roslyn were written in a manner inspired by functional programming, but I have never written a largish program entirely in functional style. So:
Principle #1: The entire program will, as much as possible, be written in a purely functional, side-effect-free style…
Here’s the bit that I really decided to grit my teeth over:
Now I know what you are thinking. Why on earth would the C# guy start writing code in OCaml, of all possible languages?! If someone like me, with long experience in the .NET stack wants to learn a functional language in the ML family then surely the natural choice is F#, with its beautiful debugger support in Visual Studio and interoperability with C#.
I have my reasons! I will go into them in a future post. But for now, just accept the fact that this blog is going to be about OCaml for a while. I’m hoping that it will be an interesting learning experience for everyone. We’ll get back to C# eventually.
As we go I’ll try to deduce some highfalutin moral principles for working in functional languages, or any languages for that matter.
And besides, the title of this blog will be more accurate than usual: we’ll literally be coding up some fabulous adventures. Join me!
If you want to follow along, you’ll need an installation of OCaml. Windows users can download OCaml 4.02 from OCamlPro at
I used the Windows installer “ocpwin64-20160113-4.02.1+ocp1-full-mingw64.exe”
An alternate site, which I have not yet tried, is
which links to installer
If you’re using a unix-based operating system, or Cygwin, or whatever, I leave it to you to figure out how to install OCaml 4.02.
And hey, for all I know, this could all be legal F#. It couldn’t hurt to try, though I have not taken the time to do so myself.
OCaml has both an interactive “REPL” mode and a traditional compiler mode. I’ll be using the latter, but I encourage you to try out the REPL, look at some online tutorials, and see how you like it. We’ll start looking at some code next time.
Next time on FAIC: How do you twiddle a bit in OCaml?