Many years ago (circa 1993) I ported the original Colossal Cave adventure by Crowther and Woods to TADS, a language created by Mike Roberts specifically for authoring text adventures. (Colossal Cave just came up recently here.)
Graham Nelson ported my port to his Inform language, and Inform is probably your best choice if what you actually want to do is write a (plain text) adventure game.
If you want to learn C programming, writing a text adventure in C would be a fun learning project! But aside from pedagogy there’s no real reason to write a text adventure in anything other than Inform, TADS, etc. Not only is it much easier to use one of these purpose-built languages, with Inform you get multi-platform compatibility going back to the 8-bit era for free!
Personally if I had any free time, I’d be more interested in looking at how to use a frontier LLM like llama as an integral part of a text adventure. There was something like this using GPT-2 circulating on here a while back, but it was pretty rough.
However, it’s clear that if you figured out how to precisely control the LLM so it didn’t produce crazy stuff, you could realize the dream of truly realistic NPCs in these games. Text adventures would seem to be a perfect laboratory for experimenting with this.
cave is the first game i remember feeling immersed in. it was so good. its awesome you ported it!
Im playing with an LLM to remake drug wars. i pretty quickly changed it to more of a spiritual successor because i wanted to add more features and then had a hard time with them and the drug mechanic so i switched to financial trading and that made more sense. the i changed it to crypto coins in a dystopian future instead of stocks cuz the ascii art needed some lore to help flavor it now that gritty drugs were out
I wrote StoryHarp for creating speech-interactive choose-your-own text adventures back around 1998 (in Delphi for Windows desktop), and ported it to the web about seven years ago (with some limitations) using TypeScript and Tachyons: https://storyharp.com/v3.0
Realistically, StoryHarp might be most fun to use as an authoring tools for kids making short idiosyncratic adventures to share with friends. StoryHarp could help people practice creative writing and learn just a bit of logic to set up puzzles (without getting bogged down in more computing complexity like writing C code or even just the conceptual demands of TADS or Inform, as amazing as those tools are).
I recently added a option (inspired by "flems.io") where you can create a StoryHarp link that includes the entire world definition in the hash. For example, here is a URL for a game that just says "You are visiting the Hacker News website" when you click "look":
https://storyharp.com/v3.0/#world=N4Ig7g9gTgNgJgMQJYwKYDkCGB...
Otherwise the game stores data only in the browser (not the server) which can be exported or imported as files.
While I can see how LLMs might make for more realistic interactions with text adventures, writing text adventures is its own sort of puzzle (like coding programs manually), and I am not sure adding LLMs will really make creating such adventures a much more joyful experience. But maybe it could. I agree in general though that text adventures make a great playground for experimenting with new ideas (as with StoryHarp as an experiment in bringing browser ideas from Smalltalk into interactive fiction design).
Anyway, that is the sort of idiosyncratic short experiential interactive fiction I am talking about. Just spend five or ten minutes and make something that captures an emotion or a theme or a concern or an moral conundrum or whatever.
with Puny Inform6 or limiting Inform6, yes. If not, it's suicidal, even for v3 games.
But, from Amiga and Atari machines, most v5 and v8 games if not all will run great.
You would probably do better on 8-bits by using ZIL which is actually feasible these days thanks to ZILF (and the leaked ZIL source code of the original Infocom games to look at).
* Text adventures are a case where it is really advantageous to separate the declaration and definition of objects, since cycles are ubiquitous. For C, consider X-macros, tentative definitions (not in C++, sadly), and using the section attribute to make the list implicit (or if you don't want to rely on compiler voodoo, just output the index during another pass).
* It may be useful to distinguish several ways an object belongs to a location: on top of, contained in, held by, equipped by, integral component of, death drop of. Additionally, "has never been moved [by player? by code]" is often desirable to record.
* Backwards ownership is fine for savefiles and initialization, but during runtime it can be useful to cache lists in the other direction. A dict may be worth it in a few places if your adventure gets big enough, but linear search is fine for a long time (and makes e.g. conditional passages easier; you should simply check that every conditional transition is eventually followed by an unconditional one with the same tag. To ensure conditions are handled uniformly, transitions with multiple names should canonicalize first).
* For C statically-allocated arrays within a struct initializer, we've been allowed to write `(T[]){t1, t2, t3}` for a quarter century now. There's no need to name the separate objects.
* It is very useful for the runtime to support the notion of "overlays" - used for things like menus which can use surprisingly similar logic to rooms. Saves should only ever look at the main game layer.
* Relative directions are very interesting, but tricky to add to a game.
What I wish I had was an example of a game that is complete enough to be interesting but not too big, to be used when porting to a new engine.
I was wondering: does anybody know if there are any good resources for writing a good text adventure? Any nice tips and tricks? Mainly related to the content. I guess it overlaps with "writing a good novel", but I bet there're some specific advices that can be applied to the text adventure.
I wanted to write my text adventure, but I'd offer reader to have multiple options, especially for those who are not really practical with english (includes myself ^-^).
Aaron Reed's 50 Years of Text Games[1][2] is a fantastic journey into the history and the possibilities of text-based games. I got the physical book and was surprised to find it as engaging as a novel. Each chapter takes one year between 1971 and 2020 and picks a game from that year to discuss in depth. While it might not help with the writing per se, you might good ideas there (several of the games discussed are in the "Adventure" lineage).
For the technical side of things, use ink script. There's an editor, plugins and it's a mature project.
For the creative side I would recommend trying out all kinds of things. Should your player be able to get stuck/into a dead end? Will players play once or many times. Can you "win" your game or is it more of a narrative? How do you want the player to feel!
For some more specific ideas, think about how your game branches. Branching and decisions in games are far trickier than they might appear. Too subtle and the player misses the choice entirely. Too in your face and they become boring ("kill the baby" vs "save the baby", gee I wonder which one takes me down the evil path)
Also, merely asking a question or giving a choice can influence the player. If you ask "who is the killer?" and give a list of suspects, one of them must have done it, even if the player never considered it. The question also assumes the player knows there was a murder and gives that away if they hadn't worked it out yet.
Yeah, I like things like Ink a great deal. It's really easy to overcomplicate narrative design if you're not careful, but Ink (and so forth) do a good job of keeping things simple and staying out of your way.
I've spent the last three years building a game engine specifically to do this, and currently finishing the final draft for the game story I've created to go alongside it.
Happy to share anything you'd find helpful. The big takeaway for me has been, you're going to want to graph out the impact of choices before you write the story. If you know the flow of decisions, then that gives a much clearer structure than trying to write the story first and then create branches off it. I think the reason is that it sets a much tighter scope for the writing doing it that way, whereas if you write the story and then find ways to branch it, the scope for that is functionally infinite.
I think for a lot of people here, the hard part of writing an adventure is not writing the code but coming up with a compelling game with an interesting story and readable text. My advice is that if you want to actually end up with an adventure game that people can actually play, just pick an existing authoring system that looks like it will do sort-of what you want and start writing.
I speak from experience when I say if you start by writing the engine then you will quickly become side-tracked with technical issues and never get your game done.
I can recommend ink if you want a choice-based game. It is super easy to get started and the language lends itself to extension if you find it doesn't do what you need out of the box.
Inform is the big one for "GET LAMP"-style parser text adventures although I haven't used it for years.
For choice based text games there is Twine and ink (plus many others).
I personally used ink[0] for a project[1] and it was a joy to use. It comes with an IDE of sorts that makes just sitting down and writing your story easy before you add the bells and whistles.
I did once write a text-based adventure game in C, however I only did that to work out some of hte "plot" and the layout/objects I was going to work with.
My actual aim was to write a simple text-adventure in Z80 assembly, which could run upon a CP/M system. I did achieve that, and later ported the game to the ZX Spectrum.
A few years after that I used one of the inform-compilers to recode a couple of the puzzles in the Z-machine, which would also have allowed me to run the game on a CP/M system, but to be honest by that point I'd lost interest and I never ported the whole of the game's text, and the two different endings etc.
That said my toy adventure was popular when submitted here, back in the day:
LLMs would definitely make a more dynamic and lively world for NPCs. I can even see a place for dynamic quest building. But it isn’t going to produce a full world without a significant amount of prompting.
I do see how it can help write a lot of boilerplate (item descriptions, back stories, etc). A big thing I always wanted is memory and we worked a long time on it for tracking logic (footprints, hunting). Conversational memory is probably single biggest thing that excites me.
I have long wanted to make a procedurally generated text adventure that focuses on economics, information, and politics rather than spatial exploration. This gets complicated quickly, of course. Basic microeconomics and armchair psychology gets one a bit of the way there, but not enough to generate compelling dialogue and intrigue -- at least I have not been successful.
The best way to implement a text adventure in C would be to implement a simple lisp interpreter in C and then implementing the actual game in a lisp DSL. Lisp lends itself surprisingly well to this, and defining game logic declaratively instead of imperatively is much more intuitive. Here are a few examples:
I haven’t used lisp is 30 years, so help me understand/remember why this would be easier than say C++ or any other language with object inheritance and virtual functions. Is there something else about it?
OO is absolutely the wrong paradigm for interactive fiction. Writing a text adventure has been my favorite way to experiment with a new language for decades now, and I’ve gone down the OO rabbit hole too many times. For this use case, you want something more like an ECS, so that a single entity can be more than one kind of thing at the same time. Consider a talking robotic vehicle. It is an object in the world: the player can interact with it from the outside. It is a room, with contents: the player can be inside it. It is an NPC: the player can speak with it. Trying to accommodate that in an OO inheritance hierarchy has always tied my code—and brain—in knots. An ECS-like architecture can handle it easily.
Sorry but Inform6, which itself is a distant cousin on methodology against ZIL and ZIL itself to Lisp, it's far better than CL for these kind of games.
The English (and Spanish library -grammar, object and token translations- with INFSP6) it's something else. Among Inform Beginners' Guide, with DM4.pdf you can set anything, even new grammars, or a Tetris, if you want to dwell into low-level Inform6 functions.
Inform6 gives you literal game objects and attributes for free. The most literal OOP language ever. And the generated ZMachine games/ROMs will run from a m68k Amiga to an Iphone.
Didn't read the article, but my first reaction to "How to program a text adventure in C" is to write a language / tool in C, and then use it to program the actual game much faster and safer. A Lisp-like a or a Lua-like language would both be relatively easy to implement.
Infocom was famous for using this approach, for instance.
Ha ha! The worst thing about PTSD is that you lose the ability to discern legitimate uses of strtok() ever after. Its older variant, post-traumatic goto disorder, is known to have affected prominent computer scientists in the past...
Many years ago (circa 1993) I ported the original Colossal Cave adventure by Crowther and Woods to TADS, a language created by Mike Roberts specifically for authoring text adventures. (Colossal Cave just came up recently here.)
https://ifdb.org/viewgame?id=c896g2rtsope497w
Graham Nelson ported my port to his Inform language, and Inform is probably your best choice if what you actually want to do is write a (plain text) adventure game.
If you want to learn C programming, writing a text adventure in C would be a fun learning project! But aside from pedagogy there’s no real reason to write a text adventure in anything other than Inform, TADS, etc. Not only is it much easier to use one of these purpose-built languages, with Inform you get multi-platform compatibility going back to the 8-bit era for free!
Personally if I had any free time, I’d be more interested in looking at how to use a frontier LLM like llama as an integral part of a text adventure. There was something like this using GPT-2 circulating on here a while back, but it was pretty rough.
However, it’s clear that if you figured out how to precisely control the LLM so it didn’t produce crazy stuff, you could realize the dream of truly realistic NPCs in these games. Text adventures would seem to be a perfect laboratory for experimenting with this.
cave is the first game i remember feeling immersed in. it was so good. its awesome you ported it!
Im playing with an LLM to remake drug wars. i pretty quickly changed it to more of a spiritual successor because i wanted to add more features and then had a hard time with them and the drug mechanic so i switched to financial trading and that made more sense. the i changed it to crypto coins in a dystopian future instead of stocks cuz the ascii art needed some lore to help flavor it now that gritty drugs were out
Just get dopewars
I wrote StoryHarp for creating speech-interactive choose-your-own text adventures back around 1998 (in Delphi for Windows desktop), and ported it to the web about seven years ago (with some limitations) using TypeScript and Tachyons: https://storyharp.com/v3.0
Realistically, StoryHarp might be most fun to use as an authoring tools for kids making short idiosyncratic adventures to share with friends. StoryHarp could help people practice creative writing and learn just a bit of logic to set up puzzles (without getting bogged down in more computing complexity like writing C code or even just the conceptual demands of TADS or Inform, as amazing as those tools are).
I recently added a option (inspired by "flems.io") where you can create a StoryHarp link that includes the entire world definition in the hash. For example, here is a URL for a game that just says "You are visiting the Hacker News website" when you click "look": https://storyharp.com/v3.0/#world=N4Ig7g9gTgNgJgMQJYwKYDkCGB...
Otherwise the game stores data only in the browser (not the server) which can be exported or imported as files.
While I can see how LLMs might make for more realistic interactions with text adventures, writing text adventures is its own sort of puzzle (like coding programs manually), and I am not sure adding LLMs will really make creating such adventures a much more joyful experience. But maybe it could. I agree in general though that text adventures make a great playground for experimenting with new ideas (as with StoryHarp as an experiment in bringing browser ideas from Smalltalk into interactive fiction design).
P.S. I just expanded that Hacker News story with a couple more rules so you can have more of an experience: https://storyharp.com/v3.0/#world=N4Ig7g9gTgNgJgMQJYwKYDkCGB...
Anyway, that is the sort of idiosyncratic short experiential interactive fiction I am talking about. Just spend five or ten minutes and make something that captures an emotion or a theme or a concern or an moral conundrum or whatever.
>8 bit
with Puny Inform6 or limiting Inform6, yes. If not, it's suicidal, even for v3 games. But, from Amiga and Atari machines, most v5 and v8 games if not all will run great.
You would probably do better on 8-bits by using ZIL which is actually feasible these days thanks to ZILF (and the leaked ZIL source code of the original Infocom games to look at).
Puny Inform it's good enough.
Some minor notes:
* Text adventures are a case where it is really advantageous to separate the declaration and definition of objects, since cycles are ubiquitous. For C, consider X-macros, tentative definitions (not in C++, sadly), and using the section attribute to make the list implicit (or if you don't want to rely on compiler voodoo, just output the index during another pass).
* It may be useful to distinguish several ways an object belongs to a location: on top of, contained in, held by, equipped by, integral component of, death drop of. Additionally, "has never been moved [by player? by code]" is often desirable to record.
* Backwards ownership is fine for savefiles and initialization, but during runtime it can be useful to cache lists in the other direction. A dict may be worth it in a few places if your adventure gets big enough, but linear search is fine for a long time (and makes e.g. conditional passages easier; you should simply check that every conditional transition is eventually followed by an unconditional one with the same tag. To ensure conditions are handled uniformly, transitions with multiple names should canonicalize first).
* For C statically-allocated arrays within a struct initializer, we've been allowed to write `(T[]){t1, t2, t3}` for a quarter century now. There's no need to name the separate objects.
* It is very useful for the runtime to support the notion of "overlays" - used for things like menus which can use surprisingly similar logic to rooms. Saves should only ever look at the main game layer.
* Relative directions are very interesting, but tricky to add to a game.
What I wish I had was an example of a game that is complete enough to be interesting but not too big, to be used when porting to a new engine.
I was wondering: does anybody know if there are any good resources for writing a good text adventure? Any nice tips and tricks? Mainly related to the content. I guess it overlaps with "writing a good novel", but I bet there're some specific advices that can be applied to the text adventure.
I wanted to write my text adventure, but I'd offer reader to have multiple options, especially for those who are not really practical with english (includes myself ^-^).
Aaron Reed's 50 Years of Text Games[1][2] is a fantastic journey into the history and the possibilities of text-based games. I got the physical book and was surprised to find it as engaging as a novel. Each chapter takes one year between 1971 and 2020 and picks a game from that year to discuss in depth. While it might not help with the writing per se, you might good ideas there (several of the games discussed are in the "Adventure" lineage).
[1] https://if50.substack.com/archive?sort=new
[2] https://if50.textories.com/
I can second this. I own the physical as well, has many pages going over the code used in the games being covered and why they were written that way.
For the technical side of things, use ink script. There's an editor, plugins and it's a mature project.
For the creative side I would recommend trying out all kinds of things. Should your player be able to get stuck/into a dead end? Will players play once or many times. Can you "win" your game or is it more of a narrative? How do you want the player to feel!
For some more specific ideas, think about how your game branches. Branching and decisions in games are far trickier than they might appear. Too subtle and the player misses the choice entirely. Too in your face and they become boring ("kill the baby" vs "save the baby", gee I wonder which one takes me down the evil path)
Also, merely asking a question or giving a choice can influence the player. If you ask "who is the killer?" and give a list of suspects, one of them must have done it, even if the player never considered it. The question also assumes the player knows there was a murder and gives that away if they hadn't worked it out yet.
Yeah, I like things like Ink a great deal. It's really easy to overcomplicate narrative design if you're not careful, but Ink (and so forth) do a good job of keeping things simple and staying out of your way.
I've spent the last three years building a game engine specifically to do this, and currently finishing the final draft for the game story I've created to go alongside it.
Happy to share anything you'd find helpful. The big takeaway for me has been, you're going to want to graph out the impact of choices before you write the story. If you know the flow of decisions, then that gives a much clearer structure than trying to write the story first and then create branches off it. I think the reason is that it sets a much tighter scope for the writing doing it that way, whereas if you write the story and then find ways to branch it, the scope for that is functionally infinite.
Got any specific questions?
The Inform Designer's Manual is mostly about Inform 6 programming, but has a lot of material on game design.
https://www.inform-fiction.org/manual/DM4.pdf
Crimes Against Mimesis was a famous tract in its day. I don't know how things have moved on since then.
https://www.rickandviv.net/index.php/2004/08/18/crimes-again...
Ron Gilbert's 1989 "Why Adventure Games Suck And What We Can Do About It" https://grumpygamer.com/why_adventure_games_suck/
Text adventures are not graphical adventures. Text games don't have the linearity and constraints of a graphical one.
Compare Anchorhead, Devours, Spider and Web... with most point and click games.
Gilbert's essay wasn't limited to graphical adventure games.
As some of the other comments allude to, the term of art for text adventure is "interactive fiction".
The Interactive Fiction Wiki is a nice place to start:
https://www.ifwiki.org/Main_Page
And if you search for something like "interactive fiction tips" you'll find tons of resources.
Slightly adjacent, I like these two blog articles that show ways to think about non-linear dialogues:
https://philipphagenlocher.de/post/video-game-dialogues-and-...
(introduces an interesting and useful way to think about dialogues, in my opinion)
https://philipphagenlocher.de/post/data-aware-dialogues-for-...
(further expands on the ideas of the first blog post, automatically ensuring that some properties that might be desirable)
Some good places to start:
- https://planet-if.com/
- https://intfiction.org/
- https://grumpygamer.com/why_adventure_games_suck/
- https://grumpygamer.com/puzzle_dependency_charts/
- https://ifarchive.org/
You can find many books on text adventures from the 1980s in the Internet Archive. The Inform manual has also quite a few tips and tricks.
I think for a lot of people here, the hard part of writing an adventure is not writing the code but coming up with a compelling game with an interesting story and readable text. My advice is that if you want to actually end up with an adventure game that people can actually play, just pick an existing authoring system that looks like it will do sort-of what you want and start writing.
I speak from experience when I say if you start by writing the engine then you will quickly become side-tracked with technical issues and never get your game done.
I can recommend ink if you want a choice-based game. It is super easy to get started and the language lends itself to extension if you find it doesn't do what you need out of the box.
What are some existing authoring systems that exist for this sort of thing? I know Ren’Py exists for visual novels
Inform is the big one for "GET LAMP"-style parser text adventures although I haven't used it for years.
For choice based text games there is Twine and ink (plus many others).
I personally used ink[0] for a project[1] and it was a joy to use. It comes with an IDE of sorts that makes just sitting down and writing your story easy before you add the bells and whistles.
[0] https://www.inklestudios.com/ink/
[1] https://sheep.horse/voyage_of_the_marigold/
I did once write a text-based adventure game in C, however I only did that to work out some of hte "plot" and the layout/objects I was going to work with.
My actual aim was to write a simple text-adventure in Z80 assembly, which could run upon a CP/M system. I did achieve that, and later ported the game to the ZX Spectrum.
A few years after that I used one of the inform-compilers to recode a couple of the puzzles in the Z-machine, which would also have allowed me to run the game on a CP/M system, but to be honest by that point I'd lost interest and I never ported the whole of the game's text, and the two different endings etc.
That said my toy adventure was popular when submitted here, back in the day:
https://news.ycombinator.com/item?id=26946130
I wrote a few MUDs in late 90s and early 00s.
LLMs would definitely make a more dynamic and lively world for NPCs. I can even see a place for dynamic quest building. But it isn’t going to produce a full world without a significant amount of prompting.
I do see how it can help write a lot of boilerplate (item descriptions, back stories, etc). A big thing I always wanted is memory and we worked a long time on it for tracking logic (footprints, hunting). Conversational memory is probably single biggest thing that excites me.
I have long wanted to make a procedurally generated text adventure that focuses on economics, information, and politics rather than spatial exploration. This gets complicated quickly, of course. Basic microeconomics and armchair psychology gets one a bit of the way there, but not enough to generate compelling dialogue and intrigue -- at least I have not been successful.
Does anyone know of good prior art in this space?
Kind of sounds like Drug Wars for the TI-86+
Section 9 - Code Generation uses awk to parse a text file to generate c files. Very nice.
I honestly think that writing an adventure can be best done by first creating an adventure-writing DSL (in C, if you like).
A few observations on the C code (I didn't read all of it):
- please, no strtok
- a little more concentration on the UI, for example not using strcmp to test inputs
- make all preprocessor definitions be uppercase
- those conditional operators confused the hell out of me - just use if/else
I am going to have nightmares from 30 years ago about writing an ANSI color parser. Or text serialization to hand jammed file formats.
Just use _s for each stdlib function
The best way to implement a text adventure in C would be to implement a simple lisp interpreter in C and then implementing the actual game in a lisp DSL. Lisp lends itself surprisingly well to this, and defining game logic declaratively instead of imperatively is much more intuitive. Here are a few examples:
[1] http://www.ulisp.com/show?383X
[2] https://github.com/mswift42/MetalHead
[3] https://github.com/xlxs4/lisp-spels/blob/main/spel.el
I haven’t used lisp is 30 years, so help me understand/remember why this would be easier than say C++ or any other language with object inheritance and virtual functions. Is there something else about it?
OO is absolutely the wrong paradigm for interactive fiction. Writing a text adventure has been my favorite way to experiment with a new language for decades now, and I’ve gone down the OO rabbit hole too many times. For this use case, you want something more like an ECS, so that a single entity can be more than one kind of thing at the same time. Consider a talking robotic vehicle. It is an object in the world: the player can interact with it from the outside. It is a room, with contents: the player can be inside it. It is an NPC: the player can speak with it. Trying to accommodate that in an OO inheritance hierarchy has always tied my code—and brain—in knots. An ECS-like architecture can handle it easily.
Thanks - I hadn’t heard of ECS before. That expanded my mind :)
Or replace large part of this code with lex and yacc and stick with C.
That's like saying the best way to drive to New York is to drive down the block to the train station and then take a train lol
Which, generally, is true.
Sorry but Inform6, which itself is a distant cousin on methodology against ZIL and ZIL itself to Lisp, it's far better than CL for these kind of games.
The English (and Spanish library -grammar, object and token translations- with INFSP6) it's something else. Among Inform Beginners' Guide, with DM4.pdf you can set anything, even new grammars, or a Tetris, if you want to dwell into low-level Inform6 functions.
Inform6 gives you literal game objects and attributes for free. The most literal OOP language ever. And the generated ZMachine games/ROMs will run from a m68k Amiga to an Iphone.
[dead]
Didn't read the article, but my first reaction to "How to program a text adventure in C" is to write a language / tool in C, and then use it to program the actual game much faster and safer. A Lisp-like a or a Lua-like language would both be relatively easy to implement.
Infocom was famous for using this approach, for instance.
LucasArts, too, with their SCUMM system.
This is all one really needs to program a huge hit game in 2025.
DOOM is essentially a text adventure but with fewer keywords.
I thought it was going to be something like this: https://github.com/dfremont/glulx-llvm
I thought it was something like LPMud or MudOS [0].
[0] https://mud.fandom.com/wiki/MudOS
Oh man, I got PTSD (post traumatic strtok disorder) on page two and rage quitted the page.
I've lost too many hours to bad stdlib APIs.
Ha ha! The worst thing about PTSD is that you lose the ability to discern legitimate uses of strtok() ever after. Its older variant, post-traumatic goto disorder, is known to have affected prominent computer scientists in the past...