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)
Do you still have that code?
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.
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.
I guess I don’t have a clear idea of exactly what I’m asking for aside from a general feeling that you could create more natural feeling interactions with today’s technologies. But I’m not sure what that would look like. I should chat with one of my Infocom friends one of these days.
(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_... )
(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...
It could fix typos at the same time (which I think some games and engines do to some extent already)
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)