Andrew Plotkin: Portfolio

I designed and created a web app that plays Zork 1, the original Infocom text adventure from the 1980s. I’ve extended the interpreter to display Zork’s source code as you play. Every turn, it shows exactly what functions were called and what strings were printed to carry out your commanmd.

The Visible Zorker allows you to explore the implementation of Zork in the same way that you explore the game world.

I took an existing open-source Z-machine interpreter and instrumented it to record runtime execution data. I then built a React interface to display that data along with the game's source code. This involved rather a lot of analysis of both the compiled game file and the source code. (Both formats are well-documented, but I had to match up each function and string and object with the source lines that generated it.)

I designed and built experimental multiplayer hypertext user-extendable environment. Imagine a hybrid between an Twine and an old-school text MUD.

The front end is jQuery; the back end is Python and MongoDB; they’re connected by a websocket. Players can build new content using a wiki-style text editor and Python as the game scripting language.

To make this work, I had to implement a safe subset of Python in Python. This was surprisingly easy. On the down side, since this is a 2013 project, it’s Python 3.4. The prototype works great but it would need a lot of reworking to scale beyond a few dozen users.

I designed a spiritual successor to Infocom’s Z-machine, which was originally created for the home computers of the 1980s. Glulx has a 32-bit architecture and a pluggable I/O system. The latter allows text games to behave consistently across many kinds of UIs — native GUI apps, web pages, Slack/Discord bots, even headless modes for automated game-testing.

I implemented the first Glulx interpreter in C. Since then I’ve ported it to ObjC (for iOS) and JavaScript (for the web). I then wrapped the JS version in Electron to turn it into a portable downloadable app.

On the compiler side, I extended Graham Nelson’s Inform 6 Z-machine compiler to generate Glulx game files from the then-standard Inform language. This has been carried forward to the modern Inform 7 language, which is still in use.

Inform 6 is a text-adventure compiler. It is written in pure C. I am not the originator of this project (that was Graham Nelson, 1993), but I added a new 32-bit back end to the code generator (see Glulx).

Over the past decade, I’ve been the primary contributor to the codebase, tidying and refactoring. The biggest job was changing the memory management system from simplistic pre-allocated blocks to extendable memory pools. I also added a test suite of some 700 cases, along with a debugging malloc library, to check for array overflows and other C sins.

An interactive presentation of Jason Shiga’s choose-your-path comic book Meanwhile. I worked with the author to redesign his book as a playable app, and then implemented it for iOS (ObjC).

A few years later I ported the game logic to Unity (C#) for a Mac/PC release. The underlying data was the same, but I had to adapt the original touchscreen UI to both mouse and gamepad input. I wound up implementing a custom UI system for Unity, and also pulled in a vector rendering library for certain parts of the game display.

I have since used the same frameworks to release iOS/Mac/PC versions of two more of Jason’s books: Leviathan and The Beyond. (Samurai vs Ninja is scheduled for this fall.)

I was the lead designer and implementor of a dialogue and story management engine for Unreal. I originally built this as a contractor for The Molasses Flood, a Boston-area game studio. The studio was later acquired by CD Projekt Red and I was brought back on to develop the engine further for a game in the Witcher universe.

TMFS was a screenplay-like scripting language, somewhat like Ink, but with facilities for describing scenes, characters, and locations as well as dialogue. The intent was to procedurally generate quests and story arcs by assembling scenes according to story rules. I was responsible for both the compiler (source code to Unreal assets) and the gameplay implementation of those assets (directing NPC interactions according to the script).

The game was rescoped several times in early 2023, and a large part of the team was laid off, including me. I believe the game is still in development and TMFS is still part of it, but I don't know how it has changed since I left.

(No links, I'm afraid; TMFS is a proprietary technology for a game in development.)

Wanderstop is a 2025 game by Ivy Road. I was not involved with developing the game itself, but I helped build the narrative workflow that the developers used.

Wanderstop began with a narrative concept (see the web site) and several pages of sample dialogue from the lead writer. The developers came up with a scripting language and dialogue engine to handle this content, but they had some trouble closing the write-edit-test loop. I was brought in for a few months (mid-2021) to review the system and suggest improvements.

(I am credited as "Tools Programming Consultant", which is generous of them.)

I was one of two engineers building a next-generation dialogue system for videogame characters. The project was conceived by Emily Short for a company called SpiritAI. The intent was to combine flexible, topic-based dialogue mechanics with AI lexical analysis of the player's input. (2017-era AI, not current generative AI.)

Character Engine was originally written in C#. I was involved in porting it to C++ as a plugin for both Unity and Unreal.

We worked on Character Engine intensely for a couple of years, but sadly the project did not gel with how the company wanted to run it, and nothing ever shipped.

In 2016 we brought several interactive fiction services together under the legal umbrella of the "Interactive Fiction Technology Foundation", a 501(c)(3) educational nonprofit.. This let us combine hosting resources and legal backing — and of course gave people a way to donate money to support IF.

I was a founding board member and the organization's first treasurer. More importantly for this portfolio, I wound up in the role of tech lead for the organization. I set up servers, managed our DNS records, and acted as admin for our AWS, Slack, and similar tech accounts.

I was by no means the only admin for IFTF. Each one of our services — the forum, the wiki, and so on — had its own admin. Mostly they managed things on their own. I was the coordinator and backstop "I don't know how to do this, can you help?" person.

As the organization grew, it outgrew various long-standing hacks. I had to research and set up scalable solutions. (Open-source and self-hosted, where possible.) Email was the first of these; I oversaw the transition to an organization-wide Fastmail setup. I also replaced Mailchimp with a self-hosted solution and set up an org-wide password vault.

After eight years, I managed myself out of that role by heading up the search for a replacement tech lead. (And treasurer as well.) I trained up my replacements and stepped down at the end of 2024.

(I was also the long-time admin of the IF Archive; I am still wearing that hat. But I'll list that role separately here.)

The IF Archive is an open-access, fan-supported repository of interactive fiction history, games, and tools. It's been running since 1992. (Before the Web! It was originally an FTP site.) I created an HTTP mirror in 1999, and then took over as primary maintainer in 2001.

The Archive is part of IFTF, but my work for IFTF is a separate role (with different dates!) so I'm listing them separately.

The Archive was originally a purely static web site. I built a script to generate HTML index page for every directory. Over the years, we brought on more volunteers to help organize files. In 2023 I built a web-accessible file admin interface. This allowed volunteers to move files around and edit metadata without needing root access to the server.

(The admin interface is for Archive staff only. You can try it out in test mode by building this Docker container.)

I've also added features such as search, an XML index, and so on. But the most important feature is keeping the service alive and stable over decades of use.

I created a static site generator tool for my blog and imported my long-running blog into it. I used to use Google’s Blogger.com service, but Google likes to cancel services and I didn’t want to be caught short. Static site generators are the way to go, but existing solutions are either heavyweight or so thin that you might as well do it yourself. I did it myself. I also built a photo repository in a similar style.

The hard part was not building the site generator, but exporting fifteen years of posts and images from Blogger.com and massaging them into a good format for my site generator. Google has a data-export service (full credit there) but a surprising number of details had changed over the years, so I had to handle several different HTML and uploaded-image idioms.