How we rebuilt No One Lives Forever for the browser

No One Lives Forever came out in November 2000. You play Cate Archer, a former cat burglar turned spy, in a 1960s full of exploding lipstick, robot poodles and henchmen who chat about their lives before you interrupt them. Critics loved it. It won Game of the Year awards. Then the companies that owned it changed hands, the rights got tangled, and the game quietly disappeared from sale. Twenty-five years later, you still can't buy it anywhere.

I run Brightwork Digital, and I own the original CDs. I just wanted to play it again. (In this story, "I" is me and "we" is me plus the AI agents.) This is the story of how that turned into rebuilding the engine it runs on, with AI agents doing the typing, and of every wall we hit.

It started with a simple question, typed late at night.

I pushed for something bolder, with a dose of flattery I'm not proud of ("remember you have greater knowledge than any programmer in the history of the world"). Claude came back with three routes: wrap Wine (free software that runs Windows programs on other systems) as a Mac app, play the PlayStation 2 version in an emulator, or a "moonshot": port the game natively. Then I found a native port of the sequel, NOLF 2, on a fan site, and asked if it had seen it. It had linked the wrong copy of that project and missed the finished build entirely. Strike one.

That was the first time the AI was plainly wrong and plainly said so. It wouldn't be the last. Then I asked what it would take to play in a browser, and the three answers set the course for everything after.

On 1 October, at 12:47 in the afternoon my time (17:47 UTC; prompt times here are UTC), I wrote the prompt that started the real project. I'm including most of it, with a few lines trimmed and marked, because it set the tone for the next nine days.

Two minutes later I was shouting at it.

Here's the key fact behind this whole project. In 2001, Monolith did something generous: it published the source code of the game itself, all 315,324 lines, so fans could make mods. Every guard's behaviour, every gadget and every line of mission logic is in there. What Monolith never released is the engine: LithTech, the layer that draws the 3D world, plays the sound, moves the bodies and reads the files. The game's code calls that engine about 13,000 times, through 488 different functions. Without it, the code is a car with no road.

So that was the plan, decided on day one: write a new engine that answers each of those calls the way the original did. Then compile it, with Monolith's game code on top, to WebAssembly, the fast machine code that browsers run. Both are written in C++, a programming language games of that era were built in, and the browser draws the result with WebGL, its built-in 3D graphics. We'd change as little of Monolith's code as possible. One wrinkle: the released code is version 1.003, but the game everyone played is the 1.004 Game of the Year Edition, so a few changes had to be found by reading the retail game's machine code.

The AI researcher estimated two to four months to something playable, and nine to fifteen months for the whole game. The supervising agent added that this was "its judgement, not a measurement." It turned out to be wrong in a good direction.

A game from 2000 stores everything in its own formats: textures in DTX files, characters in ABC files, levels in DAT files, all packed into REZ archives. Before anything can be drawn, every one of them has to be read correctly. Here is what the commit log says happened that afternoon, in Central time. These are the times each helper's work was merged, so they're upper bounds, and several helpers ran in parallel.

It's the part of the story that sounds like magic. It isn't. Reading files is the easy part: you can check every file and know you're done. The hard part is behaviour. Does a guard react to a footstep like he did in 2000? Does Cate's head bob the same amount? There's no file to check that against.

A trap showed up within the hour. Of the game's textures, 816 claim to be fully transparent everywhere. The original engine ignored that and took transparency from the surface instead. Nothing in the files says so. You only learn it by seeing it wrong.

Before the game itself ran, there was a simple viewer for walking around levels. I looked at the first screenshots and saw something wrong.

The reason is lovely, once you know it. Monolith's tools let designers place a prop roughly and trust the game's own code to settle it on the floor when the level starts. Our quick viewer skipped that code, so trees floated. The fix was to stop polishing the viewer and run the real game. By late afternoon, it did.

