When I was 14 or so, in the early 1980s, a friend and I who had been playing Zork thought it would be fun to design a game ourselves. We actually wrote to Infocom with a proposal that we write a new game for them and they let us use ZIL and the Z-machine to implement it. Surprisingly, they actually wrote back to us and politely declined our offer. In hindsight, while we knew how to program in BASIC and assembly language on our Apple IIs, we would have been lost making a game with ZIL. That’s to say that Infocom made the right call. Still, it said something about the company that they treated a couple kids with respect and didn’t laugh in our faces. I wish I still had the letter.
My goodness, I could have written this word-for-word. Similar age, same Apple II BASIC and 6502 upbringing (roll sleeves and call -151) and also wrote to Infocom. We were in the UK so even more surprised to get a reply similar to yours several weeks later. Sadly my letter is also lost to various house moves. Or eaten by a grue.
Me too, except my letter was to Sierra On-Line and my experience was on TRS-80 6809. Really classy reply asking me to write back when I finished school.
I recall sending a letter to them asking them for information on how they compressed their images for their hi-res adventure games. While they replied, they said it was a trade secret. I was kind of bummed. But being a 12 year old kid who barely understood the 6502, it probably would have gone over my head.
Lovely to hear this about Infocom and SOL. The former was my obsession throughout the mid-late 80s on my Atari 800XL, and then the latter for the next few years after getting a 386SX in '89.
In the 1980s, I was interested in text adventure games, and had a kind of book/magazine on the topic of how to write them. In BASIC, obviously (groan) because that's what was easily accessible back then.
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.
Nice. Yep, we wrote our own adventure games in BASIC as well. There were a couple problems with that, however. First we weren’t able to come up with a sophisticated parser like Infocom had. We ended up with basic “verb object” parsers, ala Scott Adams adventures. Second, we didn’t have many rooms as it was difficult to fit it all into memory and we didn’t have the sophisticated incremental loading that Infocom did with the Z-machine. Still, it worked.
When I was around six years old, my older brothers convinced me computer games were written in paragraph form. I wrote a lot of games! Asteroids went something like this, "You fly around in a ship that is a triangle. When you shoot asteroids they break up into smaller asteroids."
My brothers got a lot of laughs out of those "programs".
Wrote a mini adventure game in BASIC for the ZX-81. Since it only had 1K of RAM, each room in the game had to be a separate program (max around 25 lines of code or so), and at the end of the room, depending on what actions you took, it asked you to wind the cassette tape to a specific location to load a new room. When I could finally afford the 16K RAM pack, I rewrote it as a single application. Couldn't believe how nice it was to have that much memory.
> it asked you to wind the cassette tape to a specific location to load a new room.
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.
I iterated on adventure games from junior high into high school, starting with a TRS-80 Model III.
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.)
Writing a terrible "verb object" parser in BASIC was certainly a rite of passage for many of us. I recall making more than one. I also recall my best one having rudimentary "verb object preposition subject" support, but that being about my limit at the time in BASIC.
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).
That's really nice. I remember when I was 8 or so, I phoned up NASA and told them I'd drawn up plans for a spaceship. The lady on the phone sweetly took me very seriously and asked questions about where such a thing would launch (answer: any big airport). She encouraged me to send them in.
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.
'as a kid I....' Man. This brings back memories. I got into the BBS world and started programming in earnest because I wanted to write shells for the MUDs out at the time. A friend and I built some amazing things all in the name of auto-mapping, adding graphics, etc etc. Simple games really help confine a problem to the point that you can grow your curiosity easily with them.
This literally gave me goosebumps. It's hard to convey how much Zork (and the rest of the Infocom portfolio) means to me. This was my first entry into gaming on my Commodore 64.
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.
I've seen a few things called 'Zork source code' in various places over the years (even on a CD that came with a game programming book of some sort), and copies like this:
Zork was originally written at MIT for PDP-10s in an obscure Lisp dialect (MDL). The authors then later formed a company to sell the game on micro-computers. To do it, they built a virtual machine optimized for this purpose, a new Lisp dialect (ZIL) that could compile to the virtual machine, and the ported the game over to that new dialect. Even so, they had to split the game into three parts to fit.
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.
MDL was a dialect of lisp invented by/in part/under Sussman, the originator of Scheme and SICP; what you're calling an obscure dialect was was part of the continuum of a research trajectory, one of a number of experimental languages designed to test out ideas. Sussman got his PhD in 1973 so we're talking about his later work as a student/early work as a postdoc/assistant professor, and Abelson was in the same timeframe, and Guy Steele a half decade junior, and many others in the lab whose names you would also recognize.
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.
> 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.
Can you elaborate on this? The examples from the PFF suggest it's just the usual lispy type declarations.
You're kind of in luck. For a while, it was trendy (because MIT was doing it) to teach Intro to Programming with Lisps, especially Scheme. Because of this, there are quite a few "learn programming with Lisp" books and resources. The famous "SICP" book was the textbook for the MIT course and all of the examples were Lisp (there's a newer version that uses JavaScript, I think). There are loads of fine online books and guides. Here's a random online book: https://gigamonkeys.com/book/
In no time you'll be putting up "my other car is a cdr" bumper stickers!
> 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... ;-)
Everyone's recommending books; I'm going to do the opposite and recommend a specific dialect.
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.
I should mention that you really do want good editor support with any dialect of Lisp, because having to balance parentheses by hand gets old fast. You want an editor where you can have keybindings for "pull this space-delimited item out of the current parentheses and stick it into the parent set of parentheses" and all the other operations that are extremely common in Lisp. Also, smart auto-indenting is absolutely essential in order to produce readable Lisp code. You need things lined up correctly if you want to be able to read the code without resorting to counting closing parens. This is why so many people use Emacs, because it was designed for Lisp from the ground up. But I never liked its Ctrl+Shift+Meta+key shortcut methods, hence why I'm recommending Vim.
Emacs does have one advantage over Vim when it comes to Lisp, though, which is that it almost certainly comes with Lisp-related keybindings already ready to go. And also that its config files are written in Lisp, so if you're using Emacs then you're already reading and writing Lisp code just to configure it. Two. Two advantages. Oh, and fanatical devotion to the Pope ^W^W Richard Stallman. Three advantages... I'll come in again.
In Grad School I started with an "AI in Lisp Textbook" (which was still the most common at the time in the late oughts, I hear many have moved to Python since) and searched for a Common Lisp interpreter that felt right. I think I ended up with SBCL [0], but this was obviously a while back so my memory is slippery about it.
(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.)
Zork was originally a public-domain mainframe game called Dungeon developed at MIT. Its authors founded Infocom, split the game into 3 pieces, added more content, and released it for microcomputers as the 3 Zork games. The source code that's been floating around since the 80s is for the original Dungeon game. Between the early 80s and the early 90s, the source was translated from MDL to DEC FORTRAN to Unix f77 to C, so you can find a variety of copies of the source at different steps of that translation process. This is also why the C version doesn't look like idiomatic C code.
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).
i'm not a complete expert on this, but the dates entailed here trigger clear memories.
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.
Good question, I'm also curious. A quick search shows that there are some differences. The one in this new historicalsources folder has the PLUGH easter egg, but the other one doesn't seem to have it.
But the older version has a "Tomb of the Unknown Implementor," which this new version seems to lack.
You're one of today's lucky 10,000. It was huge news at the time. The FTC considered not allowing it and the acquisition got delayed for months while back and forth public debate raged.
Easy to forget all the big moves that happened recently, especially since there haven't been (afaict) any major changes to service. I forgot the other day that Sony had bought Bungie, though it'd be pretty memorable if Sony announced Destiny 3 as a PS5 timed exclusive.
Massive media/telecom/tech companies get passed around between other massive media/telecom/tech companies so much that regardless of how much you saw the news at the time, a couple of years later it's tough to remember "Now who is it that owns Warner Bros. currently? AOL? AT&T? Netflix? The sovereign wealth fund of Saudi Arabia?"
And Sierra. It would be amazing if MS released the source code to some of Sierra classic Hi-Res/AGI/SCI games, or the engines themselves.
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.
The repository is part of https://github.com/historicalsource, which has code for a bunch of Infocom games, although at a quick glance most of them aren't open sourced. Still, very cool resource.
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.
Ditto here. And, better, translated into Spanish with INFSP6. There is one made from a non-native Spanish speaker and it's really bad.
Now a proper Zork translation can be a reality.
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..
it's pretty grim that this announcement, which is in part celebrating the legacy of an incredible artistic endeavor, was written by an LLM. reading this feels like my head is continuously being bashed in by a brick.
> When Zork arrived, it didn’t just ask players to win; it asked them to imagine. There were no graphics, no joystick, and no soundtrack, only words on a screen and the player’s curiosity. Yet those words built worlds more vivid than most games of their time. What made that possible wasn’t just clever writing, it was clever engineering.
Yes. Because it is pitch black and therefore you can not determine it's color (plus, the fact that you haven't been eaten by one yet does not justify the conclusion that you won't be). It's also a play on Gardener's "unexpected hanging paradox".
The writing should be assumed to be subject to copyright still even though the code is open source.
In this case it sounds like Microsoft's Legal has taken the assumption the writing is applicable under the code license and is mostly seeking to enforce trademarks and brand (don't commercially release something implying it is a Microsoft-approved Zork) more than the writing, per Scott's wording of Microsoft's legal requests here: https://github.com/historicalsource/zork1/pull/3
Obviously, I'm not a lawyer, that's not legal advice, build commercial derivatives at your own risk and with your own lawyer's advice.
In many ways it's the opposite, the code counts as writing. At least where I live (should be similar in other EU countries) from the perspective of copyright law code is largely classified as literary work. There are few special rules related to fact that code is typically written by large team employed by company compared to books being written by single author and printed by publisher. Also few special rules that don't make sense for regular literary works related to reverse engineering, interface compatibility with other software and copying as part of installation/execution process.
All the code specific licenses are arbitrary rules decided by right owners under which they license others to use their work. Book authors typically don't have to worry whether when granting permission to read their work they also need to grant rights to relevant patents, or whether dynamic or static linking should be permitted.
Assuming Microsoft owns all the necessary rights for everything I don't see a major reason they couldn't release it as single work under whatever license they want. Considering the way this specific game is written I don't think you can even cleanly separate code from rest of the writing. It's all one big program with bunch of short string literals sprinkled all over the place. You could take all the string literals, but without code defining how those strings are ordered in a non linear and interactive way it would make as much sense as reading a book where all the sentences have been sorted in alphabetical order.
I doubt any of the Zork authors were part of writer union and negotiated separate licensing rules for the text they wrote.
With regards to common case where source is released with open source license separate from art assets there are a couple of reasons. It's much easier to separate pictures and music from code and tell that those are covered by different license. For some of the art assets especially music it's not uncommon that the publisher themselves don't have full rights to them and only have limited license to use in game but not to relicense as separate works. Releasing source code without art assets makes it easier to maintain commercial value and limit ability for others to exploit the work as ready to use product (or sequals) while still allowing programmers to study the code and learn from the technical tricks in code or making new games based on same engine. If I am not mistaken at
From the historical preservation perspective art assets are less likely to bitrot and become unusable. 20 years in future you will likely still be able to rip them out of commercial builds of game with little losses and worst case observable as standalone media. But the code is a lot more likely break and not be runnable on future OS/hardware. Code also has a lot more hidden aspects that you can much more easily observe by reading source code directly instead of reverse engineering the compiled executables. Better release the source code while it hasn't been completely lost.
Funnily enough you can easily find the Windows XP source code on GitHub. Not endorsed by Microsoft of course, but they've ignored it sitting on their own service for years, along with ignoring all the modern Windows and Office piracy tools which are also on GitHub. Microsoft works in mysterious ways.
If AGI ever comes close to fruition I can't wait to just dump this code into some AI, tell it to fix all security bugs and make it work on M Series processors. Would finally achieve a computing environment that would be perfect for me. Until then, I will continue to dream.
If we ever get to the point of having a tool that could do something that complex, we're well past the point of using human-written operating systems or using M-series processors.
Hmm I seem to recall Karpathy talk about the next era of software being like this: Essentially everything is made on demand exactly the way the user expects or something like that. it would definitely be a paradigm shift that requires rethinking how we approach software.
What do we really need? If you look at what Ai can solve today, smaller problems seem to be solved really well by AI. So just an AI with a large enough context, adequate speed to made the changes in near real time and a reasoning ability that can better handle problems vs whats available today might be adequate to realize this relality in some way.
I suspect this question would be asked different ways depending on the historical context of the user. I grew up using Windows XP, dabbled in using ReactOS maybe once or twice, saw that didn't meet my needs when I tried it, and then proceeded to not really spend anymore time thinking about it.
I think it would be safe for Microsoft to release (intentionally or unintentionally) the source for just about any product. I bet it's incredibly difficult to run a successful build. From talking to someone who used to work on Excel, it took them around 1 day to build Excel from source. And that's if everything goes perfectly and you know exactly what you're doing and are using the build system and setup and configuration that the Excel team has in place.
People have built working operating systems from both the XP/Server 2003 and NT 4 leaks. Here's someone building Server 2003 on Windows 11: https://www.youtube.com/watch?v=AWZe00v2Rs0
> along with ignoring all the modern Windows and Office piracy tools which are also on GitHub
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.
They are not this cynical over it, it's part of a plan. What they figure is that they can keep MS the de-facto standard this way. Photoshop worked the same way for very long.
Most of the money to be made is by licensing software to organisations that can afford the risk of pirating (practically anything bigger than SMBs: enterprises, governments, armies, etc). The moat of everyone used to your platform worths a lot more. So they just regulate enough so it won’t seem like they don’t give a shit at all.
This is exactly the kind of thing Microsoft likes to opensource: old, crusty, and obsolete. Let's compare. When ID Software opensourced Doom a few years after it's initial release, there was still some life in it and it spawned a myriad of forks and new developments continuing to this day. An active community formed around it. When Microsoft opensourced MSDOS, an opensource clone had existed for so long it was only of interrest to archeologists and historians. It was as whitered and lifeless as Zork is.
learn what? how to print text to stdout? how to do if else statements or math.random? I'm sure you can rewrite this in a week or in a month from scratch. Next, Microsoft will opensource notepad because there are 0 text editors out there. It is 1960 after all.
If I'm reading this right, the source code has been available for all the Infocom games in https://github.com/historicalsource for at least six years, but what's changed today is the license?
How did Microsoft get to own it in the first place? And the original MDL version of Zork has been around forever. I wonder if Microsoft has any of the other Infocom games and might release them too.
And, "A game that changed how we think about play"? Um, that was ADVENTURE. Zork was arguably better, but it was in the same vein, and later.
I was in a small room with two paper terminals in 1979 where I discovered ADVENT and DUNGEO at the same time. Maybe there was a distinct separation for a few college students, but for most people they “came out” at the same time.
I have an original line printer printout of 1970s "Adventure" (translated from Fortran into C for UIUC's CAC PDP-11/70 running UNIX v7.) Adventure is the father of Zork. Zork is a clone of Adventure.
Yeah. I had to walk down memory lane to try to remember who bought whom as well. I completely forgot that Activision/Blizzard is a subsidiary of Microsoft Gaming these days.
So how good are the latest coding agents? Like if I asked Gemini 3/Claude/ChatGPT 5.1 to convert it into something that could run from a Python interpreter, how far would they get? (I assume Zork Implementation Language is not well represented in the training corpus)
The easiest way to get it to run from a Python interpreter would be to compile the ZIL source to a Z-Machine binary, which you can do with ZILF [1], then use a Z Machine library in Python (such as a pure Python implementation of the Z-Machine [2]) to load/run it.
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.)
I’m curious why they chose MDL rather than Lisp for it. Sure, it would have been ancient MACLISP or whatever, but why not leverage what was already in wide use at MIT at the time?
MDL is what was in wide use at MIT at the time, the PDP-10 era. The M in MDL is sometimes "MIT" in the various backronyms of what it stood for. (Mostly it was apparently just short for "muddle", a self-deprecating description.)
(Also, to be technically correct, these source files aren't even MDL, they are a further descendant called ZIL [Zork Implementation Language].)
MDL is also from MIT and supposedly stood for More Datatypes than Lisp. According to wikipedia "MDL provides several enhancements to classic Lisp. It supports several built-in data types, including lists, strings and arrays, and user-defined data types. It offers multithreaded expression evaluation and coroutines."
Seems that most of it's novelties were eventually added into LISP proper.
Because Zork was written on the MIT Dynamic Modeling PDP-10. MDL was an important part of the software ecosystem on that computer, but Lisp wasn't. On the other MIT PDP-10 computers, Maclisp reined.
It’s very Lispy, but it’s not strictly Lisp. Why, for instance, use “<“ and “>” to surround various forms but not others? If they were to make a mini-Lisp, I’d expect something more like Gnu Emacs Lisp, something that’s obviously a Lisp, but heavily influenced by the Lisps of the day. I’ve found a few old MDL manuals linked from Wikipedia, but none of them have any sort of “Here’s why we created MDL” section that I could find.
The copyright on the whole collection is 2025 - which is likely just the README or some such thing. Some of the parts are copyright 1977. For works created after 1978 copyright would last from year of first publication + 90 years, but since most of this is written in/before 1977 different laws apply. (I suspect that Activation was careful to ensure they keep their registration up to date, but there is a slight possibility this is all public domain anyway if you want to hire a lawyer to check)
IANAL but copyright is typically the year of first publication.
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.
> IANAL but copyright is typically the year of first publication.
Under current copyright law, copyright is effective from the moment the work is first set in fixed form, though I think copyright used to be based on first publication.
Updates creates a new work, for which the copyright date is that of the updated work being completed (which doesn't change that some parts are also part of works copyrighted earlier and which may enter the public domain earlier.)
Perhaps this is a stupid/contentious idea (partly because it somewhat kills the "spirit" of the original games), but there's a little part of me that would be interested in seeing the scene building parts of Zork piped into an image generation service to visualize the landscape that the game describes.
(the grue would obviously just a picture full of black, though some creepy eyes would be a nice touch)
It seems likely that the entirety of Zork (world state and the possible actions to transform it) is already learned by the model. Which means that there is a grue in there, too. Not good. I’m starting to re-think the doomer argument...
I would love to see the Apple ][ source code made available for a lot of these classic games. In this case what I really want to see is the Z-Engine or interpreter itself not essentially the data files only.
The source code for most of Infocom's Z-code interpreters (including the Apple version) is available here: https://github.com/erkyrath/infocom-zcode-terps . Note that this isn't an official licensed release so it's in a legal gray area. It would be nice to see Microsoft bless these with an official license as well.
I have seen some of the interpreter source codes, but I don't know if they have been "officially" published. These also include some other things such as test files, and a picture file that I have never seen a decoder for (other than the decoder (and encoder) that I wrote myself).
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.)
That is the exactly the suggested compiler in this blog post. (These repos have been compiled with it for a while. The biggest change in these [Internet Archive-uploaded] repos is an official Microsoft-backed MIT License as opposed to assuming Fair Use for Archival Use prior to now.)
I'm hoping Microsoft may have a chance to open source more of the original Infocom compilers and VMs, even if they would be hard to run on modern machines, in later expansions of these repos.
bummer
> The code relies on old internal Infocom toolchains (ZILCH compiler, WATFOR,
> mainframe environment) that are not open and likely not preserved.
I hope some of those other Infocom tools eventually get open sourced for historic curiosity, but ZILF is probably going to remain the modern answer for how to compile these files.
How bad is it? I mean you have the source, it could be ported. Or am I completely misunderstanding and you specifically want the old toolchains, in which case A respectful moment of silence for compilers lost.
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.
The others don't seem to have the MIT license pullreq added, so they are not open source; the source code is merely available. The repos have a note:
"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.)
Yeah the code was leaked without Activision's permission a few years ago. It's strange to me that Microsoft has taken this opportunity to clear up the rights to Zork 1-3 but not to the rest of the Infocom back catalog. The other games haven't been available for sale since the mid 90s when Activision put out a shovelware CD collection containing every Infocom game except Hitchhiker's and Shogun, so it's not like they have much commercial value.
> It's strange to me that Microsoft has taken this opportunity to clear up the rights to Zork 1-3 but not to the rest of the Infocom back catalog.
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.
The BBC probably has a say in if that game will be open source. (Their multi-decade effort at making the game free to play and being open about some of their enhancements to it suggests they may be willing to help with that, and Microsoft making the first move with Zork 1/2/3 may help with any interest there.)
The rights to Hitchhiker's and Shogun reverted to their credited authors (Douglas Adams and James Clavell) after they went out of print. The rest of the Infocom library was created as works for hire entirely by salaried Infocom employees, so the rights went from Infocom to Activision to Microsoft.
Right, which is why I assume the BBC has the entire rights today to Hitchhiker's and was gifted them by Douglas Adams' estate, but my searches didn't turn up enough evidence to back that assumption so I didn't include it, but I feel rather sure of it. (ETA: Related to the chain of how the BBC wound up owning was left of the H2G2 wiki for a time before spinning that back out to different owners.)
I bought a version for the mac (OSX), which I managed to get moved from 800k floppy to my network drive. The games are still on my NAS today and play just fine. Still fun to play, someday I hope to find time to solve them. I keep the originals so should even be legal.
The notable change is that most of those repos have been available not as a open source but "source available" as Fair Use (for Archival Purposes), but the copyright owner (Microsoft today) has now directly applied the MIT License to three of those repos (Zork 1/2/3). Hopefully they will apply it to more of them as Microsoft legal allows, but it's still exciting they've made three repos officially open source under a FLOSS recognized license.
Great, I remember a page which stated that it was sad to have free as in freedom ZMachine languages and interpreters (Inform6, Frotz/Fizmo...) but there were very few text adventures under a libre license. So far, the most known ones:
I know, I play IF games since 2001 and 2002; and my previous gameplays where with the classical ones for ZX Spectrum (in Spanish) and some freeware games bundled with 'shareware' CD's with Winfrotz and later Frotz/NFrotz.
Some GNU user used to have several under libre licenses (even non-ZMachine ones), such as Beyond the Titanic, but he has no working repos any more.
There's also Frotz and other Z Machine interpreters, and the actual Zblorb game file. But I guess this would be the source code that compiles to the zblorb.
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.
This is the source code to the original, non-commercial version of Zork that originated at MIT. Microsoft has now released the source code for the Infocom's commercial release for microcomputers.
Dang. I had forgotten Zenimax got scooped up by MSFT Gaming a few years back. It's not an unreasonable request, though I suspect it should be made directly to MSFT Gaming.
By number of acquired studios, Microsoft is one of the biggest publishers, hence even if XBox the console goes bust, they still have a big weight as Microsoft Game Studios and XBox brand.
The cynic in me believes that this only took place after numerous meetings during which the question "is there any way we can still make money from this" was repeatedly answered with "no".
I wonder how long before someone hooks up AI image generation for the scenes with this. It could either be very tastefully done or complete slop. Probably the second option.
There have been a couple attempts at this kind of thing (same with AI generation of images from pages of Choose-Your-Own-Adventure books).
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.
In the early days of LLMs I tried it, but it was kinda terrible, and I also realised that the fun of these games, like reading a book, was the imagining of the action. Take that away and they are very simple puzzle games
There was a game I remember from the 80s that had such a (to me) tasteful background of still images to go with the text adventure; Time and Magik trilogy on Atari ST. [1]
> It could either be very tastefully done or complete slop.
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.
I kinda hate that Microsoft gets to take credit for being magnanimous with yet another product they never created.
The TL;DR: The Zorks were created by several guys at MIT who later formed Infocom. Infocom eventually sold to Activision, Microsoft bought Activision and voila--"Microsoft is open sourcing Zork".
Whenever I use LLM-generated content, I get another LLM and pre-bias it by asking if it's familiar with common complaints about LLM generated content. And then I ask it to review the content and ask for it to identify those patterns in the content and rewrite it to avoid those. And only after that do I bother to give it a first read. That clearly didn't happen here. Current LLM models can produce much better content than this if you do that.
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.
My brothers got a lot of laughs out of those "programs".
Fast-forward 45 years and whose laughing now?! :)
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.
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.)
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).
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.
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.
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.
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.
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... ;-)
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.
Emacs does have one advantage over Vim when it comes to Lisp, though, which is that it almost certainly comes with Lisp-related keybindings already ready to go. And also that its config files are written in Lisp, so if you're using Emacs then you're already reading and writing Lisp code just to configure it. Two. Two advantages. Oh, and fanatical devotion to the Pope ^W^W Richard Stallman. Three advantages... I'll come in again.
https://www.cs.cmu.edu/~dst/LispBook/book.pdf
(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/
This is the version i read:
https://www.abebooks.com/9780023397639/Little-LISPer-Third-E...
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)
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.
But the older version has a "Tomb of the Unknown Implementor," which this new version seems to lack.
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.
> docker run -it clockworksoul/zork1
You made my day
https://github.com/clockworksoul/docker-zork2
https://github.com/clockworksoul/docker-zork3
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..
https://www.hanselman.com/blog/ipad-surface-ultrabook-are-we...
Check out wikipedia's "signs of ai generated writing". Every sentence here is represented in that post. "Not just x, but y." "No x, no y, no x, just abc". https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing
Literally the first sentence.
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
Is there something similar for a text based adventure game? Does the writing count as code?
In this case it sounds like Microsoft's Legal has taken the assumption the writing is applicable under the code license and is mostly seeking to enforce trademarks and brand (don't commercially release something implying it is a Microsoft-approved Zork) more than the writing, per Scott's wording of Microsoft's legal requests here: https://github.com/historicalsource/zork1/pull/3
Obviously, I'm not a lawyer, that's not legal advice, build commercial derivatives at your own risk and with your own lawyer's advice.
All the code specific licenses are arbitrary rules decided by right owners under which they license others to use their work. Book authors typically don't have to worry whether when granting permission to read their work they also need to grant rights to relevant patents, or whether dynamic or static linking should be permitted.
Assuming Microsoft owns all the necessary rights for everything I don't see a major reason they couldn't release it as single work under whatever license they want. Considering the way this specific game is written I don't think you can even cleanly separate code from rest of the writing. It's all one big program with bunch of short string literals sprinkled all over the place. You could take all the string literals, but without code defining how those strings are ordered in a non linear and interactive way it would make as much sense as reading a book where all the sentences have been sorted in alphabetical order.
I doubt any of the Zork authors were part of writer union and negotiated separate licensing rules for the text they wrote.
With regards to common case where source is released with open source license separate from art assets there are a couple of reasons. It's much easier to separate pictures and music from code and tell that those are covered by different license. For some of the art assets especially music it's not uncommon that the publisher themselves don't have full rights to them and only have limited license to use in game but not to relicense as separate works. Releasing source code without art assets makes it easier to maintain commercial value and limit ability for others to exploit the work as ready to use product (or sequals) while still allowing programmers to study the code and learn from the technical tricks in code or making new games based on same engine. If I am not mistaken at
From the historical preservation perspective art assets are less likely to bitrot and become unusable. 20 years in future you will likely still be able to rip them out of commercial builds of game with little losses and worst case observable as standalone media. But the code is a lot more likely break and not be runnable on future OS/hardware. Code also has a lot more hidden aspects that you can much more easily observe by reading source code directly instead of reverse engineering the compiled executables. Better release the source code while it hasn't been completely lost.
Which is to say, very, very, very far away.
What do we really need? If you look at what Ai can solve today, smaller problems seem to be solved really well by AI. So just an AI with a large enough context, adequate speed to made the changes in near real time and a reasoning ability that can better handle problems vs whats available today might be adequate to realize this relality in some way.
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.
157k stars
No-one buys Windows. No-one buys Office. It's a thing that comes bundled with a computer, or that you "acquire" if you need it.
It's only interesting if Barclays are pirating Windows on a massive scale.
Oh shit did I say the name out loud?
And, "A game that changed how we think about play"? Um, that was ADVENTURE. Zork was arguably better, but it was in the same vein, and later.
See: https://news.ycombinator.com/item?id=45996035
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
https://notabug.org/coderain/zilutils
EDIT: Wrong link. Wait, I'm sure there's a C based alternative out there.
---
<ROUTINE V-ADVENT ()
https://en.wikipedia.org/wiki/MDL_(programming_language)
(Also, to be technically correct, these source files aren't even MDL, they are a further descendant called ZIL [Zork Implementation Language].)
Seems that most of it's novelties were eventually added into LISP proper.
('ADVENT' is https://en.wikipedia.org/wiki/Colossal_Cave_Adventure , for anyone who isn't familar.)
http://literateprogramming.com/adventure.pdf
https://the-rosebush.com/2025/07/studies-of-zil-part-2-how-d...
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.
Under current copyright law, copyright is effective from the moment the work is first set in fixed form, though I think copyright used to be based on first publication.
Updates creates a new work, for which the copyright date is that of the updated work being completed (which doesn't change that some parts are also part of works copyrighted earlier and which may enter the public domain earlier.)
(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...
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.)
https://zilf.io/
I'm hoping Microsoft may have a chance to open source more of the original Infocom compilers and VMs, even if they would be hard to run on modern machines, in later expansions of these repos.
And there's no way to turn it off for one app.
And if I turn it off, I can only turn it back on by re-installing Windows.
What the bloody...
So now I want to download and build.
But it's .net 10, so I apparently need VS 2026, which I hadn't bothered to install yet.
Oh my.
Although I haven't played with it and can't tell you whether it can compile the open source Zork.
I hope some of those other Infocom tools eventually get open sourced for historic curiosity, but ZILF is probably going to remain the modern answer for how to compile these files.
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.
"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.
In at least one of the above mentioned cases, we do know that the current rights holder and/or most recent licensee appears to be the BBC: https://www.bbc.co.uk/programmes/articles/1g84m0sXpnNCv84GpN...
The BBC probably has a say in if that game will be open source. (Their multi-decade effort at making the game free to play and being open about some of their enhancements to it suggests they may be willing to help with that, and Microsoft making the first move with Zork 1/2/3 may help with any interest there.)
- Spiritwrak
- All Things Devour
- Calypso
- Tristam Island
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.
It was public already, what they are doing here is open sourcing the code.
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.
https://dzlab.github.io/notebooks/flax/vision/diffusion/2023...
[1] https://www.mobygames.com/game/28812/time-and-magik-the-tril...
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.
The TL;DR: The Zorks were created by several guys at MIT who later formed Infocom. Infocom eventually sold to Activision, Microsoft bought Activision and voila--"Microsoft is open sourcing Zork".
Sigh… it’s all ChatGPT nowadays ain’t it.
Still, pretty cool; I remember playing work as a kid.