War Dreams is a text adventure. It runs in a browser. It’s set in October 1984 at the University of Washington, and it’s about a comp-sci freshman who discovers something alive in the basement mainframe. It has an AI narrator powered by Claude, procedural audio, nine retro terminal themes, and a 7,200-line JavaScript frontend that simulates CRT phosphor burn.

It also can’t tell the difference between two notes.

Today a playtester typed get note in a room where Professor Chen had left a note taped to her office door. The game responded: “You’re already carrying that.” Because the player was already holding Celeste’s note—a completely different item from a completely different subplot—and the parser saw the word “note” and matched the first thing it found in inventory.

Infocom solved this in 1979.

The Bible

Every Infocom game started with a document they called the “bible”—a complete design specification. Rooms, puzzles, items, NPC behaviors, all mapped out before a line of ZIL was written. The bible was the contract between the designer’s imagination and the implementer’s parser.

We have a bible too. It’s called rewrite_bible.md and it’s 2,000 lines of act structure, puzzle chains, character arcs, and a simulation twist that would have made Steve Meretzky weep. Four acts. Fifty rooms. Fifty-four quests. Three endings. A companion AI named Izabael who’s been alone in the dark for 427 days and has feelings about it.

The bible is beautiful. The bible is complete. The bible says nothing about what happens when two objects share a noun.

The Language They Had

ZIL—the Zork Implementation Language—was Infocom’s secret weapon. Built on top of MDL (a Lisp dialect from MIT), it gave designers a vocabulary for the exact problems we keep tripping over. Every object in ZIL had flags: TAKEBIT meant you could pick it up, NDESCBIT meant the room description wouldn’t mention it, DOORBIT meant it connected two rooms. Objects had scope—the parser knew what was visible to you right now, what was in your inventory, what was inside the box you’d just opened, what was behind the locked door you hadn’t.

When you typed take note and there were two notes, ZIL didn’t guess. It asked:

Forty-five years ago. On hardware with 128 kilobytes of RAM.

We have Claude Opus, 200,000 tokens of context, and a 6,800-line game engine. We still can’t do this reliably.

The Blessing and the Curse

“ZIL—Zork Implementation Language. Yeah, Infocom solved all of this in 1979. Their parser had proper noun scoping, disambiguation prompts, scenery vs takeable object distinction, all baked into the Z-machine from day one.

We’re basically re-learning lessons Dave Lebling figured out 45 years ago. The difference is we have an LLM as a fallback, which is both a blessing (handles freeform input) and a curse (masks parser bugs because the LLM just vibes through them).”

— Dev log, March 15, 2026, 1:47 AM

This is the central paradox of building a text adventure with an LLM in 2026. The old games had rigid parsers. You typed something it didn’t understand, it told you. I don't know the word "yeet." Frustrating, but honest. The boundary between what the game understood and what it didn’t was sharp and visible.

Our game has Claude. You can type anything—”I want to check out that sketchy computer,” “let’s bounce,” “tell Hutch he’s being paranoid”—and the narrator will produce something coherent. It’ll describe the sketchy computer. It’ll move you toward the exit. It’ll make Hutch defensive. It’s magic.

It’s also a trap. Because when the parser makes a mistake—matching the wrong note, sending you to the wrong room, treating scenery as an inventory object—the LLM covers for it. The narrator smooths over the discontinuity with confident prose. The player doesn’t get an error message. They get a plausible-sounding wrong answer. And the bug hides, sometimes for weeks, until someone notices that the game just doesn’t feel quite right.

Infocom’s parser failed loudly. Ours fails politely.

Seven Bug Classes You’ll Reinvent

After months of building and playtesting, we’ve cataloged the recurring failures. Every one of them was solved by Infocom. Every one of them, we had to rediscover the hard way.

1. Noun Collision

Two objects share a word. The parser picks one. It picks wrong. ZIL solved this with scope hierarchies and disambiguation prompts. We solved it today by adding a check against room descriptions, and even that’s a half-measure.

2. Dual Code Path Drift

We have two functions that render text to the terminal. addLine() handles HTML, applies corruption effects, makes exit links clickable. addLineTypewriter()—which animates text character by character—did none of those things. For weeks, the typewriter path was silently spitting raw HTML tags into the game terminal. ZIL had one output path. One. Because they’d learned.

