Not exactly Zork 1. Zork was originally written on MIT mainframes, but when they decided to start Infocom and release the game for profit they couldn't get it all to fit on the personal computers of the time, and so they split it into 3 parts. Zork 2 had the coal mine and the Bank of Zork, I think, and Zork 3 had the endgame. They then added some extra stuff to Zork 2 and 3 that wasn't in the original mainframe version.
The history of the source code is interesting. It was called Zork and written in MDL. At some point they renamed it to Dungeon, but then a little while later named it back to Zork. During the time it was called Dungeon, a DEC engineer logged into their system (open to the world on purpose so people could play the game) but instead of playing the game copied the source code off. Then they translated the game into Fortran so they could run it on PDP-11s. This source code is the descendant of that translation.
reading old C like this, I always wonder how could people code like this back then but apparently it was transpiled from fortran. So I'd assume the original code looked better. I dug around and found it, for comparison here is the original rooms.f vs. rooms.c:
Indeed... as soon as I saw this, I skimmed the (smug towards Lispers!) MDL primer [0] and wrote a few (broken) esrap rules to parse some MDL into Lisp. For example yours gives:
Someone more determined could write a small MDL->CL translator and produce a CL port of Zork (chock full of special declarations, since MDL uses dyamic scoping).
I also found the following interesting remark in the primer: "One of the implementors of Zork has been heard to say that Zork is a huge conditional".
I read parts of the MDL manual. It supported hacks whereby it could shift to using parentheses, as well as evaluation/quoting conventions that are more like Lisp.
Honest question as someone who never got comfortable with Lisp languages. Is the code in parser.mud easy to read. One of those 100 line functions, could you jump to the middle of it and start understanding the meaning as someone familiar with C like languages? Even though I can figure out the syntax it looks like line noise to me but perhaps it is because i've not done much Lisp coding.
I wouldn't call that code easy to read, and that's coming as someone who has actually at some point learned enough MDL to actually know the syntax rather than have to reverse engineer it on the spot. There's a couple of reasons why that code is rough to read today:
- It's doing very complicated operations that operate on mutable global data, and structuring it as huge and deeply nested functions rather than splitting the operations up to smaller chunks with meaningful names. But you'd see exactly the same kind of thing in non-Lisp source code of that era; it's just different sensibilities.
- The code is incredibly heavy on conditionals. Which makes sense given the problem domain: parsing a pseudo-natural language. But MDL is a language where the conditionals kind of suck. COND is basically unreadable in any Lisp, you'd very rarely see people use it today. In CL you'd have more readable options like IF, WHEN and UNLESS. In MDL the only option is misusing short-circuiting AND/OR as a poor man's IF. Which they do in places, which doesn't help readability either.
- The use of angle brackets makes everything look like a sea of less-/greater -than comparisons. At least I just can't help it. It's especially bad when combined with the array indexing syntax.
> COND is basically unreadable in any Lisp, you'd very rarely see people use it today. In CL you'd have more readable options like IF, WHEN and UNLESS.
I wouldn't say "very rarely"; COND is still used for multi-way conditionals. Virtually everyone I know would write:
Indeed, I always thought COND was a construct sorely missing from other languages. Pattern matching is becoming popular for similar uses. I honestly feel it can go over board in many of the same ways though.
As someone very comfortable with Lisp languages: it is hard to read. Initially, the angle brackets do throw me off a bit.
Beyond that, I'd have to read the language manual to make sense of notations like ,foo and .bar.
The code makes a lot of references to non-local names. Someone reading the code would benefit from being familiar with the semantics of what those denote.
What's going on in those functions isn't "rocket science" though.
Pretty sure the fortran was itself a port. My apocryphal memory is that the original is for some custom system, which wikipedia tells me was "MDL". The fortran was the result of it being carried to more common systems.
One of the gnarliest code bases I ever worked in was a very large C project where the inner core had been run through a f2c transpiler. Over the subsequent decade the surrounding code was a hodgepodge of people taking their own interpretations of autogenerated C code because folks didn't question why the code looked the way it did and thus they did their best to maintain the same look and feel. Oh and no one really knew how that original inner core worked, there were no docs, no oral tradition, and it was over 20 years old.
While I was still working there we accumulated enough major change requests to the application that finally got the go ahead to throw the original code base out and start from scratch.
“This code is a forward-port of the Crowther/Woods Adventure 2.5 from
1995, last version in the main line of Colossal Cave Adventure
development written by the original authors. The authors have given
permission and encouragement for this release, it obsolesces all
the 350-point versions and previous 2.x (430-point) ports.”
“What a thrill it was when I first got past the green snake! Clearly the
game was potentially addictive, so I forced myself to stop playing —
reasoning that it was great fun, sure, but traditional computer science
research is great fun too, possibly even more so.”
I wish more people had this attitude to distracting things.
I would be lying if I said this was super easy to read. It is easy, though. Not sure if it is a good exposition for literate programming. I certainly like it, but I think I was predisposed to.
Yeah when reading some of Knuth's literate programs, I get the feeling that they are probably the best possible exposition of programs that are not so good to read. :-) That is, the programs aren't structured modularly like good modern programmers would write (encapsulation, separation of concerns, etc.) — instead they freely use global variables, gotos, etc., in the programming style of the 60s with some of Knuth's idiosyncratic improvements. But given that "bad" program, the one with the globals and the gotos, Knuth's literate programming system produces what is probably the best possible exposition of that program — at least for reading as printed material (on paper not on screen).
I actually have grown to like globals because of this writing style. I'll note that most of what he writes is self contained in the section they are in. However, some things require you to have knowledge of how the system works. You can try and limit this from folks locally, but you wind up having confusing state passing tricks that can, amusingly, lead to bugs.
# On SCO Unix Development System 3.2.2a, the const type qualifier does
# not work correctly when using cc. The following line will cause it
# to not be used and should be uncommented.
Write once, run anywhere provided all the tweaking is done properly. Those were the days.
Neat. compiled right up on my SunOS 4.1.4 machine with only a slight modification (dsub.c had some C++ style comments that the old BSD cc didn't like).
phoenix$ zork
Welcome to Dungeon. This version created 11-MAR-91.
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
>
I'm running it on the real deal - a 1991-ish SPARCstation IPC. 25MHz of SPARC goodness.
Most of these machines are dead because the power supply output capacitors have failed, but a fairly easy soldering job and they are back up and running. My original SCSI HD also failed (a 424MB Seagate ST1480N), but I've subbed in a SCSI2SD. Works a treat. I basically just play Nethack on it. I've also been experimenting with TeX 3.141 on it.
As far as a VM, I believe it is possible to run 4.1.4 within QEMU. I haven't personally tried, but I have had success in the past running some versions of Solaris 2.x for sun4m in QEMU. I believe you can emulate a SPARCstation 5 with tcx graphics fairly well with that.
Back then, stacks (and the private namespaces resulting from the use of functions/methods in most modern languages) were probably considered a superfluous resource indulgence: 1970s bloatware.
The history of the source code is interesting. It was called Zork and written in MDL. At some point they renamed it to Dungeon, but then a little while later named it back to Zork. During the time it was called Dungeon, a DEC engineer logged into their system (open to the world on purpose so people could play the game) but instead of playing the game copied the source code off. Then they translated the game into Fortran so they could run it on PDP-11s. This source code is the descendant of that translation.