How to make an AI text adventure
The same phrase covers two completely different projects, and most people start the harder one by accident. The difference is whether the model runs while somebody plays.
Jump to a section
Decide first whether the model runs while somebody plays. If it does not, you are building a normal text adventure that a model happened to write, and it is one file that works for ever. If it does, you are building a service with running costs and a key you cannot safely put in a browser.
An API key in a browser game is a public key. Anyone who opens the page can read it and spend your money, and no amount of obscuring it in the JavaScript changes that. Runtime AI therefore needs a server of your own in front of it, which is the moment a weekend project becomes an ongoing one.
The two kinds, side by side#
| Written by AI | Powered by AI | |
|---|---|---|
| What runs in the browser | The whole game | A front end that calls your server |
| What it costs to run | Nothing | A little money on every turn, from every player |
| Works offline | Yes | No |
| Same story twice | Yes, which makes puzzles possible | No, which makes puzzles hard |
| Remembers hour one at hour three | Yes, because the world is data | Only what you feed back in |
| Can be published as a file | Yes | No |
The last row is the practical one. A game that needs your server is not something somebody else can host, play offline or keep.
Most people want the right hand column and describe the left one, because the phrase sounds like the model is doing the storytelling live. If you want a game that other people can play without you paying for it, the model should do its work before anybody arrives.
Building the kind you can ship#
Rooms, items and the text for each should be one object you could print out. A story written as branching code cannot be edited by you or by the model without breaking something.
The first thing to test is not the story, it is what happens when you type something the game does not know. That path is used more than any single room.
A text adventure gets better by having more to find. It gets worse by acquiring combat, hunger and a crafting tree in the third message.
Build a complete text adventure as ONE self-contained .html file.
No frameworks, no images, no network calls of any kind at runtime.
SHAPE: a scrolling transcript with an input line at the bottom. Typed
commands only. Dark background, one readable serif, generous line height.
THE WORLD: a flooded lighthouse on a winter coast, eight rooms. The
player is looking for the keeper. Exactly three items matter: a lamp, a
brass key and a logbook. Everything else is scenery with a description.
STORE THE WORLD AS DATA: one ROOMS object, one ITEMS object, one flags
object. Every room names its exits and which flag, if any, blocks each
one. Do not write the story as branching code.
PARSER: accept "n", "north", "go north", "look", "x lamp", "take key",
"use key on door", "inventory", "verbs" and "help". On an unknown word,
say which word was not understood and suggest the closest known verb.
Never consume a turn on input the parser did not understand.
ENDING: finding the keeper ends it, with a short closing passage and a
count of rooms visited. One command restarts without reloading the page.
SAVING: put the flags object and the current room in localStorage after
every successful command, and offer to resume on load.
Put every tunable number and all the prose in clearly marked places near
the top so I can rewrite the text without touching the logic.Change the world paragraph and leave the rest. The instruction to store the world as data is what lets you ask for ten more rooms later without the model rewriting the parser.
The parser is the whole experience#
Players do not experience your world directly. They experience the gap between what they typed and what happened. A beautiful room described in four sentences is wasted if take the lamp returns a shrug when take lamp would have worked.
Resist natural language understanding here, even though a model will happily offer it. A short, published list of verbs that always work is kinder than a clever parser that usually works, because the player can learn the first one and cannot learn the second.
For how the world behind the parser should be organised, including flags and dialogue that remembers, the adventure guide covers it properly and this article will not repeat it.
If you really do want the model running live#
There are good reasons to want it. A world that answers anything is a feeling no scripted game gives you, and it is why this genre keeps being reinvented. Go in knowing the four things that decide whether it works.
- The key cannot be in the page. You need a small server of your own that holds the key and forwards requests. Anything else is publishing your billing details.
- Somebody pays per turn. Every player costs you money for as long as the game exists. Decide whether that is you, and what the cap is, before anybody plays.
- Memory is your job. The model does not remember the game. You keep a summary of what has happened and send it every turn, and the quality of that summary is the quality of the game.
- Puzzles get difficult. A puzzle needs a fixed answer, and a world that improvises will cheerfully accept a solution you never designed. Most of these games end up being atmosphere rather than challenge, which is fine if you choose it.
A good middle path exists: generate the world with a model once, at build time, then ship it as a fixed game. You get prose you did not have to write and a file that costs nothing to run.
📜Adventure games on this site
Opus 5.5
GPT-6 AstraGPT-6 AstramultiFable 5.1Fable 5.1GPT-6.1 SolOpus 5Opus 5GPT-6.1 SolOpus 5Fable 5.1OpenAI CodexCommon questions#
What is an AI text adventure?
Either a text adventure a model wrote for you, which then runs on its own like any other game, or one that calls a model on every turn to improvise what happens. The two have almost nothing in common except the words on the screen.
Can ChatGPT or Claude write a text adventure I can play in a browser?
Yes, and it is one of the things they do best, because a text adventure is mostly prose and a small amount of logic. Ask for the world as a data object rather than as branching code, or you will not be able to extend it afterwards.
Can I put my API key in a browser game?
No. Anything the browser can read, a player can read, including keys hidden in minified code or fetched from another file on the same site. A live model needs a server of yours in front of it that holds the key.
Why does my AI dungeon game forget what happened?
Because nothing is storing it. The model only sees what you send in the current request, so memory is something you build: keep a running summary of events and inventory, and send it with every turn.
Is a text adventure a good first game to make?
Yes. There is no animation, no physics and no timing, so almost everything that normally goes wrong in a first build cannot happen. The work is in the writing and the parser, which are both things you can judge without reading code.
How many rooms should a first text adventure have?
Six to ten. Enough to get briefly lost, few enough that you can write every description properly. Adding rooms later is easy when the world is stored as data, which is the main reason to insist on that from the first prompt.
Where to go next#
For the state machine behind the prose, read how to make an adventure game with AI. If the project is growing stats and combat, the RPG guide covers the order to add them in.
When somebody else has finished your lighthouse, publish it. A text game needs no cover art to be worth playing, and the page records the model and the prompt that produced it.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next