Someone commented that it's fun to see Zarf is still around, so I want to take the opportunity to say that the entire community around text adventures is likewise still thriving, most visibly on the IntFiction.org forums.
People seem to look at text adventures as relics of a specific era, and it's true that it's hard to make money off of them these days, but there are several high-quality releases per year, and the quality seems to only go up. These games are often playable for free, because they're released for competitions that stipulate the submission must be free.
-----
It can be a little hard to get into text adventures, because the parser interface is designed to accept inputs according to a specific convention (all three of "cut tapestry", "cut the tapestry", "look behind tapestry. cut it." would work, but it's not a guarantee "slice tapestry" would, and almost never would "cut hanging fabric" work).
This convention must be learned. Despite the marketing in the 1980's, it does not come naturally to people. Learning that convention means forcing yourself through a few games. But once you have learned that convention, an ocean of games open up to be played, many of them very enjoyable. I highly recommend taking the time to grind through a few games to get familiar with the convention.
I recommend not starting with the old classics because they were in part made to be frustrating and difficult and played over a long time. Instead, look at modern text adventures that follow more recent advances in game design. A good source is the Interactive Fiction Database, with e.g. a search like this: https://ifdb.org/search?searchfor=tag%3AParser+published%3A2...
-----
Text adventures are also a nice way to dip one's toes into game development. They force the developer to think about game design without having to spend time or money on graphics or music.
We are spoiled choice when it comes to development systems for text adventures these days. Most popular development systems consist of two parts: programming language, and separately, standard library. The library half contains generic definitions of things like rooms, scenery items that cannot be picked up, clothing that can be worn, animals that can be interacted with but not talked to, etc. (The exception is perhaps Inform 7, which tightly couples its compiler to the standard library. In the case of the others, one is fairly free to swap out the standard library for anything else.)
Examples include:
- Inform 7 lets developers write code in a weird subset of English. Some people swear by it, but people who come from programming backgrounds sometimes find it hard to learn. It does have a great IDE though, with automapping, an index of all objects, a "Skein" that records a game tree and lets one play it back and check for inconsistencies, etc.
- Inform 6 is a completely different language, reading more like object-oriented code. There is an alternative standard library called PunyInform which lets you make tiny games that run well on old hardware. (But which can also be used as a creative constraint.) It doesn't have the same level of tooling, but it's been around for a long time and is well supported on many platforms. The compiler is a simple, dependency-free C program one runs `cc -O2 -o inform *.c` to compile.
- Dialog is a newer language and library for making text adventures that's stable, but receives frequent updates still. It's inspired by the rules-based approach of Inform 7, but uses a more consistent, programmer-friendly syntax. It's got a kick-ass debugger that reloads definitions live and supports a highly iterative development cycle. There's also a recent, partly vibe-coded "Dialog Tool" made for it that gives it an Inform 7-like Skein functionality.
Then there are others I haven't tried, like TADS, which, like Inform 6, is closer to traditional programming. The original Infocom games were written in Lisp macros that got translated into the Lisp-like ZIL language. These days, we have an extremely well-documented open source implementation of ZIL, too.
In case anyone is curious, I have written two articles introducing Inform 6 and Dialog respectively as general programming languages outside of their use for text adventures. (But this is not a recommended use case. Just a fun way to learn where the language ends and the standard library picks up.)
> I recommend not starting with the old classics because they were in part made to be frustrating and difficult and played over a long time. Instead, look at modern text adventures that follow more recent advances in game design.
A timely comment for me. I tried the linked Planetfall game, and gave up after a little bit of wandering around and nothing happening. Apparently I was supposed to just putter about for longer until the game really started with the emergency event, which got me thinking about game design in these early games.
Some of these games really liked to give you a combinatorial search problem dressed up as a game. In Colossal Cave Adventure, one of the first puzzles is to get a bird into a cage, so you can use the bird to scare away a snake. The bird is scared of a rod you find earlier, so you have to drop the rod in a different room before you get the bird (and then go back and get the rod). Now none of this makes any sense. The expectation is that you have nothing better to do then just try different combinations until you find what works. In a way it's asking you to play a meta-game, rather than the game.
This reminds me of Sword of the Samurai [1], a Fighting Fantasy book I had the misfortune to read when I was a lot younger. It was fiendishly difficult if you actually played by the rules. Partly this is because the combat was really hard (see the linked review) but also because there were just so many choices where the book gives no hints what is a good choice to make. For example, right at the end there is fight between you and your buddies versus four baddies. Each one of your buddies can take out a specific baddy, but there is no indication which is which. So the book is really designed with the expectation that you're constantly going to cheat. This meta-game of bookmarking each decision point and exploring the decision tree before committing is the actual game that the book is written for, and it has a lot of content to explore if you realise this is the game you should play.
What makes you believe people haven't tried? I have yet to find an example that actually works.
The language models have a tendency to not stick to the script (inventing world state that does not exist), be too helpul (provide spoilers), or get stuck on the same confusions as a human would.
I have recently attempted to build out games for myself and others.
I have done 100% state using AI context which works well.
The hard part about a game is the world-rules must be predictable and enforced.
Role play for example requires a target (and limits) but how do you enforce it?
If the paths are too open fashion a shovel and dig around the door.
The problems I have encountered:
1. AI is nerf'ed, helpful, restrictive, annoying, repetitive.
2. AI doesn't understand the difference between halting and blocking.
3. People want to know that a human or their proxy is making decisions. Not AI.
4. Difficult and Impossible - AI does not know the difference.
I have not tried to build a full harness to guide the game but game theory and rules have proven to be quite difficult.
> Someone please disrupt this genre with small local language model parsers already.
Do you mean something like: the LLM gets the input from the player, then interprets it to mean something built out of the available verbs? I guess the risk here is that the LLM would be overly generous with its interpretation and help the player too much (e.g. "the player wrote 'slice the tapestry' but there's only a rope in the description of the room, let's assume they meant 'pull the rope'").
I'm skeptical. When I tried "word games" with arbitrary rules (such as not mentioning specific words) the LLM often goes off script and breaks the rules. An LLM that is "too helpful" effectively ruins the game, and prompting cannot be relied on to enforce rules.
Amazing comment. The only thing I’ll add is that the annual competition for interactive fiction is on now. It covers both choice-based game as well as traditional parser games.
Many of the games are quite short, perfect for dipping your toes in this kind of thing.
I've been gradually reading the Digital Antiquarian's series of posts [0] about history of computer games. Many of these feature links to try out these games (I haven't yet gotten to games that were released after I was born)... with user setup required (take this disk image, run it in a Apple II emulator, etc). The history so far has heavily featured text based simple parser adventure games.
This might be the way in which I finally try one of these games out. Though, I'm betting my attention won't last long.
I finished all Infocom games during covid (and read all Digital Antiquarian articles since then). Despite being very interested in the games, I knew I wouldn't have energy to literally beat them. So I played with walkthroughs, stopping to examine things and enjoy the scenery, so to speak. There was no challenge, but I still had fun. Somewhat like visiting a museum.
As good as any Infocom game — maybe even better. Great puzzle mechanic. Engaging story. Easy to get around. Absolutely everything you can think of to do has an implemented response. Can complete in maybe two or three evenings. This is my favorite text adventure.
I wouldn’t call this one of my favorites, but many people consider it one of the most important works of modern IF. It does have one moment that’s really, really cool. The story is a downer.
I'm definitely guilty of writing some sick memory-trashjng bugs when I was first getting started as an intern. The best one had my team lead and a staff engineer puzzling over what the hell was going on. The second best one had someone hunting down my email and messaging me months after the internship ended just to cuss me out haha. Perhaps it is better I don't work in C anymore.
I think you're probably being too hard on yourself. As far as I can tell, the Venn diagram of people who have written non-trivial amounts of C code used in the real world and people who have written memory corruption bugs is a circle.
Back in 1999 I somehow managed to make my project du jour (a text editor) crash Windows 95 so hard that after rebooting it popped up a message telling you to reinstall Windows. :D
I want to write technically interesting posts like this too, but I don't know how.
My writing is mostly just tracking various internet posts to trace history. How do you create interesting posts based on personal experience like this?
lately I've been thinking about how something on reddit/hn/lobsters reminds me of an interesting moment from my career, and I write up a small reply about it, and that could conceivably also be a blog post if only I had a blog. and then I do nothing about it :) but that's definitely one way to blog; just take the effort to follow through on random inspirations like that.
another great route to follow is what julia evans does on her blog [https://jvns.ca/] - a lot of the posts are "hey, I learnt something new today, and here it is!". the key point is that there is no attempt at having every post be the same "weight", some of them are deep dives into a topic and some are just passing thoughts or howtos.
I looked up your blog and it is clear you have a deep interest for explaining ideas and programming techniques. That's great, there's passion! I even found that you've written about some things close to my own heart:
Looking through it I learned some cool stuff - I had no idea about this.
However, there's one piece of advice which seems applicable to most technical writing I saw on this blog, especially the Pokémon FSM one:
You need to work on pacing and length. The core issue is very broad scope. Think carefully about your target audience and the key insight you want to communicate. Then narrow your scope to communicating only what is necessary for that idea, skipping things your target audience can be assumed to already understand. The writing will automatically get snappier and more engaging.
If you want to explain the FSM script engine in Pokémon you have to assume the reader is somewhat familiar with programming and won't need a primer on registers. Otherwise you're writing a low-level programming primer, not an article about a clever technique in a video game.
well first you have personal experiences like that
or rather: you have personal experiences like whatever your experiences are like, not like theirs, and then you write about them if you think anyone else would also be interested.
Most people I know keep "journals" (in various ways and shapes) when they're working on stuff. Producing something for public consumption becomes "compile my already existing stuff and writing into a presentable thing" rather than "start writing from zero".
I don't share that opinion but many people believe that LLMs are the new compilers. This make me wonder if there will ever be a time that people get surprised to see LLMs generating wrong code.
Natural language is much more vague than programming languages (understatement of the year), even C, and LLMs are not deterministic. Perhaps you can solve the second (read: I don't know what I'm talking about), but to solve the first one, I think one needs to re-invent programming languages, which would be extremely funny if it really ends up happening :)
I used to frequent rec.arts.int-fiction and rec.games.int-fiction. There Andrew / Zarf was a regular. Looks like now he is still active in interactive fiction. Salute to him!
I once built a basic fuzzer for the Z-machine and tried it on Mini-Zork (a promotional game). It found at least one bug. I wonder if a smarter fuzzer could find the Infidel bug.
Someone commented that it's fun to see Zarf is still around, so I want to take the opportunity to say that the entire community around text adventures is likewise still thriving, most visibly on the IntFiction.org forums.
People seem to look at text adventures as relics of a specific era, and it's true that it's hard to make money off of them these days, but there are several high-quality releases per year, and the quality seems to only go up. These games are often playable for free, because they're released for competitions that stipulate the submission must be free.
-----
It can be a little hard to get into text adventures, because the parser interface is designed to accept inputs according to a specific convention (all three of "cut tapestry", "cut the tapestry", "look behind tapestry. cut it." would work, but it's not a guarantee "slice tapestry" would, and almost never would "cut hanging fabric" work).
This convention must be learned. Despite the marketing in the 1980's, it does not come naturally to people. Learning that convention means forcing yourself through a few games. But once you have learned that convention, an ocean of games open up to be played, many of them very enjoyable. I highly recommend taking the time to grind through a few games to get familiar with the convention.
I recommend not starting with the old classics because they were in part made to be frustrating and difficult and played over a long time. Instead, look at modern text adventures that follow more recent advances in game design. A good source is the Interactive Fiction Database, with e.g. a search like this: https://ifdb.org/search?searchfor=tag%3AParser+published%3A2...
-----
Text adventures are also a nice way to dip one's toes into game development. They force the developer to think about game design without having to spend time or money on graphics or music.
We are spoiled choice when it comes to development systems for text adventures these days. Most popular development systems consist of two parts: programming language, and separately, standard library. The library half contains generic definitions of things like rooms, scenery items that cannot be picked up, clothing that can be worn, animals that can be interacted with but not talked to, etc. (The exception is perhaps Inform 7, which tightly couples its compiler to the standard library. In the case of the others, one is fairly free to swap out the standard library for anything else.)
Examples include:
- Inform 7 lets developers write code in a weird subset of English. Some people swear by it, but people who come from programming backgrounds sometimes find it hard to learn. It does have a great IDE though, with automapping, an index of all objects, a "Skein" that records a game tree and lets one play it back and check for inconsistencies, etc.
- Inform 6 is a completely different language, reading more like object-oriented code. There is an alternative standard library called PunyInform which lets you make tiny games that run well on old hardware. (But which can also be used as a creative constraint.) It doesn't have the same level of tooling, but it's been around for a long time and is well supported on many platforms. The compiler is a simple, dependency-free C program one runs `cc -O2 -o inform *.c` to compile.
- Dialog is a newer language and library for making text adventures that's stable, but receives frequent updates still. It's inspired by the rules-based approach of Inform 7, but uses a more consistent, programmer-friendly syntax. It's got a kick-ass debugger that reloads definitions live and supports a highly iterative development cycle. There's also a recent, partly vibe-coded "Dialog Tool" made for it that gives it an Inform 7-like Skein functionality.
Then there are others I haven't tried, like TADS, which, like Inform 6, is closer to traditional programming. The original Infocom games were written in Lisp macros that got translated into the Lisp-like ZIL language. These days, we have an extremely well-documented open source implementation of ZIL, too.
In case anyone is curious, I have written two articles introducing Inform 6 and Dialog respectively as general programming languages outside of their use for text adventures. (But this is not a recommended use case. Just a fun way to learn where the language ends and the standard library picks up.)
- https://entropicthoughts.com/advent-of-code-on-z-machine
- https://entropicthoughts.com/advent-of-code-in-dialog
> I recommend not starting with the old classics because they were in part made to be frustrating and difficult and played over a long time. Instead, look at modern text adventures that follow more recent advances in game design.
A timely comment for me. I tried the linked Planetfall game, and gave up after a little bit of wandering around and nothing happening. Apparently I was supposed to just putter about for longer until the game really started with the emergency event, which got me thinking about game design in these early games.
Some of these games really liked to give you a combinatorial search problem dressed up as a game. In Colossal Cave Adventure, one of the first puzzles is to get a bird into a cage, so you can use the bird to scare away a snake. The bird is scared of a rod you find earlier, so you have to drop the rod in a different room before you get the bird (and then go back and get the rod). Now none of this makes any sense. The expectation is that you have nothing better to do then just try different combinations until you find what works. In a way it's asking you to play a meta-game, rather than the game.
This reminds me of Sword of the Samurai [1], a Fighting Fantasy book I had the misfortune to read when I was a lot younger. It was fiendishly difficult if you actually played by the rules. Partly this is because the combat was really hard (see the linked review) but also because there were just so many choices where the book gives no hints what is a good choice to make. For example, right at the end there is fight between you and your buddies versus four baddies. Each one of your buddies can take out a specific baddy, but there is no indication which is which. So the book is really designed with the expectation that you're constantly going to cheat. This meta-game of bookmarking each decision point and exploring the decision tree before committing is the actual game that the book is written for, and it has a lot of content to explore if you realise this is the game you should play.
So yeah, game design has come a long way :-)
[1]: https://fightingfantasy.net/articles/the-parallax-walkthroug...
Someone please disrupt this genre with small local language model parsers already.
What makes you believe people haven't tried? I have yet to find an example that actually works.
The language models have a tendency to not stick to the script (inventing world state that does not exist), be too helpul (provide spoilers), or get stuck on the same confusions as a human would.
You want the language model in the interface -- to parse the input text and convert it to a more structured command language internally.
That would solve the main UX problem with the genre.
If you can build something like that and get it to work, I'd be impressed and very excited! People before you have failed.
I have recently attempted to build out games for myself and others.
I have done 100% state using AI context which works well.
The hard part about a game is the world-rules must be predictable and enforced.
Role play for example requires a target (and limits) but how do you enforce it?
If the paths are too open fashion a shovel and dig around the door.
The problems I have encountered:
1. AI is nerf'ed, helpful, restrictive, annoying, repetitive. 2. AI doesn't understand the difference between halting and blocking. 3. People want to know that a human or their proxy is making decisions. Not AI. 4. Difficult and Impossible - AI does not know the difference.
I have not tried to build a full harness to guide the game but game theory and rules have proven to be quite difficult.
I'm not sure I follow. You claim it works well, then give a list of dealbreakers that show it doesn't work well...
> Someone please disrupt this genre with small local language model parsers already.
Do you mean something like: the LLM gets the input from the player, then interprets it to mean something built out of the available verbs? I guess the risk here is that the LLM would be overly generous with its interpretation and help the player too much (e.g. "the player wrote 'slice the tapestry' but there's only a rope in the description of the room, let's assume they meant 'pull the rope'").
I'm guessing you can fix this with some prompt engineering.
I'm skeptical. When I tried "word games" with arbitrary rules (such as not mentioning specific words) the LLM often goes off script and breaks the rules. An LLM that is "too helpful" effectively ruins the game, and prompting cannot be relied on to enforce rules.
Inform7 targeting the Z8 machine or Glulx it's far superior to any LLM crap.
The risk, I imagine, is that they open up unintended avenues of gameplay as they generously interpret options
Amazing comment. The only thing I’ll add is that the annual competition for interactive fiction is on now. It covers both choice-based game as well as traditional parser games.
Many of the games are quite short, perfect for dipping your toes in this kind of thing.
https://ifcomp.org/ballot#browse
Inform6 it's really easy, it's like the perfect OOP language to teach text adventures to older Elementary kids.
Dialog is pretty fun, kind of like a lite Prolog. It compiles to Z-code or its own VM (Å-machine) which can run on C-64 and Apple II.
Just want to say thank you for the absolutely amazing and generous comment! :)
I've been gradually reading the Digital Antiquarian's series of posts [0] about history of computer games. Many of these feature links to try out these games (I haven't yet gotten to games that were released after I was born)... with user setup required (take this disk image, run it in a Apple II emulator, etc). The history so far has heavily featured text based simple parser adventure games.
This might be the way in which I finally try one of these games out. Though, I'm betting my attention won't last long.
[0] https://www.filfre.net/the-digital-antiquarian-e-book-librar...
I finished all Infocom games during covid (and read all Digital Antiquarian articles since then). Despite being very interested in the games, I knew I wouldn't have energy to literally beat them. So I played with walkthroughs, stopping to examine things and enjoy the scenery, so to speak. There was no challenge, but I still had fun. Somewhat like visiting a museum.
I think Zarf's Visible Zorker implementation of Suspended is the best way to play it. He incorporated the map into the game itself, it's so good.
https://eblong.com/infocom/visi/suspended/
To anyone who hasn't played text adventures before, I highly recommend giving them a try because there's nothing else like them.
Everybody has their own recommended starting points, but here are a few of mine for anyone who might be interested.
9:05
https://ifdb.org/viewgame?id=qzftg3j8nh5f34i2
Can complete in a few minutes. Illustrative of how text adventures can do things that other types of games often don’t.
Violet
https://ifdb.org/viewgame?id=4glrrfh7wrp9zz7b
Fun and logical puzzles. Lovable narrator. Can complete in an hour or two.
Shade
https://ifdb.org/viewgame?id=hsfc7fnl40k4a30q
Made by Zarf / Andrew Plotkin, the guy linked to above. Can complete in 30-60 minutes.
Counterfeit Monkey
https://ifdb.org/viewgame?id=aearuuxv83plclpl
As good as any Infocom game — maybe even better. Great puzzle mechanic. Engaging story. Easy to get around. Absolutely everything you can think of to do has an implemented response. Can complete in maybe two or three evenings. This is my favorite text adventure.
Photopia
https://ifdb.org/viewgame?id=ju778uv5xaswnlpl
I wouldn’t call this one of my favorites, but many people consider it one of the most important works of modern IF. It does have one moment that’s really, really cool. The story is a downer.
Let every 1980s game programmer who never shipped a memory-trashing bug raise their hand.
I thought so! :-)
I'm definitely guilty of writing some sick memory-trashjng bugs when I was first getting started as an intern. The best one had my team lead and a staff engineer puzzling over what the hell was going on. The second best one had someone hunting down my email and messaging me months after the internship ended just to cuss me out haha. Perhaps it is better I don't work in C anymore.
I think you're probably being too hard on yourself. As far as I can tell, the Venn diagram of people who have written non-trivial amounts of C code used in the real world and people who have written memory corruption bugs is a circle.
It's concentric circles, and the "have written non-trivial amounts" circle is the inner one.
Fair point!
Back in 1999 I somehow managed to make my project du jour (a text editor) crash Windows 95 so hard that after rebooting it popped up a message telling you to reinstall Windows. :D
I want to write technically interesting posts like this too, but I don't know how.
My writing is mostly just tracking various internet posts to trace history. How do you create interesting posts based on personal experience like this?
lately I've been thinking about how something on reddit/hn/lobsters reminds me of an interesting moment from my career, and I write up a small reply about it, and that could conceivably also be a blog post if only I had a blog. and then I do nothing about it :) but that's definitely one way to blog; just take the effort to follow through on random inspirations like that.
another great route to follow is what julia evans does on her blog [https://jvns.ca/] - a lot of the posts are "hey, I learnt something new today, and here it is!". the key point is that there is no attempt at having every post be the same "weight", some of them are deep dives into a topic and some are just passing thoughts or howtos.
That's practical advice. Thank you.
I looked up your blog and it is clear you have a deep interest for explaining ideas and programming techniques. That's great, there's passion! I even found that you've written about some things close to my own heart:
https://www.makonea.com/en-US/blog/Pokemon-Red-and-the-Evolu...
Looking through it I learned some cool stuff - I had no idea about this.
However, there's one piece of advice which seems applicable to most technical writing I saw on this blog, especially the Pokémon FSM one:
You need to work on pacing and length. The core issue is very broad scope. Think carefully about your target audience and the key insight you want to communicate. Then narrow your scope to communicating only what is necessary for that idea, skipping things your target audience can be assumed to already understand. The writing will automatically get snappier and more engaging.
If you want to explain the FSM script engine in Pokémon you have to assume the reader is somewhat familiar with programming and won't need a primer on registers. Otherwise you're writing a low-level programming primer, not an article about a clever technique in a video game.
thanks!
well first you have personal experiences like that
or rather: you have personal experiences like whatever your experiences are like, not like theirs, and then you write about them if you think anyone else would also be interested.
Sounds good. I should reflect on my own experiences too.
Most people I know keep "journals" (in various ways and shapes) when they're working on stuff. Producing something for public consumption becomes "compile my already existing stuff and writing into a presentable thing" rather than "start writing from zero".
Thank you always for the good advice. I should organize things based on the records I've kept, too.
Write what you know. If you don't know, learn.
[dead]
I don't share that opinion but many people believe that LLMs are the new compilers. This make me wonder if there will ever be a time that people get surprised to see LLMs generating wrong code.
Natural language is much more vague than programming languages (understatement of the year), even C, and LLMs are not deterministic. Perhaps you can solve the second (read: I don't know what I'm talking about), but to solve the first one, I think one needs to re-invent programming languages, which would be extremely funny if it really ends up happening :)
I used to frequent rec.arts.int-fiction and rec.games.int-fiction. There Andrew / Zarf was a regular. Looks like now he is still active in interactive fiction. Salute to him!
I once built a basic fuzzer for the Z-machine and tried it on Mini-Zork (a promotional game). It found at least one bug. I wonder if a smarter fuzzer could find the Infidel bug.
Article: https://8bitworkshop.com/docs/posts/2020/fuzzing-the-z-machi...
> As a C programmer, I am legally required to regard memory corruption as the worst of all possible sins.
Self-flagellation considered harmful.
Wow. That was interesting.