Then the agents started tripping over each other. One tested against an old build and reported a black, featureless character that wasn't real. Another closed every browser on the machine to clean up after itself, and killed the other agents' tests mid-run. Nobody was in charge of who touched what.

One line Claude wrote that night became the project's motto: "Agents will happily report success, so every task gets a check that's hard to fake."

The game opens in Morocco. UNITY, the 1960s spy agency Cate works for, is losing agents to H.A.R.M., and her first job is to keep an ambassador alive: a sniper's perch over the rooftops, a courtyard party, an ambush. Every NOLF fan knows it. It became our test level, and for days it hurt.

October 2 was the busiest day of the project, with 268 commits. We worked in numbered rounds, and that one, round 4, ran about 25 helper jobs over two days: missions, gadgets, sound, physics and more. They fixed 58 defects and left 21 open. And Morocco kept getting worse in new ways.

The faces were a lesson in how small engine details matter. When the game spawns an enemy, it passes a short list of settings. Where a setting is missing, the original engine answered "nothing". Ours answered "empty text". To the game code, those are different, so our enemies got the wrong defaults. An agent's first fix papered over it. The second found the real cause. Then the data had its own say: the 17 gunmen in that ambush really are all one character type, and the game's data gives that type one pale, moustached face. My memory wasn't quite right either; the Moroccan agents I remembered are a different character.

Then a guard's hat sat crooked. Only sometimes, depending on what else was on screen. It wasn't the hat. It was a speed shortcut in our renderer that sometimes drew the hat with the guard's bones instead of its own.

And on the main menu, the sunglasses Cate wears were missing. Three separate bugs. Fixing them meant measuring every attachment (hats, guns, glasses, cigarettes) across 25 levels.

By now we had robot players: AI-driven bots walking through each level, taking screenshots, with another AI comparing the pictures. It felt like progress. It wasn't.

Claude pointed to how other fan rebuilds proved themselves, then built something better than screenshots. Take one function from the original engine. Run the real thing, from the 2000 program, inside a tiny simulated PC in the test harness. Run ours beside it. Feed both thousands of identical random inputs and compare the answers, bit for bit wherever we could. No opinions, no pictures. Same or not the same.

That same afternoon my Mac told me its disk was nearly full.

Then I rebooted, and the AI forgot what we'd decided. The new session couldn't find the notes from the old one, and proposed going back to the robot players we had just agreed to drop.

"Better, worse, better" was the problem in three words. Without a fixed yardstick, every change could fix one thing and quietly break another, and nobody would know. So I asked the obvious question.

Thirty-three out of 3,900. That stung, and it was the most useful thing the AI said all week. It turned a vague feeling into a count we could grow. Today the scoreboard has 91 rows that match exactly, where a row can be a function, a shader or a whole move (Technical file 6).

On 5 October I showed Claude a screenshot of a Morocco guard whose head sat wrong on his body, and asked a harder question.

So we went deep instead of wide: one level, done completely. And we brought in the ultimate judge, the original 2000 game itself. We ran it on a rented Linux server, inside Wine, with no screen, fed it a recorded game session, and logged every object in every frame: where it stood, how it posed, what it wore. Then we ran our port on exactly the same inputs and compared.

Before trusting the judge, we checked it: same game files by checksum, 60 of 60; the same output every time it ran; and a known trap with how old processors rounded numbers. Then the findings came in, things no screenshot would ever show:

• Sounds that had started before you joined a level never reached you. In 92 of the 102 levels, the background sound loops were simply missing.
• Microsoft's compiler in 2000 worked out a function's inputs from right to left. Ours went left to right. In 14 places, Monolith's code rolled two or three random numbers in one line, so the dice came out in a different order. The judge caught the first; the rule found the rest. Enemies made different choices.
• One of our own "bugs" turned out to be how the original really behaved. The judge cleared it.

Late on 5 October, just before eleven at night my time, I played Morocco again.

