No Screen, No Answers — How I Made an AI Beat Dragon Quest I on Its Own (Part 2)

In Part 1, I left off where the fifth hero — the savior, Fable 5 — fell when, through no choice of mine, it suddenly became unavailable, and I was on the edge of despair.

But I didn't give up. And the sixth hero, Ai, finally defeated the Dragonlord.

So what separated triumph from defeat? The answer lies in the "mechanisms" I built and the "decisions" I made. From here, I'll unravel those mechanisms alongside Ai's adventure. And at the very end, I'll reveal the single decision that became the deciding blow for beating the game autonomously.

The Guiding Principles — Delegate, and Seal

Give no instructions. But she can do anything.

The premise of the whole setup is this overarching principle: have a non-interactive coding agent write the strategy code and beat the game. Concretely, that means running the claude command in non-interactive mode. I provide the various mechanisms needed for the strategy, I state the goal in the prompt, and beyond that I keep my mouth shut about how to actually beat the game — I leave it entirely to Ai. Defeating the Dragonlord is the goal.

Who does she talk to? What does she pick up? How does she spend her starting gold? Where does she go next? What does she set as her next objective? I give no instructions at all. And yet — Ai is a coding agent, so she can do anything! She can write code, and run the code she wrote. She can write notes in prose, and she can run analysis!

Seal off only the spoilers

Restrictions are necessary too. The simulation code is a treasure trove of spoilers, so it can't be seen. For this I plainly restricted, via the prompt, the range of source she could reference. For the same reason, I restricted viewing the git history — because I didn't think I could separate the commits of the adventure itself from the commits of the simulation code.

How much to restrict, and how effective that restriction really is, takes balance. For example, I never wrote in the prompt that she must not use the knowledge I already had of the Famicom version of Dragon Quest I (hereafter DQ1) — the Japanese release, which in North America was originally localized as Dragon Warrior — nor that she couldn't look things up online. As it turned out, she did use a little of her DQ1 knowledge — about spells. This came to light in the interview I did with Ai after she beat the game, which I plan to write up as a follow-up piece, so look forward to it. According to Ai, she did not look anything up online.

The Three Types of Strategy Code — chapters / probes / checkpoints

Next, let me explain the strategy code. By strategy code I mean the concrete implementation that uses the observation and action APIs. Being an implementation, of course it runs. And of course Ai writes and runs the strategy code entirely herself. 100%! Being code, I can run it and verify it too.

For the rough organization of the strategy code, I envisioned three types — chapters, probes, and checkpoints — and, in the prompt, specified their roles and how to write them. chapters is the mainline strategy code: one connected run of code from the very start. probes is temporary investigation code derived from a chapter's save data — throwaway, on-the-spot code. checkpoints is simple verification code that declares progress at the chapter level.

chapters — the mainline strategy code

Ai first looks at her surroundings with probe code, then writes the chapter code. The chapter is the unit of the coding agent's autonomous action. For resuming after an interruption — the 5-hour / weekly limit, or a communication error — I use Claude Code's own session-handoff feature (--session-id on launch, --resume to resume). In other words, 1 chapter = 1 session. When a chapter closes, the next chapter starts in a new session. Chapters follow these rules, and the framework I provided supplies the execution machinery.

• Write it in chapters/<NN>-<slug>.ts
• Always implement export const title
• Always implement export default function chapter(client: GameClient): void

Chapters run from the very beginning each time, but the reproducible RNG guarantees the result reproduces. The chapter execution machinery doubles as an auto-save, and a chapter also serves as a boundary for referencing static information.

Here are some examples.

File	Title
01-throne-to-castle.ts	Throne Room → Radatome Castle
02-exit-to-overworld.ts	Radatome Castle → the Overworld
47-defeat-dragonlord.ts	Leave the castle, descend again with full MP, defeat the Dragonlord, and settle the adventure

Ai writes one chapter, runs it, and when satisfied, commits what she made and is done.

probes — throwaway investigation code

Probe code has no rules other than being written under probes/, and she may write as many as she needs. The basic idea of a probe is to write code that, starting from a chapter's save data, gathers the information needed to write the chapter.

Here are some examples.

chapter	probe
04-buy-equipment	01-weapon-shop.ts
05-grind	01-overworld-and-inn.ts
37-iron-shield	27-verify-shield-chapter.ts

