🗺️ Guide

How to make an adventure game with AI

An adventure game is a world described as data plus one object holding what has happened. Get that object right and a handful of rooms feels like a place.

Updated 5 October 2026 7 min read By the Agent Games team

Jump to a section

Four steps to a world that remembers you
One flags object, and everything reads from it
A world described as data, not as code branches
Dialogue options that declare what they need
Why the player must see what they are carrying
Common questions
Where to go next

Ask for rooms you can walk between and one flags object holding everything that has happened. The rooms are the easy part. A first build hands you a map and a character who greets you the same way forever. What turns that into an adventure game is the world changing because of something you did.

Rooms are cheap. Memory is the game.

Any model will draw you a map in one answer. Very few will write state that holds together once the map grows. Decide before you prompt that exactly one object stores what has happened, and that every room, door and spoken line reads from it. The rest of the design follows from that choice.

Four steps to a world that remembers you#

Paste the prompt below and walk the map

It writes rooms, a character who walks, items on the floor and conversations that check state, all in one file.

Try a door you have no key for

The refusal should name the thing you are missing. A door that goes quiet teaches the player nothing and reads as a bug.

Help somebody, then talk to them again

If the second conversation is the first one repeated, no flag was set. That is the fault to fix, before a sixth room exists.

Only then write the story

Room names and dialogue are quick to change once state works. Story written over broken state gets written twice.

PromptCopy this, paste it, send it

Build a small top down adventure game as ONE self-contained .html
file. No frameworks and no images. Draw the rooms with canvas shapes.

WORLD AS DATA: a ROOMS object. Each room has a name, a colour, a set
of exits, items lying on the floor and the characters standing in it.
The drawing code reads that object. Rooms are not branches in code.

STATE: one flags object, empty at the start. Everything that has
happened lives in it. Doors opened, people helped, notices read, items
carried, and the room the player is standing in.

GATES: an exit may carry a requires field naming one flag. The player
cannot use that exit until the flag is true. While it is shut, the
game says out loud which thing is missing.

DIALOGUE: each character has an ordered list of lines. A line may have
a requires field and a sets field. Show the first line whose requires
is satisfied, most specific first. Taking a line sets its flag. A
character the player has helped must never greet them as a stranger.

OPTIONS: when a line offers choices, each choice carries its own
requires field, and a choice the player cannot satisfy is not drawn.

INVENTORY: a strip along the bottom listing what is carried, on screen
at all times. Walking onto an item picks it up and sets its flag.

PLAYER: arrow keys or WASD walk. One key talks to whoever is nearest.
Choices are numbered and also clickable.

SAVING: write the flags object to localStorage whenever it changes and
read it back on load, so a reload resumes the same world.

PHONE: dragging on the canvas walks the player. Include
canvas { touch-action: none; } so dragging never scrolls the page.

Move the player by however many seconds passed since the previous
frame, and clamp that figure so it can never exceed 0.05. Keep walk
speed, room size, talk range and item size in one CONFIG object at the
top of the script, each with a comment.

Change the ROOMS object and the dialogue lists as much as you like. Leave the three state paragraphs alone. STATE, GATES and DIALOGUE are the only reason this build behaves differently from a first attempt. A model will quietly fold them back into local variables if you give it the chance.

One flags object, and everything reads from it#

Scattered state is the fault behind most of a first adventure build. The door keeps its own boolean. The dialogue keeps a count of how often you have spoken. The inventory is an array nothing outside the inventory panel can see. Each piece works alone. None of them agrees with the others.

So the smith you brought a key to says I do not know you, and the cellar door you earned stays shut. Nothing is broken in the usual sense. The code simply has no single answer to the question the game is about, which is what has the player done so far.

The right hand side is one line longer to write and is the difference between a map and a world. Ask for it in the first prompt, because retrofitting it means touching every conversation.

A flag is a name and a true. Nothing more. cellarOpen, metSmith, readNotice. Keeping them all in one object has a second payoff that is easy to miss: saving the game becomes one line, because the flags object is the save file. Loading it back is the same line in reverse.

A world described as data, not as code branches#

Ask a model for an adventure game without saying how to store the world and you tend to get a function per room. Each one prints its own text and checks its own conditions. Adding a room means writing another function, and changing the rules means editing every one of them.

jsThree rooms and one character. Every rule in this world is a field, so a new room is a new entry and nothing else changes.

