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'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.
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 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.
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'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.
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 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.
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".
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...
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.
Someone please disrupt this genre with small local language model parsers already.
The risk, I imagine, is that they open up unintended avenues of gameplay as they generously interpret options
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.
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 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 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...
Let every 1980s game programmer who never shipped a memory-trashing bug raise their hand.
I thought so! :-)
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'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.
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!
> As a C programmer, I am legally required to regard memory corruption as the worst of all possible sins.
Self-flagellation considered harmful.
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.
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.
Write what you know. If you don't know, learn.
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.
Wow. That was interesting.