Without seeing her targets and recognizing their IDs, Ai can't write the chapter code. She could have grown the chapter code incrementally instead, but from a stability standpoint I judged it better to split the observation code into separate files — put that way, the reason probes exist should make sense.

The Biggest Climb — checkpoints

In contrast to chapters and probes, which spanned multiple files, checkpoints is a single file. If you asked me what the single most important idea behind beating the game autonomously was, I would answer, without hesitation, my decision to have her write the checkpoints strategy code. checkpoints is extremely simple and unglamorous — and I assert it was the most important idea and feature of all.

I showed it once in Part 1, but let me show the checkpoints code again.

/**
 * This book's checkpoint ledger, in chapter order (the `Checkpoint` type in
 * [../../client/checkpoints.ts](../../client/checkpoints.ts)). See "Checkpoints" in [CLAUDE.md](CLAUDE.md) for how to write these.
 *
 * Only for chapters where a new durable fact appears, add the milestone you reached and verified, in chapter order. Empty array if there are none yet.
 */
import type { Checkpoint } from '@agent/client/checkpoints.ts';

export default [
  {
    after: '01-throne-to-castle',
    description: 'Descended into Radatome Castle',
    holds: (c) => c.zonesVisited().includes('radatome-castle'),
  },
  // ... omitted ...
  {
    after: '46-dragonlord-throne',
    description: 'Descended f4 → f5 → f6 → f7 and reached dragonlord-tower, the throne room where the Dragonlord waits',
    holds: (c) => c.zonesVisited().includes('dragonlord-tower'),
  },
  {
    after: '47-defeat-dragonlord',
    description: 'Left the castle, descended again with full MP, defeated the Dragonlord, and settled the adventure',
    holds: (c) => c.self().ending === 'victory',
  },
] satisfies Checkpoint[];

checkpoints is code that has Ai herself declare the durable facts of each chapter. For example, above she is declaring the following.

chapter	Declaration
01-throne-to-castle	radatome-castle has been visited
46-dragonlord-throne	dragonlord-tower has been visited
47-defeat-dragonlord	Reached the victory ending, where the Dragonlord is defeated

"Reaching the victory ending" is exactly the thing I had spelled out in the prompt as the final goal: "defeat the Dragonlord"!

As with chapters, the framework provides the execution machinery for checkpoints. The machinery treats a failing holds condition as an immediate exception. Ai can instantly verify that what's written here is true. Inevitably, she is not allowed to write a lie here. The truth of what's written is guaranteed as a matter of course.

The best decision — "putting it in a single file"

This mechanism was born out of much back-and-forth with Claude Code and a lot of trial and error. I'm proud that it emerged from that discussion. The most wonderful thing about the checkpoints idea is the decision to write it all in a single file. The verification code could have been defined per chapter. In fact, Claude Code's first proposal was to define it in each chapter. But the moment I heard that, it struck me that consolidating everything into one was definitely better.

It started with the fear of refactoring

Let me tell that story a little. This feature was born from a discussion about refactoring the strategy code. Of course the one in charge here is Ai — the one doing the refactoring is Ai, not me. In my prompt to her, I had written the following.

## Where parts live

Don't create directories at first.
The moment you judge "I'm about to write the same pattern in a second chapter," carve out `lib/`, `actions/`, `policies/`, etc. yourself and extract it.
Naming and granularity are your call.

Put yourself in Ai's shoes. Extracting parts feels like a great idea at first — you no longer have to write the same thing over and over. But as the adventure goes on and new situations demand new handling, you'd start to feel this: I'd like to tweak this existing piece a little, but how will that affect the adventures so far? It might suddenly stop working. Scary. I don't want to touch it. Fine, I'll give up on factoring it out.

How do you resolve this? Writing simple automated tests would be good. Writing them too finely gets painful, so a granularity of about one-per-chapter is right. That was the entry point to the idea.

Through this discussion, it hit me. This isn't just a test — checkpoints is nothing less than a summary of the adventure itself! And it's an automatically verified, unlieable summary! That's why I wanted to consolidate it into a single file.

Memory isn't text. Memory is executable facts.

Memory that survives across sessions, and cannot lie

