---v----v----v----v----v---
| _______ |
> One / \ G <
| Lousy / \ U |
> Point | ___ | E <
| | (___) | |
> <--)___(--> P <
| / / \ \ o |
> / / \ \ s <
| |-|---------|-| t |
> | | \ _ / | | a <
| | | --(_)-- | | g |
> | | /| |\ | | e <
| |-|---|_|---|-| |
> \ \__/_\__/ / <
| _/_______\_ |
> | f.m.l.c. | <
| ------------- |
> <
| Donald Woods, Editor |
> Spelunker Today <
| |
---^----^----^----^----^---
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?! :)
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.)
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.
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).
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.
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.
(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.)
This is the version i read:
https://www.abebooks.com/9780023397639/Little-LISPer-Third-E...
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.
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.
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.
> docker run -it clockworksoul/zork1
You made my day
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..
MC Frontalot - It Is Pitch Dark
https://www.youtube.com/watch?v=4nigRT2KmCE
Featuring Steve Meretzky!
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.
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.
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/
https://notabug.org/coderain/zilutils
EDIT: Wrong link. Wait, I'm sure there's a C based alternative out there.
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.
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.)
---
<ROUTINE V-ADVENT ()
<TELL "A hollow voice says \"Fool.\"" CR>>(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.)
There is an enormous stack of line-printer paper here. It is barely
readable and totally unintelligible.
<DEFINE FEEL-FREE (LOSER)
<TELL "FEEL FREE, CHOMPER!">
<MEMQ ......
The rest is, alas, unintelligible (as were the implementers).https://the-rosebush.com/2025/07/studies-of-zil-part-2-how-d...
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'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.
(the grue would obviously just a picture full of black, though some creepy eyes would be a nice touch)
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.
- 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.
Sigh… it’s all ChatGPT nowadays ain’t it.
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".
[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.
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.
Still, pretty cool; I remember playing work as a kid.
"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.)