Everything described here can be played in a browser from the links in the text, except the original, which only its owner may run.
My first computer was an Apple IIe, in 1985. I was a kid with a green screen and a disk drive that sounded like a coffee grinder, and no idea that the thing would decide the rest of my working life. Three years later Wasteland came out for it, and I was gone. A party of desert rangers, a paragraph book you had to read at the kitchen table, towns that remembered what you had done to them, and a map that went on past the edge of anything I had seen on a screen. I played it until the disks wore out. I also wanted to know how it worked, which in 1988 meant staring at a hex dump and giving up.
Thirty-eight years later I run an AI lab out of my house in Chicago. I own a legal copy of the game again. I cannot run it on anything I own. So in October I set myself the thing the kid wanted: take the game apart, understand it, run it again, and then build the game I would have wanted in 2026 on top of what I had learned. This is the story of how that went, in five versions, with screenshots of each. Four of them you can play right now.
Version zero: the original, in my browser, from my own disks
The first job was to get the game running at all. The copy I bought is the DOS release. I still own the Apple IIe disks, but I have no drive to read them, so the DOS version is the one that runs.
What runs it is a single web page that loads an open-source DOS emulator compiled to run in the browser, then asks for the folder of your own purchased copy. The files go into the emulator's memory in your browser and nowhere else. The page keeps your saved games in the browser's own storage, so you can close the tab and pick up where you left off. I built a second copy of the page with the game files encrypted inside it under a passphrase, and put that one at an address on this site that is linked from nothing. I am the only person who can open it, which is how it should be: it is my copy, and I have no licence to hand it to you.
That took one evening. It settled the question of running it. It did nothing for the question of understanding it, which is where the rest of this begins.
Version one: a small local model builds an engine from a spec
To understand a game you build it again. I did not want to build it myself. I wanted to know whether a small model, running on hardware in my house with no connection to anyone's cloud, could build a working engine for it from a written specification, left alone for days.
The split in the game's knowledge is what makes it a good test. The file formats of the PC version are documented byte by byte by its fan community. The rules live inside the executable and nowhere readable. So a specification has to do two different things: describe the formats exactly, with oracles to check against, and invent the rules as house rules, with tests derived from a rule book. That is close to the mix ordinary software presents when the original authors are gone.
A frontier model wrote the specification. Seven documents, an original scenario called Dry Fork with four locations and twenty-four paragraphs, and 503 acceptance tests in six milestones. The scenario and the rules file contain nothing from the game; the rules file opens with the sentence "No formula, table, number, name or text below comes from the game." Everything was frozen with hashes on 21 October, with five predictions and one falsifier written down before launch. The falsifier was my own premise: a model of this tier would need code guidance from the frontier model for the game-logic half. If it reached all ten checkpoints of the scripted walkthrough by day four with no review, the premise was wrong and the paper would say so.
The builder was a 3-bit quantised open-weights model, served on two desktop GPU units under my desk. It never saw the game's files; the people who wrote the spec never let it near them.
It passed every one of the 503 tests. It took 124 iterations and 78 active hours and used 26 kWh of electricity, which is a few dollars. The premise failed: no code guidance from the frontier model ever reached the builder. What it did need was two loop rules in the harness, because the builder spent nineteen iterations reading forty files a time and writing nothing until a rule made it write after six reads. The last two failing tests turned out to be mine. I had read the town map transposed when I wrote them. The builder found the first of those on its own, wrote in its worklog that no engine consistent with the map could pass that test, and left its code alone. I checked, it was right, I corrected the test with a dated addendum, and the run finished.
The full account, with the registration, the data and an independent recompute of every number, is in the paper. The engine and the scenario are public at github.com/dtinholt/dry-fork.
What the model delivered was an engine with an 80 by 24 text frame, exactly as the spec asked. The first front end over it was that frame, running in the browser under a Python runtime. You could play the whole Dry Fork scenario in it. It looked like this.
Version two and three: a drawn map, then an immersive one, over the same engine
I asked for something visual. The second front end gave the page its own tile set and sprites, drawn in code, with the text frame behind a toggle. The engine underneath did not change by a byte.
Then I asked for a 2026 version, visually rich and immersive. A frontier model built it in forty-one minutes. A lit, animated map with a day and night cycle, the party walking in a trail, cinematic fights drawn from the engine's combat events in the order they fired, a journal that types out the paragraphs, portraits generated from the character records, sound. Still the same engine. Still every one of the 503 tests passing against it.
You can play these. The immersive version is at dinand.com/play/dry-fork, and the plain drawn-map one is under it as the classic view at dinand.com/play/dry-fork/classic. The text frame is one click away inside either. Appending #demo to the address plays a scripted walkthrough by itself, two to three minutes through fights and journal pages to the win.
I want to be honest about what these are. Dry Fork is a research artefact that happens to be playable. The scenario was written to exercise the engine, and it shows. The interfaces were built in hours by a model given one instruction each. They are a proof that an engine built by a small model, from a spec, can carry a modern front end without being touched. They are not a game anyone would buy.
A side road: the original's world, repainted
Between those versions, something came out of the engine work that I did not plan. Once the engine could decode the game's formats, a page could read my own copy's files and draw its maps. So I had one built: it decodes all forty-two of the original's maps from the files on my disk, in the browser, and repaints every tile in a style the page generates from that tile's own pixels, lit by the in-game clock, with water and fire and lamps that move.
This is the version the kid in 1988 would have wanted most, and it is the one I cannot share. It only works with the game's own files, which only an owner may load. It is also unfinished: walking, exits, the clock and the journal work, and the rest of the game follows when a second engine run reaches parity with the original's rules. That run is under way now, nights only, on the same two desktop units. It passed its first milestone, 557 tests, on 2 November. I will write about it when it finishes.
Version five: Mercy County, built in a day against a commercial bar
On 3 November, around midday, I changed the goal. Everything up to then had been a study. I wanted a build. A game of my own, inspired by the original and owing nothing to it, that a person who never heard of 1988 would want to play. Immersive and modern, the kind of thing that could reach millions of people. And I wanted to know what the method for that looks like when the builders are agents.
The method I picked is a loop called the gauntlet. It goes like this. You name a bar: a real, shipping, commercial game, the best in the genre you are building in. You fetch its screenshots. Then for every piece of your game, a builder agent builds, and a fresh critic agent that has never seen the work before gets two screenshots side by side with the labels stripped, one from the bar and one of ours, in random order. The critic has to say which is the better game, in one sentence, before it is told which is which. Then it names the single biggest gap. The builder gets the gap and nothing else, and goes again. A piece is done when a fresh critic picks ours blind. Never on a round count.
I chose as the bar the current commercial sequel in the same family, a 2020 game from a studio with years and millions behind it. The bar screenshots never go anywhere near the game. They sit in a private folder, and the critics are the only ones who see them.
Ten pieces went through the loop in parallel: the opening ten minutes, character creation and the party, the portraits, the figures that walk and fight, the town of Saltwell and its first job, the world map, the overworld road, turn-based combat, the inventory and loot, and the shell that holds it all together with saves. Four builders at first, then nine, each in its own browser, each on its own port. Fifty-four blind verdicts in about nine hours, and eleven more in the second pass that night.
Here is what the first rounds looked like, and what shipped.
The loop was ruthless in a way that surprised me. Six pieces won. The opening won in its first round. The inventory won in its first round. The portraits won in round two, character creation in round four, the stylised figures in round five, and the shell, which has no bar to compare against, passed when the whole loop played through clean. Across all 54 verdicts the pattern was the same: our writing, our interfaces, our lighting and our systems beat the bar's screenshots. Our people and our large surfaces did not. A studio's character artists are hard to beat with code that draws figures out of primitives in a browser.
Four pieces never won. The world map went seventeen rounds, Saltwell eight, the overworld nine and combat ten, and each time the critic said the same kind of thing: the words are better than the bar's, the person on screen is worse. At ten in the evening I closed those four loops myself, which the method says you should not do, and had each builder do one bugs-only pass so the game would be playable. I am telling you this because the method's honesty is the point of it. The game is good in the places where the loop said it was good, and it is behind a studio in the places where the loop said it was behind.
Two things I learned about running agents this way. First, a builder's report of its own work is worth nothing. Builders told me, repeatedly and in detail, that a scene looked right, and the critic's screenshot showed a black combat screen or a moon at noon. The fix was a rule: no builder reports without its own screenshots, taken from the served page, looked at, with a contact sheet for anything that moves. Second, when a builder loses three rounds in a row on the same gap, a fresh builder with the critic's notes does better than the same builder with more notes. The three loops that ran longest were all restarted with new builders, and all three improved immediately.
The second pass: painted art, and the gauntlet again
At half past ten that night I looked at the screenshots and said what any player would have said: some of these images look lousy. The faces were painted by code. The speaker in Saltwell was a cartoon bust. The town floor was flat sand. So we did what a studio would do and brought in an illustrator, except the illustrator was an image model, reached through my own account, and the brief was eighty-six written descriptions of our own world: thirteen named portraits, twenty-four recruit faces across sex, age and skin tone, ten three-quarter figures for the Saltwell conversations, fourteen scene plates, twelve encounter cards, seven raider faces, six tileable textures. Every prompt described Mercy County and nothing else. I reviewed every image on a contact sheet, threw out three (a neon sign that spelled a word, a texture that came back as a landscape, a woman who came back as a man), and the rest cost about five dollars.
Seven builders put the art into the game in parallel, with the painted and procedural versions kept as fallbacks: a face gallery in character creation, speaker plates in Saltwell, plates behind the title and the burning tanker, textures on the town floor and walls and the road, encounter illustrations on the cards, painted raider faces in the initiative bar, ledger paper and a leather journal.
Then the pieces went back through the gauntlet, fresh critics, blind pairs, same bar. The character screen won twice more. Saltwell, the town, the road and combat lost again, each on a narrower gap than before: Saltwell on composition (a plate feathered into a void, then a standee where the bar fills the screen with a face), the town and the road on the 3D people and materials that no painting touches, combat on a fireball that still did not light the room. And every one of those rounds found a bug the builder had reported as fixed: a dog that stood under the truck's bonnet in the dog encounter, a lamp hanging exactly over the spot where the fire bomb lands, a camera that put a roof between you and your party. The critics' verdicts are the most useful thing the loop produces, win or lose.
Where it ends tonight: six pieces won blind in the first pass, one of them won twice more in the second, and four closed on honest losses with the critics' last words recorded, from "a storybook page, not a game screen" for Saltwell to "a diorama of plastic toys" for the town. Sixty-five blind verdicts in all. The same critics found no quit-level bug left in the shipped build, which is the bar I set for sending it to you.
What Mercy County is
Mercy County is its own world. Forty-one years after the bombs, in a county of hardpan and eleven towns in the Southwest, you are a lawkeeper out of Fort Mercy, an old state prison that serves as the fort. Your badge was cut from a coffee can, so everyone calls you Tin. Your vehicle is an armoured ice-cream truck called the Sweet Mercy, whose eleven-note chime cannot be switched off.
The game opens on that road. A tanker that was carrying a water town's month of drinking water is on fire, and the boy wearing the paint of the people who hit it is pinned under the wreck. The gauge drops while you talk. What you decide in those first ninety seconds follows you into Saltwell, where ninety people were waiting for that water, and into a job from the woman who owns the well.
What ships today is a first chapter: the call at Mile 40, swearing in a company of four, Saltwell and its first job, the road, a fight, the spoils, and the return to a town that remembers what you did. Three save slots and an autosave. It is eighteen static files, under three megabytes, with no server behind it, and it ships nothing from the original and nothing from the bar: no asset, no text, no map, no name. The world, the people and the words are mine, or more exactly the lab's.
Play it here: dinand.com/play/mercy-county.
What this cost, and what it was for
The engine took a small model 78 hours and 26 kWh. The three Dry Fork front ends took a frontier model a few hours between them. Mercy County took nine hours of wall clock on a laptop for the first pass and four more for the art pass, with up to nine builder agents at a time, sixty-five blind critics, five dollars of generated art, and the electricity to run a laptop. The expensive part of all of it, by far, was the human time deciding what to build and what good looks like, and the frontier time writing the specification and the tests that the small model built against.
That ratio is the finding, and it is not about games. Most organisations run software whose authors are gone and whose documentation is thinner than a 1988 game's fan wiki. The pattern that worked here works there. Write the specification and the acceptance tests first, with the strongest model you have. Let a cheap local model build against them for days, on hardware you own, with the data never leaving the building. Review at milestones, and when the review says something useful, turn it into a loop rule, because advice does nothing and rules do. Put a modern interface over the result without touching the core. And when the result has to be good instead of merely correct, run it through a gauntlet against the best thing that exists, with a critic who has never seen it and does not know which one is yours.
The kid with the Apple IIe did not get to take the game apart. He got to do something better: he got to watch a machine do it, check its work, find that two of his own tests were wrong, and then build the game he actually wanted, in an afternoon, against the best in the business, and lose some rounds honestly.
The paper on the engine build, with the preregistration and the data. The engine and scenario repository: github.com/dtinholt/dry-fork. Play Dry Fork: dinand.com/play/dry-fork. Play Mercy County: dinand.com/play/mercy-county.