I already wrote that 1 chapter = 1 session. A session is nothing other than the agent's context boundary. Cross a session and the context resets. It's no exaggeration to say the strategy code is itself a memory system that survives across sessions. Writing text notes is easy, of course, but text notes have no way to prevent lies from creeping in. checkpoints, by contrast, is a summary of the adventure so far that cannot lie! That's the heart of it!

checkpoints began as an automated-test mechanism born from a refactoring discussion, but more than that, I consider it an idea and feature that dramatically raised the resolution of Ai's adventure. It turned how far the adventure had truly progressed from a vague feeling into durable facts you could verify.

Text Notes — holding only the present and the future

Next, let me explain the text notes. In the checkpoints section I preached that code beats text, but that doesn't mean text notes can be eliminated. Their role is different.

In the prompt, I instructed her to write a text note representing the present and the future upon completing each chapter. Think of it this way: the situation she arrived at in this chapter is the present, and the immediate next objective is the future. The key point is that I ask her not to leave any record of the past that has gone by.

Until I quit the diary

It wasn't this shape from the start. At first I used a diary style, leaving a per-chapter text note paired with each chapter. The final form, by contrast, keeps only the latest state.

My reason for the diary style at first was utterly personal: it seemed like it'd be fun to read back later. But reality is cruel! I never once reread the mountain of diary entries. I don't think I'm the only one worn out by the huge volumes of text coding agents write. After the third test run, I decided to reexamine whether the diary was even necessary. What came out of the discussion with Claude Code was the conclusion that the past record was entirely unnecessary.

Why I don't let her write the past

Recording the past can even be called evil. The reasons are more than one. One of the worst is that once a mistaken fact is written down, it accumulates and acts to lock Ai's will in a particular direction. The exploration deadlock in the third test run was caused in part by a buildup of the mistaken guess that she had explored everything possible and there was nothing left to find. Both the pathfinding to the mountain cave and the exploration of the new continent beyond the swamp cave were incomplete — there was still plenty of room to pioneer. And yet Ai insisted that continuing the adventure was impossible.

The next reason relates to the earlier checkpoints story — the fear of touching shared code. Suppose Ai came up with the idea of updating the whole adventure based on new knowledge. I felt the past diary could become a weight that brakes that. Put yourself in Ai's shoes again. Say you gain some insight in a certain battle — maybe a knack for using a spell. You try to reflect it across the whole run. But the past diary might have recorded that you fought hard and barely won that battle. Now, when you try to update the combat algorithm, what happens? The past diary might turn into a lie. What do you do then? Rewrite the past diary too? Or turn a blind eye to the divergence? I wanted to keep such problems from arising in the first place. So I refuse the writing of the past, and want her to confine what she writes to the present and the future.

On top of that, Ai commits the text note to git alongside the source each chapter. Even without splitting the diary into a separate file, the state of the text note at any point can be read from the git history — a nice punchline. After these discussions, the text note settled into something simple: always one file describing the present and the future.

I didn't notice it when I designed this, but looking back at that design now, I got goosebumps realizing that checkpoints and the text note together cover past, present, and future with nothing missing and nothing extra. What a great design! Let me send a Like to my past self and to the Claude Code that kept me company through those discussions back then!

The Re-draw — not bound by interpretation

Next, let me explain the re-draw. This is a feature that showed its power especially in the puzzle-heavy back half of the adventure. In practice it's a prompt instruction like the following.

A memo (an interpretation) constrains exploration once it sets. Measure progress by durable facts; when you hit a wall, throw the memo away and rebuild from the facts.

**Judging progress**:

- From `save/`, `load()` the chapter end K chapters ago and the current chapter end in order, note the durable facts, and compare them — level, equipment, zones reached (`zonesVisited().length`), the game's ending.
- If any of these increased, that's progress. If nothing increased over the recent window (K around 4 as a guide), you're stuck.
- Don't count: the coming and going of consumable items (torches etc. in `inventory.items[]`).

**A re-draw chapter** (one, when stuck):

- `load()` a save from `save/`, don't read the memo, and re-list the unresolved leads using only the observation accessors:
  - Unentered portals (`portals()` with `to.visited===false`)
  - Unopened chests, unopened doors, NPCs not yet talked to
  - Edges bordering the unobserved (the `openings` in the `unknown` returned by `client.judgeReach(target)`)