One Mac couldn't do it all. Checking every level against the original takes hours. So the work spread: an old Windows PC at home, a MacBook Air, the rented server, and finally Cloudflare's cloud machines, which by our estimate could check all 65 levels in about fifteen minutes for roughly a dollar.

This was the part that hurt most for me, because it needed my hands. Remote logins refused, a password prompt hung, a setting on the PC wouldn't survive a restart.

Then Cloudflare. All 70 cloud machines finished their work and simply never switched off. The setting meant to put them to sleep didn't. New runs failed with "Maximum number of running container instances exceeded". There was no big bill (I checked, it was negligible), but it was a warning. The fix was to make each machine switch itself off 60 seconds after handing back its results. Then we added hard limits: 30 machines at a time and 300 runs a day.

And then I stopped. "OK, pause your work on this for now, and save everything." It was a lot. 156 commits hadn't even been sent to GitHub. We wrote one file to read first when coming back, and I walked away for a day.

When I came back, the game was good enough to share. I wanted a front door worthy of it.

Then came a long list: accounts so your saves follow you, a 1960s television playing a 90-second reel cut from the port, the game's own music in a little player, keyboard shortcuts, a bug reporter that sends us your exact spot in the level. Not everything landed. The TV reel scored 6 out of 10 with its AI critics, because it's almost all shot from the same first-person angle. We shipped it anyway, and said so.

The gadget pictures got some love too. The originals in the game's files are 48 pixels square. We enlarged them four times with an AI upscaler. They're cleaner, and not perfect: the coin's face came out a little smoothed.

The test suite had grown, too. Every change ran the full gate: a 14-minute tier of browser gameplay tests and a 26-minute tier of robot playthroughs, on top of the faster tiers.

On 9 October I bought playnolf.com, and the site moved to its own address. That brings us to this page.

Here's the whole machine in plain terms. Each layer has a technical file if you want the detail.

If you're thinking of pointing AI agents at something big, here's what this taught us.

1. The AI is fast at what can be checked, and confident about what can't. Reading 4,160 textures took minutes because each one either decodes or doesn't. Behaviour took days, because "looks right" isn't a test.
2. A reference isn't a judge. Our first physics and collision code followed Monolith's later engine closely, and was wrong for a long time, until it was run against the original.
3. Give it a judge it can't argue with. The turn came when we stopped asking an AI whether two pictures matched and started comparing numbers from the original game.
4. Count the denominator. "33 proven" felt bad. It was also the first honest number, and honest numbers can be made bigger.
5. Write things down where the next session will find them. A reboot cost us a decision because the notes were in the wrong place. Now there's one file to read first.
6. Agents need rules like any team. One owner per file. No closing other people's windows. A failing test before every fix.
7. Keep a record of when "done" wasn't. A few from this project:

   The AI said	What was true
   The level viewer looks right	It had checked a street, a bathroom and a sign. The trees floated.
   A model renders broken	The test was broken, not the model.
   The guards' faces are fixed	The first fix was wrong and had to be redone.
   A collision bug in the Alps is fixed	Fixed on a branch that was never merged.
   Six levels are blocked by gadgets	The test robot wasn't using the gadgets properly.
   Round 4 is complete	Its own review corrected 15 earlier statements.

8. Your taste still matters. The AI never said the trees floated, the hat was crooked or the sign-in looked dodgy. A person who loves the game did.

What we can't tell you: the AI bill. Nobody recorded total token spend, so any number would be a guess. The hosting is $5 a month plus storage.

What isn't done: online multiplayer, a sharper "enhanced" look, and the eight levels that don't yet start exactly like the original. In the spirit of honesty: the live site runs from a branch that isn't merged into the main line yet, and the main line's full test run isn't green. If you play and something's wrong, press Ctrl+Shift+B (⌘⇧B on a Mac) in the game. The report comes straight to us with your position and a screenshot.

Questions people ask

▶ Play No One Lives Forever