Source code for a 1977 version of Zork (opens in new tab)

Thanks! Here's a merge of previous 'related' lists. If anyone finds others, we can add them...

Infocom’s code-porting tools for Zork and other games have been found - https://news.ycombinator.com/item?id=38528416 - Dec 2023 (30 comments)

Zork Zcode Interpreters Appear Out of Nowhere - https://news.ycombinator.com/item?id=38361247 - Nov 2023 (14 comments)

Infocom-zcode-terps: Historical source code for Infocom's Z-machine interpreters - https://news.ycombinator.com/item?id=38326878 - Nov 2023 (24 comments)

Microsoft consumes Activision; and a plea - https://news.ycombinator.com/item?id=37893794 - Oct 2023 (160 comments)

1977: Zork - https://news.ycombinator.com/item?id=26181863 - Feb 2021 (91 comments)

Zork source and binaries, January 1978 - https://news.ycombinator.com/item?id=24371538 - Sept 2020 (13 comments)

Zork source code, 1977 - https://news.ycombinator.com/item?id=23108626 - May 2020 (81 comments)

Exploring Zork (2012) - https://news.ycombinator.com/item?id=20731333 - Aug 2019 (22 comments)

Zork and the Z-Machine: Bringing the Mainframe to 8-Bit Home Computers - https://news.ycombinator.com/item?id=19982345 - May 2019 (17 comments)

A Brief History of Zork (2014) - https://news.ycombinator.com/item?id=19946781 - May 2019 (10 comments)

Source code for Zork, Hitchhiker’s Guide, and other Infocom games - https://news.ycombinator.com/item?id=19672436 - April 2019 (238 comments)

Z3 – The Zork CPU - https://news.ycombinator.com/item?id=15169565 - Sept 2017 (11 comments)

The DUNGEON (Zork I) source - https://news.ycombinator.com/item?id=15147346 - Sept 2017 (50 comments)

Your load is too heavy: Zork deep reading - https://news.ycombinator.com/item?id=15138114 - Aug 2017 (32 comments)

The Enduring Legacy of Zork - https://news.ycombinator.com/item?id=15073227 - Aug 2017 (48 comments)

Beyond Zork - https://news.ycombinator.com/item?id=10524438 - Nov 2015 (9 comments)

Revisiting 'Zork': What We Lost in the Transition to Visual Games - https://news.ycombinator.com/item?id=2705269 - June 2011 (133 comments)

Just as an aside on how far we've come since the mid-1980s: back then I had heard of a "Dungeon Definition Language" for writing adventure games (IF) by someone at UCSD(?). I emailed him to ask for the source code, and he kindly granted me access. Instead of a 'git clone' or downloading a tarball, however, this involved me (a) snail mailing him a paper cheque covering the costs of a tape, operator time, and postage; (b) waiting a week or so; and (c) finally receiving a large puffy envelope in the mail, which I was able to have read into my account (for free, due to a friendly sysadmin) the next working day. Then, of course, there was the usual hour or so of (d) fixing up all the little places where your correspondent's unix didn't do things quite how your home system's unix did, before having a copy that actually built and ran.

https://en.wikipedia.org/wiki/9-track_tape

To clarify, "Mainframe Zork" usually means the original MDL version for the PDP-10, Bob Supnik's Fortran translation thereof, or the C translation of the Fortran version. The other, "not mainframe" Zork, is Infocom's Zork series written in ZIL and running on microcomputers.

The old Infocom parsers were quite advanced and support much more advanced grammar than I think I ever considered using in playing a game like that.

Later Infocom games, and later hobby interactive-fiction, has conventions like allowing some abbreviations (x for examine, l for look, i for inventory). My transcripts are full of those. Even if the parser will probably correctly parse a sentence like "I want to look at the table, please", in practice most of us will just type "x table" anyway.

The parser also allowed for combined commands, at least in somewhat later games, so you could type things like (I think) "examine the table and then pick up everything that is on it. then ask the dwarf to go north" as a single command (but that is still going to be split up into several actions, as if they had been entered as several shorter commands). I never learned enough about the parser to dare try to use things like that as I am not quite sure what the parser would understand or not. Easier to just input one thing at a time and see what happens before typing in the next thing.

While the parsers can be impressive, I just as happily go back to play the more simpler games like the ones by Scott Adams that used a two-word parser and only read the first three letters of each word. You really don't need more than that for good player input. That user interface is much easier to use as there are fewer things you may have to try to make the parser understand what you want to do.

You mean an LLM-based adventure game? There’s AI Dungeon [1]. Or do you mean a more sophisticated conventional parser with a hand-crafted adventure? That I’m not aware of.

From what I know about adventure games with parsers, they’re essentially just a big finite state machine with descriptions for each state and a hard-coded list of commands that trigger state transitions. There may be additional commands that print a whimsical or humorous response but otherwise leave the player in exactly the same state. There’s also usually a default response for when the input can’t be parsed into a valid command.

The AI Dungeon approach, as far as I’m aware, isn’t really a game with rules and a reachable end condition. It’s just an LLM trained on fantasy role-playing description so it can produce a lot of stuff in response to any prompt. What it lacks, as far as I’m aware, is the underlying state machine.

[1] https://play.aidungeon.com/

See https://ganelson.github.io/inform-website/

(Inform 7 games are actually also programmed in a kind of adventure-speak, but if anyone is willing to play guess-the-verb in not-quite-natural-language, it'd be IF fans. eg https://literateprograms.org/dijkstra_s_algorithm__inform_7_... )

I don't know if this counts, but I wrote a parser for "the ship's computer" in my game, "Space Nerds in Space". It's described here: https://scaryreasoner.wordpress.com/2016/05/14/speech-recogn...

(and that reminds me, there's Google's Parsey McParseface: https://blog.research.google/2016/05/announcing-syntaxnet-wo... though I'm not sure how practical it would be to use that in an interactive fiction context.)

I also wrote some toy "interactive fiction" things (with less sophisticated parsers) in python and Lua as a way to gain familiarity with those languages, not that they are very interesting in and of themselves, though they demonstrate a fairly standard technique behind these kinds of games in a compact way.

https://github.com/smcameron/smcamerons-python-adventure

https://github.com/smcameron/space-nerds-in-space/blob/maste...

I was playing some classic text adventures recently, and what I felt would be straightforward and helpful to improve existing games would be if there was a wrapper that would probe the code to understand all valid commands e.g. "get lamp" and then use vector embeddings so that "grab light", "take gaslight" or other basically equivalent phrases wouldn't give you that immersion shattering response of "There is no <light> visible" or "I do not understand <take>" which makes the parser seem dumb sometimes.

It could fix typos at the same time (which I think some games and engines do to some extent already)

You can run MDL Zork with a interpreter called Confusion.

1970's was MDL (a lisp dialect of sorts), later versions used a specialised subset:

    In 1980 Marc Blank and Joel Berez adapted the MDL language to create a subset called ZIL (Zork Implementation Language) which was used extensively by Infocom to create their award winning games.

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

The README says it was written in MDL.

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