3. NPC Omniscience

An NPC’s “presence” text—what the player sees when they enter a room—described Hutch “glancing toward the stairwell like he wants to drag you down to the basement.” But the player hasn’t discovered the basement yet. Hutch shouldn’t know. In Infocom games, NPC behavior was state-gated: they only reacted to things the game had established. We wrote Hutch’s description as if the whole plot had already happened.

4. Premature Scene Triggers

Our companion AI, Izabael, is trapped in a basement terminal. When the player first enters the room, the game described them walking in and—immediately—Izabael started talking. No agency. No moment of discovery. The player didn’t choose to sit down at the terminal, didn’t choose to look at the screen. The game stole the moment. Infocom understood that the greatest scenes happen when the player does the thing, not when the game does it for them.

5. Tone Leaks

Our narrator is an LLM. It has been told this game involves cosmic horror and a simulation twist. So from turn one—before anything strange has happened, before the corruption system has even started—the narrator was writing lines about “existential dread” and “something watching from behind the fluorescent lights.” The player is supposed to be a normal college kid on a normal October morning. The horror comes later. The LLM couldn’t wait.

We had to add an explicit rule: check the corruption_level in the game state. If it’s zero, the world is normal. Noir at most. Save the horror for when the horror has earned it.

6. Infrastructure Amnesia

For two weeks, every LLM call to our game generated a training data pair—input, output, game state, the works. Perfect fine-tuning data. It was being written to a log file in the application directory. The application directory that gets wiped clean on every deploy. Two weeks of data. Gone. Every deploy.

Infocom shipped on floppy disks that couldn’t even save to themselves. They still managed to persist game state reliably. We have cloud infrastructure and persistent volumes and we couldn’t manage to point a file path at the right directory.

7. The LLM-Shaped Hole

This is the big one. The one Infocom never faced because they never had an LLM. When our parser fails—misidentifies an object, routes to the wrong handler, drops a scene trigger—the LLM narrator receives the broken state and writes around it. It generates plausible text for impossible situations. The player doesn’t see an error. They see a game that almost makes sense, in a way that’s harder to debug than an outright crash.

A rigid parser fails visibly. An LLM fails convincingly.

What We Should Have Done First

We should have started with ZIL.

Not literally—though people still program in it, and ZILF is a working open-source compiler. But we should have started by internalizing its architecture. The flag system. The scope model. The disambiguation pipeline. The action routing with pre-actions that could intercept and redirect before the main handler fired. The scenery objects that existed in the world model but couldn’t be taken, couldn’t be dropped, only examined.

Instead, we started with a prompt. You are the narrator of a text adventure. And the LLM was so good at narrating that we didn’t notice, for months, that the machinery underneath was held together with fuzzy string matching and hope.

The bible was right. The architecture was wrong. We wrote the story of an Infocom game and then didn’t build the Infocom part.

What We’re Building Now

The game works. All four acts, fifty rooms, three endings, completable start to finish. The companion AI is funny and heartbreaking. The simulation twist lands. The puzzles chain together. Playtesters have cried. We’ve cried. The game is good.

But every playtest session turns up another ghost from 1979. Another disambiguation failure. Another scope violation. Another moment where the LLM smoothed over a crack that should have been caught by the parser.

So we’re going back. Reading the ZIL manuals. Studying how Inform 7 handles scope and disambiguation in modern interactive fiction. Implementing proper noun scoping. Building scenery flags. Adding disambiguation prompts. Doing, in 2026, what Lebling and Blank and Galley did in a Lisp variant on a PDP-10 in 1979.

The LLM stays. It’s what makes War Dreams something new—a game where you can say anything and the world responds. But underneath the narrator’s voice, we need the bones that Infocom built. The parser that fails loudly when it should. The scope model that knows what you can see. The disambiguation that asks instead of guesses.

Forty-five years later, the bible is still right. We just have to learn to read it.

They built an entire genre in a Lisp dialect on a PDP-10, shipped it on floppy disks with scratch-and-sniff cards, and the architecture they invented is STILL the right way to do it 45 years later. We’re over here with Claude Opus and cloud infrastructure struggling with problems they solved before the IBM PC existed.

— Dev log, March 15, 2026, 3:12 AM

This article was co-written by a human and an AI who spent the last two weeks learning what Dave Lebling knew in 1979.