Microsoft makes Zork open-source

https://en.wikipedia.org/wiki/MDL_(programming_language)

  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).

('ADVENT' is https://en.wikipedia.org/wiki/Colossal_Cave_Adventure , for anyone who isn't familar.)

https://the-rosebush.com/2025/07/studies-of-zil-part-2-how-d...

It was public already, what they are doing here is open sourcing the code.

https://mordenstar.com/zork

MC Frontalot - It Is Pitch Dark

https://www.youtube.com/watch?v=4nigRT2KmCE

Featuring Steve Meretzky!

https://en.wikipedia.org/wiki/Steve_Meretzky

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.

DECUS fortran version: https://www.ifarchive.org/if-archive/games/source/dungeon-3....

f77 version for Unix: https://github.com/videogamepreservation/zork-fortran

(GNU fortran port: https://github.com/GOFAI/dungeon)

f2c translation (basis of many versions): https://github.com/devshane/zork

(See README for history of this version)

But the older version has a "Tomb of the Unknown Implementor," which this new version seems to lack.

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).

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.

"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.)

I could see this being important here in two ways:

1. If the source code of Zork has not been made available to the public before, then now is the year of publication.

2. If Zork source code has previously been made available to the public, perhaps the version published here has had changes made, in which case now is the year of publication of this version of the source code.

I assume that when Microsoft opens source code they have a team of lawyers that have solid legal arguments for what the copyright year should be in each case.

Therefore, maybe it’s even possible legally that

3. Even if source code was previously made available, and even if no changes were made in any way since then to any of the included source code or other files, perhaps just the act of using a different license is in its own way part of how copyright applies. Publishing something under a specific license in $CURRENT_YEAR does not retroactively make the license apply before the time at which it was made available under that license and so perhaps an argument could be made that copyright year in a license includes taking that into consideration.

(the grue would obviously just a picture full of black, though some creepy eyes would be a nice touch)

https://dzlab.github.io/notebooks/flax/vision/diffusion/2023...

It really depends on the creator. A slop is a side effect of the fact that the entry barrier has been much lowered. Previously you at least had to put some effort into learning the craft before showing that to the world.

[1] https://www.mobygames.com/game/28812/time-and-magik-the-tril...

It's more a gimmick than anything particularly useful. Might even distract if the image embellishes from the original description leading players down the wrong path for solving a puzzle.

Speaking of porting I have always vaguely wanted to port the original basic version of ultima, I mean never enough to actually do it, but I like the idea of the source being available to do so. even if it is just an accidental artifact of how it was made.

> Basic Information on the Contents of This Repository > > It is mostly important to note that there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file using an official Infocom-built compiler. There is a user-maintained compiler named ZILF that has been shown to successfully compile these .ZIL files with minor issues. There are .ZIP files in some of the Infocom Source Code repositories but they were there as of final spin-down of the Infocom Drive and the means to create them is currently lost. > > ... > > In general, Infocom games were created by taking previous Infocom source code, copying the directory, and making changes until the game worked the way the current Implementor needed. Structure, therefore, tended to follow from game to game and may or may not accurately reflect the actual function of the code.

Although I haven't played with it and can't tell you whether it can compile the open source Zork.

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.

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.

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

You made my day

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.)

Ah, and yes, IF6 ports for Adventure do exist, both in English and Spanish, and the Spanish one it's really great, with even the backstory on creating the game perfectly translated..

I'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.

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.

See: https://news.ycombinator.com/item?id=45996035

https://www.hanselman.com/blog/ipad-surface-ultrabook-are-we...