You Are Likely to Be Eaten by a Grue: The Current State of Interactive Fiction
Sun, 28 Dec 2025
Over a decade ago, I had an idea for a text adventure game. It started as a faint narrative thread in the back of my mind, but as I began to pull at it - fleshing out the story, imagining the puzzles, and structuring the world - I naturally shifted to thinking about implementation, and my first instinct was to avoid reinventing the wheel. Surely, in a genre as historic as interactive fiction, there were already free software tools to build these games?
I set out to find out. I expected to find what I always find when I explore a new domain of software: a vibrant ecosystem of free software.
Instead, I found a world seemingly untouched by the ideals of software freedom.
As I looked into the most popular software for writing interactive fiction, I didn't find the free software movement's bazaars of freely licensed software. I found a walled garden filled with proprietary compilers and proprietary documentation, all being used to build proprietary games. Worse, I found a community that didn't just tolerate these restrictive chains - they celebrated them. I watched as they hosted competitions to build proprietary text adventures with these proprietary tools, handing out awards to authors for being masters of their craft, all while ignoring that the very tools they were using were restricting them and the proprietary games they made were restricting their users.
For someone like me, who has lived and breathed the philosophy of free software for so long - someone who is intimately familiar with how proprietary software mistreats its users - it was a disorienting shock. It felt like stumbling into a backwards, upside-down reality, a digital Planet of the Apes where the values I held as self-evident were not just ignored, but actively inverted. I had walked into the dark without a light, and I realized, quite suddenly, that I was likely to be eaten by a grue.
To understand how we got here, we have to look back at the genre's origins. It all began with Colossal Cave Adventure. Generally considered the first text adventure game, it was a simulation of a real cave system in Kentucky, mixed with fantasy elements. You explored the cave, found treasures, and solved puzzles. But it was primitive. It relied on a simple two-word parser that only understood verb-noun commands like "GET LAMP" or "KILL SNAKE." If you tried anything more complex, the game couldn't understand you.
Some time later, a group of hackers at MIT decided they could do better than Colossal Cave. They were part of the Dynamic Modelling (DM) group, which was located in the same building (545 Tech Square) as the Artificial Intelligence (AI) Lab, where Richard Stallman worked. Both groups were steeped in the same hacker culture and had a PDP-10 mainframe running the Incompatible Timesharing System (ITS).
The folks at the DM group looked at Colossal Cave and saw a challenge. They began writing their own game, which they eventually called Zork. Unlike its predecessor, Zork was technically sophisticated. It featured a parser that could understand complex natural-language sentences. You weren't stuck with two-word commands; you could type something like "open the green door with the red key and then go east," and the game would actually understand and execute it.
Zork was initially implemented in a Lisp-like programming language called Muddle (shortened to MDL, but pronounced Muddle), developed explicitly by the DM group. By 1977, the game had become a massive hit on the ARPANET, and people across the country were logging in to solve its puzzles. The developers - Tim Anderson, Marc Blank, Bruce Daniels, and Dave Lebling - eventually decided to commercialize it. They founded a company called Infocom and set out to sell Zork to the general public as proprietary software.
However, they hit a massive technical wall. The mainframe version of Zork used a megabyte of memory, an astronomical amount for the time. The popular home computers of the era, like the Apple II or TRS-80, had a tiny fraction of that, often as little as 32KB.
Their solution was twofold. First, they split the massive original game into a trilogy: Zork I, Zork II, and Zork III. Second, they invented the Z-Machine.
The Z-Machine was a virtual machine that allowed them to run their massive game on tiny hardware. It used a custom character set called ZSCII to pack text efficiently, but its real magic was how it handled memory. It treated the floppy disk as if it were RAM, implementing a form of virtual memory that paged data in and out as needed. This allowed games that were far larger than the computer's physical memory to run smoothly.
As the home computer market exploded in the 1980s with dozens of incompatible systems, the Z-Machine became Infocom's secret weapon. They didn't need to rewrite their games for every new computer; they just had to write a Z-Machine interpreter for that specific machine, and all of their games would run on it instantly. This platform independence fueled their success for years.
But eventually, Infocom ran into hard times, was purchased by Activision in 1986, and shut down in 1989, marking the end of the era of commercial interactive fiction but not of proprietary interactive fiction.
As the computer industry marched forward, replacing the Apple IIs and Commodore 64s with newer, faster machines, people found themselves unable to run the games they had purchased. The community didn't wait for permission to solve this. A group known as the InfoTaskForce set about reverse-engineering the Z-Machine: they figured out how the virtual machine worked, bit by bit, until they could write their own interpreters. This was a triumph of hacker ingenuity, but its primary goal was preservation: they did it so they could continue to run Infocom's proprietary games on modern hardware.
Into this environment stepped Graham Nelson. He didn't just want to play old games; he tried to make new ones. He dissected the Z-Machine format further and made Inform. It was a compiler and a language of the same name that could generate Z-Machine story files, effectively giving anyone the ability to do what only Infocom could do a decade prior.
However, despite this, the "free software" ethos was missing. Graham Nelson used his new compiler to make a game called Curses. But like the Infocom games that inspired it, Curses was proprietary. It was distributed as an opaque binary file - freeware, yes, but not free software. You could play it, but you couldn't study how it was made, you couldn't modify it, and you certainly couldn't learn from its source code.
This tone has continued in the interactive fiction community. There's a culture in which authors release their game files but keep their source code jealously guarded.
This culture of secrecy is codified in the community's institutions to this day. The major competitions, such as the Interactive Fiction Competition (IFComp), generally require that entries be "unreleased." In the world of free software, we develop in the open; we push our code to public git repositories, we welcome collaboration, and we share our progress. But in the interactive fiction community, our way of life is effectively banned. To participate, you must develop your game in secret, hidden away on a private drive, ensuring no one sees a line of code until the "grand reveal." It's a workflow that demands you act less like a community member sharing knowledge and more like a miniature Infocom, protecting trade secrets that don't even exist.
Graham Nelson refused several requests to make Inform free software, but was eventually convinced to adopt a dual-licensing approach combining a proprietary license and the Artistic License 2.0. Finally, the compiler was free.
However, while the compiler was freed, the definitive guide to using it, The Inform Designer's Manual, remained under a restrictive license. This creates a trap that the GNU Project has warned about for decades: free software needs free documentation. As noted in the GNU philosophy, if you have the right to modify the software but not the right to modify and redistribute the manual that explains it, you are still effectively locked out. You can't update the documentation to reflect your code changes.
Later, the community saw the arrival of Inform 7, which allowed people to program using code that looked like natural English sentences. Under the hood, however, it was a complex translation layer that compiled down to Inform 6 code. For years, Inform 7 remained strictly proprietary, a black box that the community relied upon but could not touch. While it, too, has eventually become free software, it comes with strings attached: contributing to the project requires a copyright assignment to Graham Nelson. This centralization of power ensures that the community doesn't truly own the project as we expect in the free software world, because Graham retains ultimate control.
Even with the software free, a gaping hole remains: we still lack a free replacement for The Inform Designer's Manual for Inform 6 and for Inform 7. Writing a comprehensive, copyleft guide for these would be a valuable contribution to the community, finally severing the reliance on proprietary documentation.
But this struggle for freedom wasn't just about Inform. For decades, everything we knew about the Z-Machine was based on reverse engineering. The community built interpreters and compilers without ever seeing Infocom's original tools, forcing them to invent their own names for opcodes and figure out internal structures.
That changed when a cache of Infocom's internal source code leaked. This data - still strictly proprietary - revealed that Infocom had used their own language called ZIL (Zork Implementation Language). ZIL was a massive collection of macros built on top of the Lisp-like Muddle language. The leak included the source for Infocom's games, as well as early versions of Infocom's own toolchain: a compiler named ZILCH (ZIL Compiler Hack) and an assembler named ZAP (Z-Language Assembly Program). There's a video that goes over the history and technical information.
With the secrets of ZIL exposed, work began to make free software for compiling this language: a compiler called ZILF and an assembler called ZAPF. While these are free software, they come with a significant architectural flaw: they're written in C#.
For those of us concerned with software freedom, C# is a problematic foundation. As the Free Software Foundation has warned for years - specifically in their page about why free software shouldn't depend on C# - implementing free software in C# invites the threat of software patents. While the immediate legal threats may ebb and flow, building our infrastructure on a language ecosystem controlled by a proprietary giant is a strategic error.
Then, in November 2025, Microsoft, having acquired Infocom's copyrights after buying Activision, officially released Zork I, Zork II, and Zork III as free software under the MIT license. For the first time, we could legally inspect the code that built the genre. Yet, this victory was incomplete. While the trilogy was freed, the rest of Infocom's library remains locked away, and crucially, so does the toolchain. Microsoft didn't release the original ZILCH compiler or ZAP assembler. We were given the source code to the games, but not the original tools to build them.
And so, this is where we find ourselves today. When I first looked at this community years ago, it was a walled garden of pure proprietary software. Today, the landscape has shifted technically, but culturally, it's barely moved. We have access to ZIL's history, albeit through leaks, and to free software tools like ZILF and ZAPF, yet the community remains stuck in the same proprietary patterns I saw years ago. People are still releasing proprietary games while jealously guarding their source code. Competitions still enforce "unreleased" rules that discourage our usual norms of community and collaboration. The "backwards" world I stumbled into has acquired better tools, but the mindset remains the same. We're no longer entirely in the dark, but we are still waiting for a toolchain that is genuinely free, portable, and safe from the threat of software patents. And there's still the push for cultural changes to value user freedom as much as they value game design and complexity. The grue hasn't eaten them yet, but they aren't quite out of the cave either.