Microsoft Makes Zork Open-Source
Key topics
The gaming world is abuzz as Microsoft open-sources Zork I, II, and III, legendary text-adventure games that captivated generations. Commenters are riffing on the significance of this move, with some hailing it as a preservation of gaming history and others speculating about the potential for community-driven mods and enhancements. As enthusiasts dig into the newly released code, they're uncovering insights into the original development process and marveling at the games' enduring influence on the industry. This unexpected release has sparked a nostalgia-fueled conversation about the evolution of gaming and the power of open-source collaboration.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
7m
Peak period
147
0-12h
Avg / period
26.7
Based on 160 loaded comments
Key moments
- 01Story posted
Nov 20, 2025 at 1:13 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 20, 2025 at 1:20 PM EST
7m after posting
Step 02 - 03Peak activity
147 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 25, 2025 at 10:34 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
IIRC, Al Lowe had retained copies of source code from the early Sierra days, and was planning to release some of it publicly a few years ago, but Activision shut him down. Maybe MS would be willing to reconsider that now that they're pursuing historical preservation.
Hence why when people think it is only a XBox console and nothing else, couldn't be more wrong.
---
<ROUTINE V-ADVENT ()
https://en.wikipedia.org/wiki/MDL_(programming_language)
('ADVENT' is https://en.wikipedia.org/wiki/Colossal_Cave_Adventure , for anyone who isn't familar.)
https://the-rosebush.com/2025/07/studies-of-zil-part-2-how-d...
It was public already, what they are doing here is open sourcing the code.
https://mordenstar.com/zork
MC Frontalot - It Is Pitch Dark
https://www.youtube.com/watch?v=4nigRT2KmCE
Featuring Steve Meretzky!
https://en.wikipedia.org/wiki/Steve_Meretzky
https://github.com/MITDDC/zork
What's the lineage here?
The source you're linking to is the original MDL source. This is about the ZIL source for the three games that the original Zork was split into.
Okay, I get it. Lisp is great.
Where should I start? It wasn't like I was planning on doing anything else at work next week...
In no time you'll be putting up "my other car is a cdr" bumper stickers!
Yeah but then learning Lisp is going to get in the way of welding up new bumper brackets, and the bumper will still be lying in the pile of things beside the shed waiting to be reattached... ;-)
These articles are very good and accessible:
https://www.norvig.com/lispy.html
https://norvig.com/lispy2.html
This is the version i read:
https://www.abebooks.com/9780023397639/Little-LISPer-Third-E...
(The professor I had for that AI course in Grad School didn't know Lisp and wanted to learn it better, especially because so much of the textbook was in it, so asked us for volunteers to learn it as well and I took that as an excuse/challenge to do every project with a language choice that semester in Common Lisp.)
[0] https://www.sbcl.org/
https://www.cs.cmu.edu/~dst/LispBook/book.pdf
Install Clojure. Read https://clojure.org/guides/getting_started and choose an editor. If you don't have a favorite editor, I recommend NeoVim with the LazyVim package (clone https://github.com/LazyVim/starter and follow instructions), then run the :LazyExtras command and install the Clojure package. If you haven't used LazyVim before, https://lazyvim-ambitious-devs.phillips.codes/ is a good book; you can read it online for free, then if you find it useful, purchase a copy to reward the author for his hard work.
Once you've installed an editor, you'll want to install https://leiningen.org/ which is the de facto (if not de jure) package manager for Clojure. Makes compiling your Clojure code to an .exe (for distribution to other machines where Clojure isn't installed) about as simple as it can be.
Once you've got an editor and a package manager installed, you're ready to read https://clojure.org/guides/learn/clojure as well as the various books on Lisp others are recommending. Depending on which book it is, the functions may have different names (e.g., some languages use `first` and `rest` while others stick with the historical `car` and `cdr` names, but they're the same functions), but you should find that the concepts translate perfectly well from one dialect of Lisp to another and the only challenge is having to look up what name the function has in the dialect you're using.
https://donhopkins.com/home/archive/MDL_Programming_Primer.p...
Introduction
Over the years the original MDL (pronounced "Muddle") Primer by Greg Pfister [Pfister 72] became more and more a reference manual and less a Primer from which a novice could learn the language. Some of the text of the original has been re-used in this document, but much has been eliminated, changed, or re-ordered, and a reasonable amount of new material has been added. In particular, a number of figures and many more examples have been added to make some of the more difficult concepts easier to understand.
This Primer is intended as an introduction to MDL. After assimilating the information contained herein, you should be able to write very good programs. However, for any individual topic in the MDL Primer there is likely to be more information available in The MDL Programming Language [Galley 79] and The MDL Programming Environment [Lebling 80], and there are many topics in these documents which are not addressed in the Primer. Anyone who plans to do any serious work with MDL should read these documents.
One of the difficulties in writing a Primer is to make it useful to those who don't know anything at all about programming without boring those who know a lot of the basics. Hopefully those at both extremes will find this to be easy to read. If you are a complete novice, however, there may be some unfamiliar references and some material which doesn't make sense on your first reading.
Why MDL?
Many people ask this. It is often hard for those who use MDL to put into words their reasons for liking it. Those of us who use MDL are convinced that it is a better language than any other we've encountered. Unfortunately, very little has been done to convince others of this and spread the use of this marvelous tool.
MDL was created in the early 1970's by a group at the Dynamic Modelling/Computer Graphics division of MIT's Project MAC (later renamed the Laboratory for Computer Science). It is an offshoot of the original Lisp. There have been quite a few offshoots of Lisp in the past 10 years MacLisp, InterLisp, Lisp Machine Lisp, Lisp1.5, UCI Lisp, Franz Lisp, etc., etc. but none of them are like MDL.
Since MDL is a distant relative of Lisp and many of those first learning MDL have some familiarity with Lisp, a short comparison of the two languages follows. If you are not familiar with Lisp (or, better still, with any other languages) count your blessings (you don't have any bad habits to unlearn) and skip the following discussion.
MDL's similarities to Lisp: MDL shares the advantages of Lisp over the more popular languages such as Basic, Fortran, Cobol, Algol, Pascal, etc.
It has an interpreter which allows real-time interaction and allows you to define and test individual functions separately.
Its syntax is very simple.
- Any data object or function can be passed as an argument or returned as a value.
- It has list structures equivalent to Lisp's.
- Recursive functions can be written quite easily.
The similarities between MDL and Lisp are such that in many cases a few minor changes to Lisp code will convert it into working MDL code. Given the other features of MDL, no MDL programmer would write the program in the same Lisp style.
MDL's dissimilarities to Lisp: Many objections to Lisp are answered in MDL.
-Strongly typed languages provide much better error detection tools than Lisp. MDL allows declarations of all variable types to whatever level of complexity is desired. A variable can be declared to be one of several types.
- Recursion is a useful tool, but often is not a very efficient way to solve the problem. Lisp's motto "To iterate is human, to recurse divine," is not one of MDL's tenets. MDL allows recursion, but provides excellent facilities for iteration.
- MDL has a very powerful set of data structures Lists, Strings, Vectors, and Uniform Vectors. Although lists are a very useful and flexible form of structure, they are certainly not optimal in all cases. MDL's various structures allow the user to save space and access time. MDL's structures are also "first class," in that the standard functions for manipulating data structures can be used on all of them equivalently.
Probably the biggest complaint against Lisp-like languages is that they are unsuitable for "production programming" because they are too slow. MDL has an excellent compiler which as far as we know is the best compiler for a Lisp-like language. It produces machine code equivalent in efficiency to Fortran and Cobol, which are considered very efficient.
-MDL has a rich library of useful program aids. The editing and debugging functions are among the best. The package system allows building of very large programs from small sections, usually written by different people, without worrying about variable name conflicts.
Probably the most distinctive feature of MDL is its mechanism for user-defined types, which is the best of any language with which we are familiar. User-defined types have been retrofitted on some of the newer versions of Lisp, but in most cases they can be used only with special functions and cannot be used in the same general way that Lists can.
Hopefully some of your questions have been answered and you have some ready answers when you get flak from your non-MDL programming friends. Learning MDL should be an enjoyable and worthwhile experience. Your reactions to this Primer and suggestions for changes are always welcome. Good luck!
Warning! You are about to embark on an undertaking fraught with peril. MDL programming has been proven to be habit-forming. Once you begin, you may find the habit hard to kick!
Acknowledgments
We are deeply indebted to our predecessors for their work on this topic: Greg Pfister, who wrote the original A Muddle Primer [Pfister 72], and Stuart Galley, who updated that document and added significantly to it to create The MDL Programming Language [Galley 79] document. Some of the text and examples of the original documents survive here, and some other material was simply rewritten in an order and style which we consider more comprehensible.
Special thanks to Chris Reeve, Dave Lebling, Stu Galley, Poh Lim, Thomas Michalek, Dave Scrimshaw, Tim Anderson; Mark Plotnick, and Prof. J.C.R. Licklider for their many comments and suggestions.
No document on MDL would be complete without acknowledging the "original implementors." If not for their inspiring work, this fine language would not exist. We are forever grateful to Gerald Sussman, Carl Hewitt, Chris Reeve, Dave Cressey, and Bruce Daniels. Thanks are also extended to the many unnamed hackers who have improved the language and the programming environment over the years.
This work was supported by the Advanced Research Projects Agency of the Department of Defense and was monitored by the Office of Naval Research under contract N00014-75-C-0661.
This document was prepared using Scribe and printed on the Xerox Dover printer.
(c) Copyright 1981 Massachusetts Institute of Technology. All rights reserved.
> User-defined types have been retrofitted on some of the newer versions of Lisp, but in most cases they can be used only with special functions and cannot be used in the same general way that Lists can.
Can you elaborate on this? The examples from the PFF suggest it's just the usual lispy type declarations.
Is it really that distant?
> The similarities between MDL and Lisp are such that in many cases a few minor changes to Lisp code will convert it into working MDL code.
I guess not.
Reading a bit of the code it looked superficially like a relatively standard Lisp but with some unusual syntax choices.
When Infocom shut down, one or more of the employees took home backups of the Infocom file server. Various partial releases have been leaked publicly from those backups, including tooling/language documentation and the ZIL source code for every Infocom game. The ZIL source code has been public since 2019. The notable thing that Microsoft is doing here is clearing up the rights to the 3 Zork games (but none of the rest of the Infocom titles).
DECUS fortran version: https://www.ifarchive.org/if-archive/games/source/dungeon-3....
f77 version for Unix: https://github.com/videogamepreservation/zork-fortran
(GNU fortran port: https://github.com/GOFAI/dungeon)
f2c translation (basis of many versions): https://github.com/devshane/zork
(See README for history of this version)
But the older version has a "Tomb of the Unknown Implementor," which this new version seems to lack.
the date on the Zork archive you linked to is 1977. in 1977 there was not really yet a notable software market for personal computers based on microcomputer chips, and software development at MIT in that timeframe would have been on Multics or DEC-10 or 20's and (probably not quite) the dawn of Vax-750s
just a couple years later the names on the archive you linked to went on to found infocom to sell this software ported to personal computers, Apple II 6502's or CPM S-100 bus 8080 and Z80s.
the Colossol Cave Adventure game for the PDP-10 had been released (to other institutions that had PDP-10's) just a couple years before and had caught fire in popularity at universities. These people at MIT took the same idea and reimplemented it with embellishments.
Which is to say, very, very, very far away.
You weren't going to buy it anyway. No-one cares about you. Pirate it if you like. Take your warezed copy of Office Home Edition and be blessed, no-one is going to miss your 120 bucks.
An organisation with maybe 100,000 users each paying a per-seat licence? Yeah, that's the sale they want. Not your one-off copy.
"This collection is meant for education, discussion, and historical work, allowing researchers and students to study how code was made for these interactive fiction games and how the system dealt with input and processing. It is not considered to be under an open license."
This github repo has been up for some years now (this old blog post has some back story: https://blog.zarfhome.com/2019/04/all-of-infocoms-game-sourc... ) -- AFAIK it's the source contents from an old hard drive image from back when Infocom was a company.
(I only checked hitchhikers and starcross, because github is giving a lot of error pages for these right now.)
Likely explanation: their lawyers are worried there may be third party rights or agreements limiting their ability to open source a game – even if that isn't true, lawyers want to see paperwork to convince themselves it isn't true. For Zork, that was comparatively easy because the game's history is well-known, and Activision had a history of releasing sequels. For other games, that may be more difficult – so start with the lowest hanging and highest profile fruit.
I could see this being important here in two ways:
1. If the source code of Zork has not been made available to the public before, then now is the year of publication.
2. If Zork source code has previously been made available to the public, perhaps the version published here has had changes made, in which case now is the year of publication of this version of the source code.
I assume that when Microsoft opens source code they have a team of lawyers that have solid legal arguments for what the copyright year should be in each case.
Therefore, maybe it’s even possible legally that
3. Even if source code was previously made available, and even if no changes were made in any way since then to any of the included source code or other files, perhaps just the act of using a different license is in its own way part of how copyright applies. Publishing something under a specific license in $CURRENT_YEAR does not retroactively make the license apply before the time at which it was made available under that license and so perhaps an argument could be made that copyright year in a license includes taking that into consideration.
(the grue would obviously just a picture full of black, though some creepy eyes would be a nice touch)
https://dzlab.github.io/notebooks/flax/vision/diffusion/2023...
It really depends on the creator. A slop is a side effect of the fact that the entry barrier has been much lowered. Previously you at least had to put some effort into learning the craft before showing that to the world.
[1] https://www.mobygames.com/game/28812/time-and-magik-the-tril...
It's more a gimmick than anything particularly useful. Might even distract if the image embellishes from the original description leading players down the wrong path for solving a puzzle.
Speaking of porting I have always vaguely wanted to port the original basic version of ultima, I mean never enough to actually do it, but I like the idea of the source being available to do so. even if it is just an accidental artifact of how it was made.
> Basic Information on the Contents of This Repository > > It is mostly important to note that there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file using an official Infocom-built compiler. There is a user-maintained compiler named ZILF that has been shown to successfully compile these .ZIL files with minor issues. There are .ZIP files in some of the Infocom Source Code repositories but they were there as of final spin-down of the Infocom Drive and the means to create them is currently lost. > > ... > > In general, Infocom games were created by taking previous Infocom source code, copying the directory, and making changes until the game worked the way the current Implementor needed. Structure, therefore, tended to follow from game to game and may or may not accurately reflect the actual function of the code.
Although I haven't played with it and can't tell you whether it can compile the open source Zork.
https://www.youtube.com/watch?v=A8Z1cKUxD9c
https://crpgadventures.blogspot.com/2016/05/zork-victory-sor...
I remember figuring out the mechanisms that the book introduced: what kind of rudimentary data structures to use to represent the state of the world, the locations of objects, etc.
I got some simple stuff to work, you could navigate the world, pick up and drop objects, etc. but then my motivation gradually ran out because I didn't have a clearly defined design for the game I was going to build.
I had a few pirated games (C64, Amiga): "Death in the Caribbean", "The Pawn", etc but never had the motivation to stick with them past the first or second puzzle. The puzzles seemed like if the answer didn't arrive via a flash of divine inspiration, there was no way to figure it out based on logical reasoning. Maybe that part of my brain wasn't developed back then.
But also I had access to TADS and early Inform (at home) and still wound up building a couple in BASIC (because school computer labs would have that available).
Wow, that's dedication!
I wrote my own adventure game for my Commodore PET, which had 8K of RAM. It worked well, but after three rooms of content, I ran out of RAM, so then I gave up.
My brothers got a lot of laughs out of those "programs".
Fast-forward 45 years and whose laughing now?! :)
I created parser recursion in BASIC (without a stack or a then non-existent GOSUB), using a string as the stack, including a character as a return destination (i.e. a flag for conditional GOTOs).
I was so proud of my parser!
A wrote many great unfinished games. I was more interested in better coding than completion, but the games still had a lot of color.
One Easter egg was if you typed “sh*t” the response was: “YOU HAVE DROPPED THE DUNG”.” You could do that anywhere, so a great way to detect you had walked in a circle in a maze or forest.
Later I used strings as a heap to define very simple 3D vector geometry.
(In early MATLAB, I prototyped some code with tree data structures implemented with an array, before they introduced their structures. The latter code shipped.)
Around the same time (1988) my best friend and I started making our first game in HyperCard. Getting more immediate results from that is probably how I ended up a SWE instead of in aerospace.
- Spiritwrak
- All Things Devour
- Calypso
- Tristam Island
A coding agent may even be able to suggest that path, as knowledge of at least the existence of both ZILF and Python ZVM should be in training sets.
The more interesting questions would be how much a coding agent could help you write new Zork rooms or similar things in ZIL now that these ZIL source files are MIT licensed. I would also assume ZIL is not well represented, it's fork of the Lisp family tree (Lisp -> MDL -> ZIL) in generally probably not well represented in open source code bases up to this point. (Some of that may depend on if the agent was trained on some of these historicalsource repos ahead of this open source license change, too.)
[1] https://zilf.io/
[2] https://github.com/sussman/zvm
> docker run -it clockworksoul/zork1
You made my day
https://github.com/clockworksoul/docker-zork2
https://github.com/clockworksoul/docker-zork3
I tried to use these official sources to make my own.
https://github.com/MattCruikshank/zork1-source
Curious if you have feedback:
> docker run -it --rm -v $(pwd)/saves:/home/zork/save mattcruikshank/zork1-source:latest
The -v lets me save and restore.
I tried to use Docker Compose to specify the volume... But the TTY support there feels terrible, and I don't know how to fix it.
Many modern implementations do not support permanent shifts in Z versions 3 and above (although all of my own implementations do, and I think all of the official implementations also do, even though Infocom never used that feature (this isn't too surprising since the algorithm they described for deciding when to use permanent shifts is worse than not using them at all; I worked with someone else to make a better algorithm for making this decision)).
Some of the official implementations check the Z version number and some don't; even some that do, do not check if it is a small-endian story file (and the ones that do will only display an error message if it is, and refuse to run it). My own implementations do check for small-endian story files (as well as the Z version number), although some will display an error message and refuse to run it in that case, some actually are able to run both big-endian and small-endian story files (as far as I know, there are no small-endian story files; Infocom never used this feature and no modern compilers support this).
Something else I might mention is that some people say that Infocom used many tricks in the programming, although I have looked at disassembled code in the debugger and found that they could be optimized a lot more (e.g. by using SET->BCOM optimization, and many other things), and the source code for the interpreters also shows some things that could be optimized much better. (Another thing revealed from the source code of the interpreters is a undocumented command-line switch for the DOS version that allows you to specify the name of the story file.)
I'd like Zork I through III ported to Inform 6...
I don't specifically know why that appeals to me. I guess it's because I'd like to tinker with it and understand it better. And if I were going to write Zork I from scratch today, I'd want to use the most modern tools available. [checks notes] Okay, but not Inform 7. I have an aversion to Inform 7. I want my code to look more like code, and less like an LLM prompt.
Ah, and yes, IF6 ports for Adventure do exist, both in English and Spanish, and the Spanish one it's really great, with even the backstory on creating the game perfectly translated..
I feel the same about Inform 6 vs 7. I wrote some very simple games in Inform 6 thirty or so years ago, just for personal amusement, but never did a thing with Inform 7.
I guess I'm skeptical of "literate programming" in general, where I have to learn a special way of phrasing English just to interact with some magical process that I don't and can't understand... all so I can avoid typing a few square brackets and semicolons. I think there's an underlying symmetry to the conceptual structure of interactive fiction and the way it looks in Inform 6 that is much easier to reason about... but eh. I'm a couple decades late to the argument.
For anyone out there who had anything to do with bringing these games to market, know that you impacted so many lives in a fun, meaningful, heartfelt way.
Still, pretty cool; I remember playing work as a kid.
Sigh… it’s all ChatGPT nowadays ain’t it.
So this is useful to modify zork, but not much changes if you want to build something around zork, as you will most likely be building something that interfaces at the z machine level.
82 more comments available on Hacker News