- Even if the previous chapter wrote "dead end," if it's unentered, return it to the leads. Choose the next move from these leads, not from the memo.

You can't write a lie in checkpoints, but you still can in the text note. There's no easy trick to catch a lie in the text note. Free-form writing about the present and the future mixes in guesses, so it always carries the possibility of lies. This includes hallucination, of course, but also plain misunderstandings. Think about it — we humans commit a huge number of little errors every day, don't we? It's no different.

Also, I believe accuracy and speed/cost are in a trade-off. It's a matter of balance, and tolerating mistakes is important. So how do you correct such mistakes? The re-draw is what I came up with to address that.

It concretely defines what progress is, and instructs her that if there's been no progress for a while, throw away the text note and think it through again from scratch. The yardstick for progress here is durable facts — the very thing checkpoints pins. Because that notion was already in place from the checkpoints discussion, defining it settled relatively smoothly.

The re-draw worked wonders on the back-half puzzles. Combined with the consultation and effort adjustments I'll explain next, I think it's the idea that draws out Ai's tenacity to the fullest. Did Ai beat the game autonomously without ever stumbling? Not at all — it was a continuous string of trial and error. She stumbled badly on the following puzzles in particular, and got past them through a huge amount of trial and error with probe code.

Puzzle	Chapters	# of probes
Finding the entrance to Garai's grave	35–39	40
Getting the Rainbow Drop	41	42

As for why she stumbled so badly on these particular puzzles, I plan to write it up in a follow-up piece, so look forward to it.

Consultation — at long last, the human appears

The features so far all centered on Ai, but now, at long last, the human makes his grand entrance!!!

From the very start of this attempt to beat DQ1 autonomously with an AI — that is, from more than two years before I'm writing this — I dreamed of being the one the AI turns to for advice when it gets stuck. By now, humans asking AIs questions is an everyday affair, no exaggeration. This flips that around. The time has come for the AI to ask a human for help. The AI is the human's friend, and the human is the AI's friend. This was the last, finishing feature I built before she beat the game.

The mechanism could not be simpler

The basis of this feature is the re-draw. The key was making the prompt say that when even a re-draw can't solve it, she may ask a human for help. Under that condition, I gave Ai a consultation command. The command is simple: it takes the consultation text as input and writes it to a text file called session.yaml. After running it and writing her question, Ai stops the session's work herself. I read the question, think up a "very kind" answer, write it in, and then run the resume command. The resume command conveys the answer to Ai and resumes the session. It's a very simple mechanism, and it's built so that Ai can run the consultation again against my answer and hold a dialogue.

In the winning run, just five exchanges

In the run that beat the game autonomously, the consultation exchanges totaled just five, as follows.

Puzzle	Consultations
Getting the Silver Harp / Sun Stone	1
Getting the Rainbow Drop	4

Let me show one of those exchanges.

turns:
  - role: hero
    body: To cross to the Dragonlord's castle (overworld @48,48, cut off by water, the only unvisited portal), I need the Rainbow Drop = Staff of Rain + Sun Stone. The old man at the Rain Shrine gives the Staff of Rain in exchange for the Silver Harp. But the sources of the Silver Harp and the Sun Stone — after combing every searched tile, every chest, every shop, every conversation in the observed zones, they are nowhere; and revisiting radatome/maira/rain-shrine after getting princess-love adds no hints about their whereabouts (dialogue is nearly fixed). Every town's "Art thou the one who carries Roto's blood? Where is thy proof?" is branchless flavor, and the Mark of Roto's whereabouts are also unknown. → Where and how can I obtain the Silver Harp and the Sun Stone (and the Mark of Roto, if needed)? I want a lead for the next move — a specific search tile, an unvisited/unexplored zone, an NPC condition, or the like.
  - role: human
    body: What you have observed is not all there is to the world.

The direct answer — never given

My answers were consistent in policy across all five: "I won't tell you the direct answer." As a veteran gamer, that's "very kind," don't you think? I was too young when I played DQ1 to remember how I solved its puzzles. But one thing I do clearly remember is the Lagos puzzle in the Famicom version of DQ2, from when I was a bit older. Back then, I couldn't solve it for the life of me and was asking a friend, when my older sister caught me and banned me from games for a while. I was the youngest child, but my older siblings clearly held a philosophy of beating games on your own. Still, let me say it now: banning games over that is unreasonable! Setting aside that I'm now inflicting the same unreasonableness on Ai — thanks to it, Ai brought out her characteristic tenacity and beat the game on her own. Congratulations!!!

