Tuesday, April 16, 2019

All of Infocom's game source code

I can just leave that statement there, right? I don't have to elaborate? Jason describes it better than I could, anyhow:
So, Infocom source code is now uploaded to Github. Most people don't speak or want to speak the language it's written in, ZIL (Zork Implementation Language). You can browse through it and kind of suss out what's being done when and the choices made over the course of time.
In cases where the source code had multiple revisions, and I don't know the story of what revisions came when and came why, I did a reasonable job of layering them out (this came before that, that came after that) and doing multiple "check-ins" of the code so you can see diffs.
Often, there are cases that some games were built up from a previous game, allowing modification of the macros and structures and then making them work in the new game. For example, an NPC partygoer in one game was a thief in a previous one. Dungeons become stores, etc.
--@textfiles (Jason Scott), from a twitter thread
This material has been kicking around for a while now. If you search for articles about "the Infocom drive", you'll see some discussion from years past. Actually, don't do that, it's mostly old arguments that don't need to be rehashed.
The point is that a great deal of historical information about Infocom has been preserved -- but it's not publicly archived. You can't go research it anywhere. Nobody admits to having it, because it's "proprietary IP", and you're not supposed to trade in that stuff because companies like Activision make the rules.
So when Jason puts this information online, he's taking a stance. The stance is: history matters. Copyright is a balance between the rights of the owner to profit and the rights of the public to investigate, discuss, and increase the sphere of culture. Sometimes the balance needs a kick.
Quite possibly all these repositories will be served with takedown requests tomorrow. I'm downloading local copies for myself tonight, just in case.
One other note: Jason's comments say "...there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file." This is somewhat out of date. There are long-standing open-source efforts to build a ZIL compiler. ZILF is the most advanced one that I know of. I don't know whether it's rated to compile this historical ZIL code -- but I'm sure that people are already giving it a shot.

12 comments:

  1. I had a conversation with Jason years ago about "the Infocom Drive" and releasing the source code. So glad to see it has finally happened.

    ReplyDelete
  2. ZILF throws a few warnings, but...

    $ mono ../bin/zilf.exe zork1.zil
    ZILF 0.8 built 3/19/2017 12:34:17 AM
    Renovated ZORK I: The Great Underground Empire
    [warning MDL0417] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/GCLOCK.zil:31: ROUTINE: only 3 routine arguments allowed in V3, so last 2 "OPT" arguments will never be passed
    in INSERT-FILE called at zork1.zil:19
    in IFILE called at zork1.zil:41
    [warning ZIL0504] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/GPARSER.zil:229: treating SET to 0 as true here
    [warning ZIL0505] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/1ACTIONS.zil:2484: COND: clauses after else part will never be evaluated
    [warning ZIL0502] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/1ACTIONS.zil:3283: RETURN value ignored: block is in void context
    4 warnings
    $ mono ../bin/zapf.exe zork1.zap
    ZAPF 0.8
    Reading zork1.zap
    Reading zork1_freq.zap
    Reading zork1_data.zap
    Reading zork1_str.zap
    Measuring..
    Assembling
    Wrote 94664 bytes to zork1.z3
    $ frotz zork1.z3
    ZORK I: The Great Underground Empire
    Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved.
    ZORK is a registered trademark of Infocom, Inc.
    Revision 0 / Serial number 190416
    West of House
    You are standing in an open field west of a white house, with a boarded front
    door.
    There is a small mailbox here.
    >$ve
    Verifying disk...
    The disk is correct.
    >

    ReplyDelete
  3. You're welcome, guys. At least I'm in a place where I can cop to it now.

    ReplyDelete
  4. I strongly maintain a Z-code interpreter must be (re)written for the PDP-10.

    ReplyDelete
  5. Thanks for doing the ZILF test! But does ZILF compile the source into the same binary as Infocom shipped? That's the next question.

    ReplyDelete
    Replies
    1. It appears to be functionally close but it's not identical.

      Delete
    2. The next level test would likely be easiest to generate some ZAP assembly and compare it to some of the files that have survived in the old Infocom development directories.

      Of the form...

      .FUNCT INSIDE-GATE-F,RARG
      EQUAL? RARG,M-ENTER \?ELS5
      ZERO? CASTLE-ENTER \?ELS5
      SET 'CASTLE-ENTER,1
      PRINTI "As you pass through the gate, you feel that your mind is being probed. After a moment, it is released or, perhaps, discarded as uninteresting."
      CRLF
      CRLF
      RTRUE

      Delete
    3. That particular trivial fragment looks identical in the output of ZILF (except the specific name of the branch destination - \?ELS5 vs \?L1) but the output side matches up this way...

      $ ls -l
      -rwxrwxrwx@ 1 erd staff 111126 Feb 14 1994 enchanter.zip
      -rw-r--r-- 1 erd staff 125568 Apr 18 00:35 enchanter.z3

      A difference of +13% but I have to admit I was in a bit of a hurry and didn't check my abbreviations on this run. I don't think it's that bad when you use the same *.zxap abbreviation file as the original.

      Delete
    4. Thanks for posting details!

      To be clear, nobody's saying that ZILF *should* produce byte-identical compiled output.

      Looking at the results may tell us something about what kinds of optimization ZILCH used, and (more abstractly) how much Infocom relied on high-level code structures in ZIL vs simple if/and/or game logic.

      Delete
    5. Producing byte-identical output is a non-goal for ZILF. It is a goal for ZAPF, though - we should be able to produce identical output if we have identical assembly code.

      Delete