It seems to often make it hard to get back where you were, like you go west and then east and end up in a different place. I don't know enough about z-machines to tell why.
It has been a while since I've played interactive fiction, so I can't make a specific suggestion, but modern games seem to be better at keeping the directions consistent (or at least providing clues when they are not). As others have noted, older games broke directionality to serve as puzzles -- failing to acknowledge that some people have a sense of direction while following twisty paths!
Newer games also tend to follow some quality of life rules in their design, things like avoiding arbitrary deaths and avoiding situations where the player cannot progress because they missed something earlier in the game.
Anything Non-Zork. Even Adventure from Don Woods was half-consistent in some places. But having an "odd" geometry matched perfectly the environment of a cave.
Not ZMachine related, not even with Inform6, where n_to, s_to and w_to e_to are pretty much self-explanatory. It's just that Dungeon/Zork/Zork-I-II-III were made that way.
This was never a technical oddity. This was generally a tool of verisimilitude: the real world isn't built on a clean square grid. You might have a diagonal hallway or a road that curves or a passageway between two "rooms" with a strange incline.
On the one hand, you could encode the hallway itself or the road curve or the passageway as their own weird segments in the grid. But then maybe you bog the player down in a lot of liminal spaces that don't really add much to the game. On the other hand, you could ask the player to bring or build their own map and pay attention to descriptive text like "to the north is a passage that seems to bend to the east" or far more subtle variations of such.
Zork and many other IF games were built on the premise that people would map things and getting lost or confused by grid breaks was part of the fun. (Going back to, as neighboring comments point out, the original Adventure which was modeling caves and caves have always had strange three-dimensional twistiness that doesn't fit a square grid. Part of the fun was discovering that disconnect between the game mechanics using square grid compass terminology and the digraph of the game spaces being more confusing than that.)
It makes sense then. I haven't played zork for over 35 years. The last couple infocom games I played (Hitchhikers, LGOP) had more regular geometries, in my memory.
Oh yeah, Zork itself especially is meant to be a weird place and the geometry intentionally silly at times. Some of the geometry was built to be logic puzzles for fellow MIT students. It's impressive it was ever commercialized, much less successful enough that we are still talking about it today.
There's also ZIL by way of ZILF https://github.com/taradinoc/zilf This is the Lisp-like language that Infocom implementers actually used back in the day.
Infocom came out of the MIT AI Lab which was very LISP-centric at the time. Depending upon you you listen to, the gaming part was something of a side effect as opposed to the ultimate goal.
Though I find it fun on the language family tree that the Infocom team's preferred MDL (and thus ZIL) language was surprisingly closer to (and almost prototyping for) the Scheme split despite being "next door" to some of the most LISP legacy work, too.
Yes, they actually planned to release cross-platform applications in addition to games and actually shipped one (1985's database Cornerstone). The problem was 1985 was a bit late for cross-platform business software to be successful; the IBM PC and compatibles had taken over the business market, and having apps in a VM just meant they were a bit slower than native ones.
And they really went all-in on Cornerstone at a time when PC databases, as you say, had really cornered a (shrinking) market. Even MS Access arguably ended up as something of a footnote. Not that text adventure games, even with some graphical chrome, were really a growing market either.
Yes, very easy to grasp and games will be much lighter than Inform7. Tads it's propietary even if the interpreters are free. Inform6 has the whole stack (even free documentation too), from Inform Beginner's Guide to these, where you have libre games for Inform6 and some free as in freedom
related documentation of Inform6 internals.
Inform 7 source code, at first glance, looks like plain English. It makes you start to wonder whether Inform 7 is actually an LLM and not a compiler. Then as you look at more code, you quickly start to see the structure of the language, and realize that it is indeed a programming language merely structured to look like English at first glance. But it's very cool that you can do things like this (example from the Inform 7 documentation):
Definition: a room is neighboring if the number of moves from it to the location is 1.
Every turn:
if a random chance of 1 in 2 succeeds:
let current location be the location of the lurking critter;
let next location be a random room which is adjacent to the current location;
if the lurking critter is visible:
say "The critter [one of]slouches[or]slithers[or]shambles[or]lurches[at random] away.";
move the lurking critter to next location;
if the lurking critter is visible:
say "A critter [one of]oozes[or]staggers[or]ambles[or]creeps[at random] into the room.";
[Whether or not the critter has moved, we need to adjust the sword-glow, because the player may have moved.]
if the lurking critter is in the location:
adjust sword-glow to glowing brightly;
otherwise if the lurking critter is in a neighboring room:
adjust sword-glow to glowing faintly;
otherwise:
adjust sword-glow to glowless.
This snippet omits the definition of "the lurking critter" (a standard NPC) and the sword (a standard object with a custom defined method called "adjust sword-glow to"), but it should give you a good idea of what Inform 7 source code looks like. (Inform 6 looked much more like a traditional programming language).
It's still pretty good. TADS is a more modern alternative, and the one I would go with, but basically these haven't been commercially viable products since the 80s so there's not a lot going into it.
Arguably, the right answer now is to document everything that matters to you about the adventure, and tell an LLM to run it.
Well, TADS is older than Inform, yes, but the whole idea of VM-based platforms for adventures originated from Infocom's Z-machine starting with Zork I in 1980 -- it's what let them basically release their games for every platform current in the US in the 1980s.
It does even better than that.
I have a private interactive fiction game going based on a popular novel. It's very immersive. Still a work in progress. Right now you can do the daily life things the novel skips like making dinner. I make it so you can skip the day but I was enjoying doing the routine things. It's hard having the game keep track of objects and some NPCs knew things they shouldn't. I tightened it but testing is a lot of work. Hmm. Maybe I can have another LLM play test it.
It also allows you to deviate from the novel. This is a romance novel. I had the main character choose someone else and it showed an alternate version of the novel. After the main threat of the story was dispatched things settled into weeks of routine living where I added another person into my routine. I played to see if another event would show up but after 3 in game weeks I decided to stop. This was a test and I needed to improve the game. I can see this becoming addictive to some people because they will be living in the story and having a life there and making friends and finding partners.
This type of game is still uncharted territory. Does one end the game or let the player play indefinitely? Is it more fun to have the player do the daily life things or skip those or give them a choice?
It was impressed on me in college how much the MOS 6502 is sort of a fascinating line in the sand for a "clockwork computer". You can visualize all of the 6502 registers and all of its easily addressable RAM in a bitmap you can see on a modern screen and its general clock speeds were so much more relatively close to human scale so you could watch such a visualization compute in (near) real-time.
I remember building my own mini-6502 debugger of my own for an assignment I was having difficulty debugging on the breadboarded hardware in our lab (and also to save me from having to spend all of my waking hours in that lab). I want to say it was in something stupid like PHP at the time, but it was just a quick and dirty hacked together thing I did in like an hour during a lecture for a different class.
I've seen some really cool projects on HN of people building visual/visible 6502 boards. LEDs have gotten so cheap and the 6502 is so easy to replicate in FPGA and other hardware spaces that you can build real neat 6502 computers. Which I think the original homebrew computer club hackers would still respect all these years later. (The 6502 fueled the original home computer revolution and was in so many machines, from the Apple II to the Commodore 64 to the NES and more. It was such a key workhorse chip.) I'm still glad I had a lab course on the 6502 in my college education. (The follow up one with the Motorola 68k was maybe less successful, and mostly taught us why the 68k is the last real breadboardable CPU in so many ways including the way that it frequently burned through breadboards and made most debugging a hardware issue.)
This is neat. Z-machine internals without needing to run a debugger.
Very cool. Did a very little testing for Infocom back in the day and knew a lot of the folks involved.
Neat! Any cool stories? What games did you work on?
I didn't really work on any games formally. Knew a lot of the folks from school and after and did some informal testing and feedback.
It seems to often make it hard to get back where you were, like you go west and then east and end up in a different place. I don't know enough about z-machines to tell why.
It has been a while since I've played interactive fiction, so I can't make a specific suggestion, but modern games seem to be better at keeping the directions consistent (or at least providing clues when they are not). As others have noted, older games broke directionality to serve as puzzles -- failing to acknowledge that some people have a sense of direction while following twisty paths!
Newer games also tend to follow some quality of life rules in their design, things like avoiding arbitrary deaths and avoiding situations where the player cannot progress because they missed something earlier in the game.
>Modern
Anything Non-Zork. Even Adventure from Don Woods was half-consistent in some places. But having an "odd" geometry matched perfectly the environment of a cave.
Not ZMachine related, not even with Inform6, where n_to, s_to and w_to e_to are pretty much self-explanatory. It's just that Dungeon/Zork/Zork-I-II-III were made that way.
Nothing to do with the VM. The game was designed that way, navigation is part of the puzzle.
This was never a technical oddity. This was generally a tool of verisimilitude: the real world isn't built on a clean square grid. You might have a diagonal hallway or a road that curves or a passageway between two "rooms" with a strange incline.
On the one hand, you could encode the hallway itself or the road curve or the passageway as their own weird segments in the grid. But then maybe you bog the player down in a lot of liminal spaces that don't really add much to the game. On the other hand, you could ask the player to bring or build their own map and pay attention to descriptive text like "to the north is a passage that seems to bend to the east" or far more subtle variations of such.
Zork and many other IF games were built on the premise that people would map things and getting lost or confused by grid breaks was part of the fun. (Going back to, as neighboring comments point out, the original Adventure which was modeling caves and caves have always had strange three-dimensional twistiness that doesn't fit a square grid. Part of the fun was discovering that disconnect between the game mechanics using square grid compass terminology and the digraph of the game spaces being more confusing than that.)
It makes sense then. I haven't played zork for over 35 years. The last couple infocom games I played (Hitchhikers, LGOP) had more regular geometries, in my memory.
Oh yeah, Zork itself especially is meant to be a weird place and the geometry intentionally silly at times. Some of the geometry was built to be logic puzzles for fellow MIT students. It's impressive it was ever commercialized, much less successful enough that we are still talking about it today.
Don't imagine a grid.
Instead imagine that "GO EAST" takes you onto a winding road.
The road arcs southward and to go back you'd have to "GO NORTH".
Further... some travels in Zork even drop you through a hole (though I forget if it tells you so).
So going East might put you in the basement and there's no way to climb back up.
Perhaps you could try making a map.
Or in this case; just click on "map"
This is very neat! Been wondering what people would do with the Zork code now that it is open source [1].
[1]: https://opensource.microsoft.com/blog/2025/11/20/preserving-...
Would Inform 6 nowadays be still the language of choice for developing text based games like Zork? Or even a reasonable choice for that matter?
There's also ZIL by way of ZILF https://github.com/taradinoc/zilf This is the Lisp-like language that Infocom implementers actually used back in the day.
Infocom came out of the MIT AI Lab which was very LISP-centric at the time. Depending upon you you listen to, the gaming part was something of a side effect as opposed to the ultimate goal.
Though I find it fun on the language family tree that the Infocom team's preferred MDL (and thus ZIL) language was surprisingly closer to (and almost prototyping for) the Scheme split despite being "next door" to some of the most LISP legacy work, too.
Yes, they actually planned to release cross-platform applications in addition to games and actually shipped one (1985's database Cornerstone). The problem was 1985 was a bit late for cross-platform business software to be successful; the IBM PC and compatibles had taken over the business market, and having apps in a VM just meant they were a bit slower than native ones.
And they really went all-in on Cornerstone at a time when PC databases, as you say, had really cornered a (shrinking) market. Even MS Access arguably ended up as something of a footnote. Not that text adventure games, even with some graphical chrome, were really a growing market either.
Yes, very easy to grasp and games will be much lighter than Inform7. Tads it's propietary even if the interpreters are free. Inform6 has the whole stack (even free documentation too), from Inform Beginner's Guide to these, where you have libre games for Inform6 and some free as in freedom related documentation of Inform6 internals.
https://jxself.org/git/
I built https://github.com/chicagodave/sharpee/ as a modern IF platform (Typescript) that runs natively in a browser.
Also https://sharpee.net/
I think Inform 7 is pretty cool. I suggest checking in to that as well.
Inform 7 source code, at first glance, looks like plain English. It makes you start to wonder whether Inform 7 is actually an LLM and not a compiler. Then as you look at more code, you quickly start to see the structure of the language, and realize that it is indeed a programming language merely structured to look like English at first glance. But it's very cool that you can do things like this (example from the Inform 7 documentation):
This snippet omits the definition of "the lurking critter" (a standard NPC) and the sword (a standard object with a custom defined method called "adjust sword-glow to"), but it should give you a good idea of what Inform 7 source code looks like. (Inform 6 looked much more like a traditional programming language).> [Whether or not the critter has moved, we need to adjust the sword-glow, because the player may have moved.]
That must be a comment, right?
In that case: "The critter [one of]slouches[or]slithers[or]shambles[or]lurches[at random] away.";
[one of] [or] [at random] are also comments?
In code, square brackets indicate comments. But inside a string literal they indicate variable interpolation or other commands.
It's still pretty good. TADS is a more modern alternative, and the one I would go with, but basically these haven't been commercially viable products since the 80s so there's not a lot going into it.
Arguably, the right answer now is to document everything that matters to you about the adventure, and tell an LLM to run it.
TADS is hardly modern. It’s actually the oldest VM based platform from the early 90’s.
Well, TADS is older than Inform, yes, but the whole idea of VM-based platforms for adventures originated from Infocom's Z-machine starting with Zork I in 1980 -- it's what let them basically release their games for every platform current in the US in the 1980s.
But not publicly available as a platform.
I wonder if you could make a "choose-your-own-adventure" book uning LLMs.
It would write the book ahead of you, kind of like how railroads could send trains with supplies out to the track as it was built.
It does even better than that. I have a private interactive fiction game going based on a popular novel. It's very immersive. Still a work in progress. Right now you can do the daily life things the novel skips like making dinner. I make it so you can skip the day but I was enjoying doing the routine things. It's hard having the game keep track of objects and some NPCs knew things they shouldn't. I tightened it but testing is a lot of work. Hmm. Maybe I can have another LLM play test it.
It also allows you to deviate from the novel. This is a romance novel. I had the main character choose someone else and it showed an alternate version of the novel. After the main threat of the story was dispatched things settled into weeks of routine living where I added another person into my routine. I played to see if another event would show up but after 3 in game weeks I decided to stop. This was a test and I needed to improve the game. I can see this becoming addictive to some people because they will be living in the story and having a life there and making friends and finding partners.
This type of game is still uncharted territory. Does one end the game or let the player play indefinitely? Is it more fun to have the player do the daily life things or skip those or give them a choice?
Like with any LLM produced project, can you? Sure. Will it be engaging, well written or consistent? Almost certainly not.
You could, but no one wants to read or play GenAI content.
Nice. Like watching clockwork internals. Came across a similar engine for another text based adventure a while ago: https://github.com/efa/Wilderland
It was impressed on me in college how much the MOS 6502 is sort of a fascinating line in the sand for a "clockwork computer". You can visualize all of the 6502 registers and all of its easily addressable RAM in a bitmap you can see on a modern screen and its general clock speeds were so much more relatively close to human scale so you could watch such a visualization compute in (near) real-time.
I remember building my own mini-6502 debugger of my own for an assignment I was having difficulty debugging on the breadboarded hardware in our lab (and also to save me from having to spend all of my waking hours in that lab). I want to say it was in something stupid like PHP at the time, but it was just a quick and dirty hacked together thing I did in like an hour during a lecture for a different class.
I've seen some really cool projects on HN of people building visual/visible 6502 boards. LEDs have gotten so cheap and the 6502 is so easy to replicate in FPGA and other hardware spaces that you can build real neat 6502 computers. Which I think the original homebrew computer club hackers would still respect all these years later. (The 6502 fueled the original home computer revolution and was in so many machines, from the Apple II to the Commodore 64 to the NES and more. It was such a key workhorse chip.) I'm still glad I had a lab course on the 6502 in my college education. (The follow up one with the Motorola 68k was maybe less successful, and mostly taught us why the 68k is the last real breadboardable CPU in so many ways including the way that it frequently burned through breadboards and made most debugging a hardware issue.)