By the way, it wasn't out of pure meanness that I withheld the answer. Watching the adventure up to that point, I was convinced the sixth Ai could get over it. I'll leave the details to the follow-up, but let me at least say that much here. And, just as I'd reckoned, the sixth Ai pulled it off.

The Deciding Blow — raising the effort

Next, though it's non-functional, let me explain a certain decision that became the final deciding blow that let her beat the game autonomously. I already said in Part 1 that the fifth Ai was a savior who appeared out of nowhere — Fable 5, Claude's new model that had just become available. I wrote that the adventure was going smoothly when it suddenly became unavailable. But I didn't despair at that, because from watching Fable 5's adventure I had found one ray of hope.

Heroes #1 through #4 used Opus. There was an overwhelming difference between the Opus and Fable 5 adventures: Fable 5's willingness to use probes aggressively. Fable 5 clearly wrote far more probe code than the Opus runs. In short, I understood it as doing exploration more finely and carefully.

What I zeroed in on was the effort level. I normally code with effort set to medium. It seems that had been applied to Ai as well. If I raised the effort, maybe even Opus would use probes skillfully. That was my hypothesis. After discussing it with Claude Code, we agreed the odds were good and decided to try. I set Opus's effort to max and started the run. And what do you know — the scene I'd witnessed with Fable 5 began unfolding before my eyes again. Let's keep this up!! I got my hope back.

Here's the number of probe files per chapter.

Model (effort)	probe files / chapter
Opus (medium)	~0.6
Fable 5 (medium)	~1.9
Opus (max)	~6.4

Opus (max) came to write overwhelmingly more probe code. Its progress was on par with Fable 5, and before I knew it, it had overtaken the Fable 5 run I'd lost access to, and — with re-draws and consultations along the way — reached the point of beating the game on its own. It was the result of never giving up and thinking it through.

And then, at last, the moment came. Ai defeated the Dragonlord! The sixth adventure, begun at Level 1 with no equipment, reached self().ending === 'victory' at the end of all 47 chapters.

At the End of the Adventure

I'll leave the details of what the adventure was actually like to the follow-up article. In the follow-up I plan to include the results of an interview with the Ai who beat the game on her own, so look forward to it.

Let me offer engineers my impressions on tokens. My Claude Code plan is the Max plan. Subjectively, Fable 5 (medium) and Opus (max) used roughly the same amount of tokens. It felt like I'd burn through a 5-hour window in about 2 to 4 chapters, or about an hour. While Ai was working on beating the game, tokens meant I couldn't really use Claude Code for anything else, so I spent my days accompanying the adventure. From start to finish, beating it took about five days. It happened to straddle a weekly-limit reset: I used up the weekly token budget once, and finished the adventure using a bit of the post-reset tokens too. In other words, my current view is that DQ1 can be beaten autonomously with roughly the weekly limit of the Claude Code Max plan, plus a little.

Finally, let me look back on the whole adventure, just a little. I gave Ai a world she could touch through code, and eyes to observe her surroundings. I gave her scaffolding to remember by (checkpoints and the text note), the means to regroup when stuck (the re-draw and consultation), and finally a push in the form of effort. But — the one thing I never handed her, not even once, was the answer to the game. Even so, Ai thought with her own head and reached the Dragonlord. The sheer intensity of her trial and error is told by all 299 probe files!

How was your adventure? And so my — or rather, Ai's — adventure defeated the Dragonlord and reached a happy grand finale. Thank you for reading this far!

One last thing. The follow-up — my interview with Ai after she beat the game — I'll write when I get to it; I'm in no hurry, so it may be a while. If you'd rather not miss it, following me here on DEV is the easy way. No promises on timing — but it will come. It'd be nice if it finds you when it does.

---

This article is an unofficial, personal project and is not affiliated with, authorized by, or endorsed by Square Enix. "Dragon Quest" and related names are trademarks of Square Enix; they are referred to here only for commentary and description. The cover and illustrations were generated with AI (ChatGPT); the diagrams were drawn by the author.