const ROOMS = {
  yard: {
    name: "The yard",
    exits: { north: "hall" },
    items: ["rustyKey"], people: [],
  },
  hall: {
    name: "The hall",
    exits: { south: "yard",
             down: { to: "cellar", requires: "cellarOpen" } },
    items: [], people: ["smith"],
  },
  cellar: {
    name: "The cellar",
    exits: { up: "hall" },
    items: ["lantern"], people: [],
  },
};

// Most specific line first. The first satisfied line wins.
const SMITH = [
  { requires: "smithHelped", text: "Thank you. The cellar is yours." },
  { requires: "rustyKey",    text: "That key is mine. Hand it over?",
    sets: "smithHelped" },
  {                          text: "I do not know you." },
];

Two things make this shape worth asking for by name. One movement function handles every exit in the game, so a bug in the gate logic is one bug rather than one per door. And you can read the whole world out loud. If the data says the cellar needs cellarOpen and nothing in the game sets that flag, you can see it before you play.

It also makes the model more useful to you. Add a locked gate between the hall and the garden that needs the lantern is a change to one object. The model does not have to understand your movement code to make it, so it is far less likely to rewrite something that already worked.

Dialogue options that declare what they need#

A dialogue tree is the usual answer and it is the wrong one here. Trees grow a branch per combination, so three flags give you eight paths to keep straight. A flat list where each line declares its own condition grows by one entry instead, and the order of the list is the priority.

Most specific line first. Walk the list and take the first line whose requires is satisfied. The last entry has no condition, so there is always something to say.
A choice the player cannot meet is not shown. Do not grey it out. A greyed option tells the player exactly what secret they have not found yet, which is worse than silence.
One line, one flag. A line that sets three flags is a line you cannot reason about later. Split it.
Say the state out loud while testing. Ask for a debug key that prints the flags object on screen. Most apparent dialogue bugs are a flag that was never set, and you cannot see that from the dialogue.

This is also how you avoid the quiet failure where a character has nothing left to say. Keep a final unconditional line per character, written as something they would repeat. A smith who says mind the step forever is fine. A smith who says nothing at all looks broken.

Why the player must see what they are carrying#

An adventure game asks the player to remember things, so it has to be honest about what it has given them. Without a visible inventory they stand at a gate with no idea whether the key is already in their pocket. That is not difficulty. It is the game withholding its own state.

All five of these are flags in the same object, which is why one panel can show what is carried and one line can save the whole game.

Keep it a strip along the bottom rather than a panel behind a key. Something hidden behind a key gets checked once and then forgotten, and you will watch a tester walk past the answer. On a phone the strip earns its space twice over, because tapping an item is the only way to use it.

Two small rules keep it readable. Show items by name, not by icon, until you have art worth looking at. And never silently remove something. If handing over the key consumes it, say so in the line that takes it, or the player will assume the game ate their item.

🗺️Adventure games written by AI

Voxelcraft — 3D Block Builder

Common questions#

Can AI make an adventure game?

Yes, and the code is rarely the hard part. A model will write rooms, walking and conversations in one answer. What it does not do unprompted is keep one honest record of what has happened, which is the thing that makes the rooms add up to a world.

Why does a character I helped greet me as a stranger?

The dialogue has no access to the fact that you helped them. Ask for an ordered list of lines per character, each with a requires field naming a flag, and show the first line whose flag is set. The greeting then sits last, as the line used when nothing else applies.

Why is my locked door still locked after I find the key?

Two separate pieces of state, each correct on its own. The inventory recorded the key and the door is reading something else. Both belong in the same flags object, and the door should check that object directly rather than being told by whatever handled the pickup.

How long should a first adventure game be?

Short enough that you can walk the whole thing while testing. Three or four rooms, one gate, one character who changes. If that holds together you can add rooms for as long as you enjoy it, because by then adding one is a new entry in a data object.

Should it be text or graphics?

Either works, and the state problem is identical in both. Drawn rooms give you something to look at and a reason to use a canvas. Pure text saves you every drawing question and lets you put the effort into the writing. Pick whichever you will actually finish.

How do I save progress?

Write the flags object to localStorage whenever it changes, and read it back on load. That is the whole save system, and it is only one line because every piece of state lives in one object. Include the current room so a reload puts the player back where they stood.

Where to go next#

When somebody else can finish your world without you sitting next to them, publish it. It gets a page of its own recording the model and the prompt behind it, and other people can walk through what you wrote.

The general method is in how to make a game with AI. If your world is growing stats and combat, the RPG guide covers the order to add them in, and the prompt guide has wording for common faults. The adventure games here are the fastest way to see how much a few rooms can carry.

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.

Publish a game