DEVELOPMENT RECORD · SEPTEMBER 2026

A game made in conversation.

One person supplied the premise, occasional direction, criticism and encouragement. ChatGPT made most of the intervening design and implementation choices: mechanics, levels, architecture, testing systems, presentation, sound direction and, eventually, a story that had not been written down at the start.

The primary source is here now. The mistakes are not cleaned up. The old builds are not replaced with reconstructions.

READ THE FULL TRANSCRIPT STEP THROUGH 17 BUILDS

About this record. The transcript is the copied visible ChatGPT conversation supplied after development. It begins with the first game instruction and continues through the decision to publish the process. Privacy and technical redactions are explicitly marked: the specific GitHub repository/account, internal ChatGPT links and attachment URLs are not published. Public project material such as deadagain.fisheggs.au and fisheggs remains. The simulated critics are labelled as simulated. Robot Dave is an executable solver, not a human tester.

THE PREMISE

Death becomes infrastructure.

The initial instruction was broad. The death/ghost mechanic, mastery structure, hidden levels, 320×200 presentation and the decision to keep the controls small emerged in the first exchanges.

READ THE CONVERSATION 10 MESSAGES

CHATGPT

That’s a strong foundation for a browser game. The part of Dangerous Dave worth copying isn’t the exact mechanics so much as its economy: very few controls, instantly understandable rules, short levels, precise movement, secrets, and escalating difficulty. A modern version could preserve that while adding one distinctive mechanic that gives the game its own identity.

I’d design around these constraints: left/right/jump + one action, levels around 30–90 seconds once mastered, instant restart, pixel-art presentation, and no sprawling upgrade/inventory system. The player should understand almost everything within the first minute, but still be discovering techniques much later.

A concept I think could work: DEAD AGAIN

You’re a tiny escaped test subject working your way through a malfunctioning underground facility. Visually, think chunky EGA/VGA-era graphics: black backgrounds, cyan/magenta machinery, spikes, acid, lasers, doors and absurd little monsters.

The unique mechanic is that every time you die, your previous attempt remains in the level as a ghost that repeats exactly what you did.

So initially it feels like Dangerous Dave:

← → move Space jump X interact/fire

But death gradually becomes part of solving the level.

Suppose there's a pressure plate that opens a door. You run onto it and die. On your next attempt, your ghost repeats that run and stands on the plate while you go through the open door.

Later:

Ghost #1 activates a lift. Ghost #2 attracts an enemy. Ghost #3 gets killed by a laser and temporarily blocks it. You use all three to reach the exit.

That creates an interesting contradiction: dying is useful, but dying too much makes the level increasingly chaotic.

And importantly, you don't need to explain much of it. Players discover it.

The Dangerous Dave structure

Each level has three objectives.

Find the key/artifact, reach the exit, and optionally collect every treasure item.

You can finish without collecting everything. But completing the entire game requires finding all the hidden collectibles.

I'd make perhaps 40–50 handcrafted levels, divided into five visually distinct areas. The first ten would be almost embarrassingly simple. By level 40, players would be performing ridiculous sequences using several previous versions of themselves.

But there should be no procedural generation. The appeal is learning beautifully designed levels.

The difficulty curve should feel like:

Level 1: “Oh, this is easy.” Level 5: “That's clever.” Level 12: “Wait—I can use my dead guy to do THAT?” Level 25: “This is evil.” Level 40: “There is absolutely no way.” Five minutes later: “OH.”

That last reaction is what I'd optimise the entire game around.

The addictive element

Don't make progression itself grindy. Make mastery addictive.

Every level records:

TIME 00:41.83 DEATHS 3 TREASURE 7/7 SECRET ✓

Then reveal a tantalising target:

PERFECT: 00:28.00 / 1 DEATH

So somebody can casually finish a level, while another player spends an hour trying to perfect it.

There could even be a wonderfully cruel achievement:

ALIVE AGAIN — Complete the entire game using the theoretical minimum number of deaths.

That makes full completion genuinely difficult without making ordinary progression miserable.

The ghosts also naturally produce speed-running possibilities. Expert players could intentionally die at very precise moments to create an optimal sequence.

One other ingredient I'd steal from early PC games

Secrets that aren't signposted.

A wall that looks completely ordinary can be walked through. A treasure appears if you jump somewhere pointless. One level has a second exit. Perhaps entering a particular sequence of rooms takes you to something bizarre.

Modern games tend to telegraph secrets with cracked walls, glowing objects and UI indicators. Don't.

You want schoolyard-style:

“Did you know there's another level behind the wall in Level 17?”

For a browser game, that kind of discovery is particularly valuable because players can immediately send someone a link.

Keep the fiction stupidly simple

I'd resist lore, dialogue trees and lengthy introductions.

Opening screen:

YOU HAVE ESCAPED. THIS WAS A MISTAKE. [ PRESS SPACE ]

You're playing three seconds later.

The character should also be visually tiny and memorable—something you could recognise from a 16×16 sprite.

I think the death/ghost mechanic + brutally compact platform levels + hidden completion layer has enough depth to make this substantially more than a Dangerous Dave clone while retaining exactly the simplicity you're after.

And because you mentioned wanting it unique, I'd spend most of the design effort on that single mechanic rather than adding guns, inventories, crafting, character classes, etc. One brilliant rule exploited 50 different ways will feel much more like the games from that era.

Which direction appeals more: A) death/ghost puzzle-platformer, B) faster action/platformer with a different signature mechanic, or C) much closer to Dangerous Dave with secrets and new hazards?

YOU

That’s perfect. I really like option A. It sounds compelling and unique

CHATGPT

Yes — I think A is the game. The key now is not to dilute it. The ghost/death mechanic is strong enough to carry an entire retro platformer if we keep discovering new consequences of the same simple rule.

I’d make one important refinement: your ghosts should be physically real. They don't just activate switches; they obey almost all the same rules as you. They can collide with enemies, get crushed, ride platforms, pick things up, be shot, fall onto switches, perhaps even collide with you. That turns a very simple mechanic into a surprisingly deep system.

And I'd keep the first encounter almost comically simple. Level 1 teaches running and jumping. Level 2 introduces a locked exit. Level 3 introduces death. Then perhaps Level 4 contains a button that has to remain pressed while you walk through a door. There's apparently no solution. Eventually the player dies standing on the button, restarts—and watches their previous self walk over and press it.

Click. Door opens.

That's the moment the game reveals itself.

From there, we can build a whole vocabulary without adding many controls: ghosts distracting enemies; two switches needing two previous lives; ghosts carrying objects; timing jumps off platforms activated by earlier runs; deliberately getting one ghost killed at a particular location; multiple ghosts accidentally sabotaging each other; and eventually levels where the player has to choreograph four or five previous lives almost like programming a machine.

I'd also make death count against your score but not your ability to progress. That creates a beautiful tension: beginners use six deaths to brute-force a solution; experienced players realise it can be done in three; obsessive players discover the intended minimum is two.

And there's a particularly nasty possibility for the final few levels: everything you've learned says death helps you, and then you encounter levels where you need to prevent one of your previous selves from doing what you originally made it do. Suddenly you're effectively fighting your own mistakes.

The name DEAD AGAIN actually feels surprisingly good to me, too. Short, memorable, explains the mechanic after you've played it, and looks right in giant pixel lettering:

        D E A D
        A G A I N

     YOU'VE DONE THIS BEFORE.

       [ PRESS SPACE ]

I think there's enough here to move beyond brainstorming and actually design the game. The most useful next step would be to create the core design: player movement, exact ghost rules, death/restart system, collectibles, scoring, enemies and hazards, followed by the first 10 levels designed individually so each introduces one new idea without a tutorial.

Then we could build a playable browser prototype in HTML/JavaScript and see whether the central mechanic is genuinely fun.

YOU

Let’s do it. Sounds great

CHATGPT

Excellent. I’d treat this as Version 0.1 of the game design and be quite disciplined about keeping it small enough that we can actually build and play it.

DEAD AGAIN — Core Game

Genre: Retro precision puzzle-platformer Platform: Browser, keyboard first Visual era: DOS/EGA/VGA, roughly 1990–94 Core promise: Every death becomes part of your next attempt.

The objective of every level is simple: get the key and reach the exit. Treasure is optional, secrets are hidden, and the real challenge is eventually completing every level perfectly.

Controls

Keep them brutally simple:

| Control | Action | | --- | --- | | ← → | Move | | Space | Jump | | X | Action | | R | Restart | | Esc | Pause |

No double jump. No wall jump. No skill tree.

Movement should feel extremely responsive. The character accelerates slightly but stops quickly, with a little mid-air control. Jump height should be completely predictable. We're aiming for “I screwed that up”, rather than “the controls screwed me.”

The central rule

When you die:

1. The level immediately resets. 2. Your previous run appears as a ghost. 3. The ghost performs exactly the actions you performed. 4. You play alongside it.

Die again and there are now two ghosts.

The ghosts aren't transparent recordings that pass through everything. They exist in the game world.

They can:

• press switches

• ride platforms

• trigger traps

• distract enemies

• block projectiles

• carry/push certain objects

• die

• collect special ghost-sensitive objects

But crucially, ghosts don't permanently collect your normal treasure or key. Otherwise previous runs could accidentally complete the level for you.

I'd initially allow perhaps six ghosts maximum. On death seven, the oldest recording disappears. That gives us a natural complexity ceiling and potentially creates some wonderfully evil late-game puzzles.

Death must be FAST

This is critical.

No:

YOU DIED Continue? Yes / No Loading…

Instead:

SPLAT → 0.4 seconds → GO.

The player should almost be able to die without interrupting their train of thought.

Death isn't punishment.

Death is an input.

---

The first 10 levels

This is where I'd be particularly careful. No tutorial text unless absolutely necessary. The level geometry teaches the player.

1 — GET OUT

Tiny room.

Run. Jump over one pit. Grab key. Exit.

Maybe 15 seconds.

The player thinks they've downloaded a very simple retro platformer.

2 — GREED

Same basic idea, but gems appear in slightly dangerous positions.

The obvious route gets you out.

The dangerous route gets:

7/7 TREASURE

We establish immediately that finishing and completing are different things.

3 — DEAD END

First proper trap.

The player is almost certain to die.

SPLAT.

Level resets.

For the first time, they see themselves appear again and repeat their previous movements.

We don't explain it.

4 — HOLD IT

This is our reveal.

Something like:

                  EXIT
                   │
              ┌────┴────┐
              │  DOOR   │
              └────┬────┘
                   │
       [BUTTON]    │
          ↓        │
──────────○────────┴────────

Stand on button → door opens.

Walk off button → door closes.

Apparently impossible.

Eventually the player dies while standing on it.

Restart.

Their ghost runs over...

CLICK.

Ghost stands on button.

Player walks through door.

That's the game.

5 — AFTER YOU

Moving platform controlled by a switch.

Your previous self must activate the platform at the right moment for present-you to jump aboard.

Now the player understands that when they do something matters.

6 — BAIT

First enemy.

A stupid little creature chases whichever version of you it notices first.

Solution: previous-you attracts it away while current-you slips past.

We've introduced ghosts interacting with enemies without adding a single control.

7 — TWO OF ME

Two pressure plates.

For the first time, one death isn't enough.

You need:

Ghost 1 → switch A Ghost 2 → switch B You → exit

The player is now choreographing multiple lives.

8 — BAD TIMING

Same concept, except ghosts can interfere with each other.

If you record the first run badly, Ghost 1 causes a trap to kill Ghost 2 before it reaches its switch.

This teaches something important:

Your previous lives aren't necessarily helpful.

9 — THE WALL

Straightforward-looking level.

Except players who experiment discover they can walk through one apparently solid wall.

Inside:

SECRET 1/??

No cracked texture. No glowing hint.

We establish that this game has real secrets.

10 — AGAIN

First miniature boss/puzzle.

A large security machine blocks the exit and cannot be killed directly.

The player eventually works out a three-life sequence:

Life 1: lure turret fire toward generator. Die.

Life 2: activate shield while Ghost 1 causes turret to destroy generator. Die.

Life 3: Ghost 1 attacks generator. Ghost 2 activates shield. Security system fails. Current-you runs through the wreckage.

Then:

        LEVEL 10 COMPLETE

        TIME       01:42.31
        DEATHS          2
        TREASURE      9/10
        SECRET          ?

        PERFECT DEATHS: 2

             ★ ★ ☆

And the player sees 9/10.

There's a very good chance they immediately replay it.

---

Where it gets evil

Levels 11–20 introduce moving machinery, projectiles and manipulating objects.

21–30 start exploiting interactions the player wasn't explicitly taught.

31–40 assume genuine mastery.

And then I'd have 41–45 hidden entirely.

You don't unlock them by simply beating Level 40. They require secrets scattered throughout the game.

Level 45 should be horrendous.

But fair.

Completing it should feel like an achievement someone would actually screenshot.

One rule I'd establish now

We never add a mechanic merely because the game needs more content.

Every new element has to interact interestingly with ghosts.

A normal disappearing platform? Not interesting enough.

A disappearing platform where every ghost that touches it also consumes one use?

Now we have something.

A normal gun? Probably unnecessary.

A gun whose bullets can kill your previous selves, allowing you to erase part of an already-recorded sequence?

Interesting.

That design rule should keep DEAD AGAIN coherent instead of turning into a generic platformer with a ghost gimmick bolted on.

And one tiny aesthetic detail

When ghosts replay previous runs, I wouldn't make them ethereal blue silhouettes.

I'd make them look exactly like the player, except each older incarnation uses one of the limited colours in our retro palette.

By Level 30, seeing four little versions of yourself sprinting around a tiny screen executing an elaborate sequence should look completely ridiculous.

That's part of the charm.

Next, I think we should build the playable prototype rather than design another 40 levels on paper. We only need movement, jumping, collision, spikes, death/replay, a pressure switch, a door and an exit. Levels 1–4 are enough to find out whether DEAD AGAIN actually feels as good as the idea sounds.

YOU

Absolutely.

CHATGPT

Great. The prototype scope is locked: movement, jumping, collisions, death/replay ghosts, spikes, switches, doors, key/exit, treasure, and Levels 1–4.

The crucial test isn’t graphics yet—it’s whether Level 4 produces that “ohhh… THAT’S what this game is” moment. I’d also give it the retro presentation from day one: 320×200-style internal resolution, chunky pixels, tiny sound effects, instant death/reset and essentially zero menus.

For the first build, I’d structure it as a self-contained browser game with no framework dependency: HTML5 Canvas + JavaScript, so it can run by opening the page and later be hosted almost anywhere.

One small change from our earlier controls: for the prototype, I’d use arrow keys + Space only, with R to manually restart. We don’t actually need an action button yet. That makes the central mechanic even cleaner.

The first milestone is therefore:

DEAD AGAIN — Prototype 0.1

Level 1 → learn to move Level 2 → learn treasure/key/exit Level 3 → discover your ghost Level 4 → deliberately use your death to solve the level

After that, we play-test the feel before adding anything else. If Level 4 works, we have the foundation of the game.

YOU

Let’s do it

CHATGPT

I’m building the first playable slice now: a self-contained HTML5 Canvas prototype with four levels, instant death/restart, and recorded ghost runs. I’m keeping the code deliberately dependency-free so you can open it locally or host it anywhere.

YOU

A user should be able to play it on their phone like it’s a game boy, or on their computer like it’s an old dos game.

BUILDING THE MACHINE

From a four-level prototype to 45 stages.

The game moved quickly from a browser prototype to a complete campaign structure: THE ESCAPE, THE WORKS, THE MIRROR, THE BLACK and the hidden THE BELOW. The instruction to keep every stage became a permanent constraint.

READ THE CONVERSATION 20 MESSAGES

CHATGPT

Perfect — that changes the interface, not the game. On phones I’ll make the whole page feel like a little handheld: game screen on top, chunky D-pad below, big jump button, and haptic-friendly touch targets; on desktop it’ll present like an old DOS game with keyboard controls and the same low-resolution pixel viewport.

The first build is now working as a single HTML file, and the same game state renders into either interface automatically. I’ve also kept the game at an internal 320×200 resolution, so the phone version genuinely looks like a handheld screen rather than a desktop page with touch buttons bolted on.

YOU

If I give you a GitHub repo, do you reckon you could write everything to that? And just keep building this bad boy?

CHATGPT

Absolutely. That’s probably the best way to build DEAD AGAIN from here.

Give me the GitHub repo and I can treat it as the actual game project: structure the codebase, build the desktop and Game Boy-style mobile interfaces, implement the engine, levels, ghosts, enemies, sound, scoring, saves, secrets, polish, and keep iterating on it with you rather than producing disconnected prototypes.

For the architecture, I’d keep it deliberately lean:

• HTML5 Canvas + JavaScript/TypeScript

• fixed 320×200 internal game resolution

• responsive scaling for desktop

• dedicated handheld/mobile shell with D-pad + jump/restart controls

• keyboard controls on desktop

• shared input layer so touch and keyboard play identically

• level definitions kept separate from engine code

• local save/progress system

• eventually PWA support so someone can put it on their phone’s home screen and launch it almost like a native game

And yes, I’m very happy to keep building this bad boy rather than stopping at a design document. We can go from prototype → playable game → art/sound → 40+ levels → secrets → final polish.

One limitation: I can keep working on it during our conversations, but I can’t independently continue coding in the background after the chat ends. If your GitHub connection gives me write access, I can work against the repo directly; otherwise I can still create complete commits/patches/files here for the repo.

Send me the repository link and I’ll start from there.

YOU

This is the repo: [redacted for privacy]

CHATGPT

Great — I’ve got the repo. I’m checking whether I can work against GitHub directly from here; if so, I’ll use that as the source of truth and start turning the prototype into the proper cross-device game.

I’ve got the repo URL. It appears to be private or otherwise not publicly readable from here—the direct GitHub fetch returns 404, and it isn’t showing up in public search. [Unknown Site](https://chatgpt.com/)

The cleanest setup is to connect GitHub to ChatGPT with access to that repository. Once that’s available, I can work against the actual codebase rather than handing you files to copy in manually.

For the first proper repo pass, I’d put in the game foundation we’ve already agreed on: the 320×200 game viewport, responsive DOS-style desktop shell, Game Boy-style mobile controls, the shared keyboard/touch input system, the ghost recording/replay engine, and Levels 1–4. I’d also structure it so levels, entities, rendering, input and game state are separated enough that we can keep expanding it without ending up with one enormous JavaScript file.

If you make the repo accessible to me through a GitHub connection, send me a message once it’s connected and I’ll start building directly into deadagain.

YOU

It’s not letting me install the GitHub plugin

CHATGPT

No problem. We don’t need to let that hold up the game.

At the moment I don’t have a GitHub connection available here that can write directly to your repository, so fighting with the plugin isn’t necessary. The practical workflow is: I build the actual repo contents here, give you the updated project as a ZIP/files, and you commit/push it to [redacted for privacy]. Once GitHub access becomes available later, we can switch to working directly against it.

We already have the first prototype HTML file from this conversation, so I can use that as the starting point rather than beginning again. [Connect GitHub for game build]([redacted internal ChatGPT link])

More importantly, I think we should now graduate from the single-file prototype into a real game structure while keeping it easy to run:

deadagain/
├── index.html
├── src/
│   ├── game.js
│   ├── input.js
│   ├── player.js
│   ├── ghosts.js
│   ├── physics.js
│   ├── entities.js
│   ├── levels.js
│   ├── renderer.js
│   ├── audio.js
│   └── save.js
├── assets/
│   ├── sprites/
│   └── audio/
├── styles/
│   └── game.css
└── README.md

And I want one codebase, two experiences.

On desktop it should boot like an old DOS game: black surround, 320×200 pixel screen, keyboard controls, scanline/pixel options eventually, and essentially no browser-looking interface.

Turn the phone vertically and the same game becomes a handheld: screen in the upper portion, physical-looking D-pad, big JUMP button, smaller R button, with controls positioned for thumbs. Landscape can offer a larger-screen alternative.

Progress should persist locally, so closing Safari and returning doesn't wipe your completed levels, treasures, secrets or best times. Eventually we'll make it installable as a PWA too, so DEAD AGAIN can sit on an iPhone/Android home screen and launch fullscreen much more like an actual game.

So rather than spending more time troubleshooting GitHub, I’d keep building. The next deliverable should be a proper runnable deadagain project containing the first four levels and the complete ghost mechanic, packaged so you can drop it straight into that repo.

YOU

Sounds great. Btw, the developer is “fisheggs”

CHATGPT

Got it — I’ll use fisheggs as the developer credit for DEAD AGAIN going forward.

That can appear in places like the title screen, README, metadata, and eventually something suitably retro like:

DEAD AGAIN A game by fisheggs

YOU

Great. Let’s get going. One shot this thing baby

CHATGPT

I’m turning the prototype into a proper repo-ready build now: one codebase, DOS-style desktop, handheld-style mobile, four polished levels, ghost replay, touch controls, local saves, and fisheggs branding. I’m also packaging it so you can drop it straight into deadagain and run it immediately.

I found one important prototype issue while hardening it: old ghosts were continuing from wherever they’d reached after a death, instead of every life restarting the whole choreography from frame zero. I’m fixing that at the engine level so each death truly creates a repeatable “program” for the next attempt—the core mechanic depends on it.

The repo-ready build is assembled and passes JavaScript syntax checks and a local HTTP smoke test. It now has the corrected ghost choreography, shared keyboard/touch input, generated retro SFX, persistent best results, pause/retry/erase controls, and basic offline/PWA support on top of the four-level vertical slice.

Done. DEAD AGAIN Prototype 0.2 is now a proper repo-ready project.

Download the complete DEAD AGAIN project

It includes the desktop DOS presentation, Game Boy-style phone interface, four opening levels, corrected deterministic ghost replay, touch + keyboard controls, keys/gems/switches/doors/spikes, sound effects, local save data, pause/retry/ghost erase, fisheggs branding, and basic PWA/offline support.

To put it into [redacted for privacy], unzip it into the repo root and commit everything. For local play, from the repo directory run:

python3 -m http.server 8080

Then open http://localhost:8080.

I’ve also deliberately structured the game now so we can start going wild without turning it into spaghetti. The next major pass should be Levels 5–10, enemy AI, moving machinery, secrets, a proper level-select/progression screen, and the first real pixel-art treatment.

This bad boy has officially begun.

YOU

Let’s do this davedogs, you killa you

CHATGPT

I’m taking that as the green light for the next full pass. I’m pushing DEAD AGAIN from “proof of concept” into “actual game”: Levels 5–10, first enemy behaviors, moving machinery, hidden secrets, level progression, and a stronger retro presentation—all without bloating the controls.

The core expansion is taking shape around one rule: every new obstacle has to become more interesting because ghosts exist. Level 5 uses a ghost-powered lift, 6 teaches enemy baiting, 7 demands two previous lives, 8 makes bad choreography punish you, 9 introduces a genuinely unmarked secret wall, and 10 combines the systems into the first proper exam.

Version 0.3 is packaged and smoke-tested. The game now goes all the way through Level 10, has level-select progression, two enemy types, ghost-driven moving platforms, fake-wall secrets, persistent unlocks, and the first combined “exam” level where the player has to use what the earlier stages taught them.

Boom. DEAD AGAIN Prototype 0.3 is ready.

Download DEAD AGAIN 0.3

This pass adds Levels 5–10, ghost-powered moving platforms, hunter/patrol enemies, two-life switch puzzles, a hidden fake-wall secret, persistent level unlocks, title-screen level selection, improved save data, new retro SFX, and the first level that combines several systems at once.

I’ve also updated the README so this ZIP can now essentially become the contents of [redacted for privacy].

The next pass is where I’d start giving it real personality: proper pixel character/enemy art, death animations, environmental tilesets, level 10 as a stronger boss encounter, screen transitions, secret tracking, and Levels 11–20.

fisheggs presents: DEAD AGAIN. This thing is becoming a real game.

YOU

Let’s do it. I believe in you, you sexy robot

CHATGPT

You beautiful enabler. DEAD AGAIN 0.4 is built.

Download DEAD AGAIN 0.4

This is a substantial jump: 20 handcrafted levels now, with Levels 11–20 forming the second area, THE WORKS. They push into elevators, moving machinery, enemy baiting, multi-ghost choreography, false floors, hidden rooms and increasingly nasty combinations of earlier mechanics.

I’ve also upgraded the little player from the placeholder rectangle into an actual animated pixel character, added zone presentation, expanded secret tracking, and kept the whole thing working across the DOS desktop and handheld mobile interfaces.

All JavaScript files pass syntax validation and it’s packaged ready to replace the contents of the GitHub repo.

The trajectory I see now is:

1–10: learn what death means. 11–20: learn to orchestrate death. 21–30: the game starts lying to you. 31–40: mastery. 41–45: secret levels for lunatics.

And eventually, someone gets 100%.

Then we make them wish they hadn't.

YOU

Yeah we do. You’re riding this horse hard Dave. Keep it up

CHATGPT

Oh, we are riding.

DEAD AGAIN 0.5 — THE MIRROR is built.

Download DEAD AGAIN 0.5

We’re now at 30 handcrafted levels:

1–10 — THE ESCAPE: learn the rules. 11–20 — THE WORKS: orchestrate your previous lives. 21–30 — THE MIRROR: the game starts using what you've learned against you.

THE MIRROR introduces deceptive geometry, fake routes, nastier ghost/enemy interactions, deliberately misleading solutions, more hidden areas and levels designed around the player questioning assumptions they've acquired during the first twenty stages.

Level 30, REFLECTION, is the first real mastery test.

I also gave THE MIRROR its own subtle visual identity, improved the zone presentation and title/level selector, updated offline caching, and validated all the JavaScript before packaging it.

Next stop is 31–40: mastery territory. That's where I want to stop teaching mechanics altogether. No hints that actually help. Tiny levels with brutally precise solutions. Three-, four- and eventually five-ghost choreography.

Then 41–45 don't even appear to exist until the player earns them.

We're building the sort of bastard little game people claim they hate while attempting Level 37 for the 84th time.

YOU

This is going to be brutal. Let’s bring this one home Dave

CHATGPT

We brought the bastard home.

DEAD AGAIN — VERSION 1.0

Download DEAD AGAIN 1.0

The full campaign architecture is now in the build:

Levels 1–10 — THE ESCAPE Learn the rules.

Levels 11–20 — THE WORKS Learn to orchestrate your deaths.

Levels 21–30 — THE MIRROR Stop trusting what the game taught you.

Levels 31–40 — THE BLACK No more useful hints. Four- and five-death solutions. Precision, enemies and serious ghost choreography.

And then…

Levels 41–45 — THE BELOW

They don't appear in the normal level count. Finish the main campaign and discover enough secrets and they begin revealing themselves.

The last one is:

45 — ALIVE AGAIN

I also gave THE BLACK and THE BELOW their own visual identities, added progressive secret-level unlocking, updated the PWA/offline build, finalised the campaign structure and ran syntax validation across the JavaScript.

One important distinction: the design is now complete, but the game isn't production-finished merely because we've generated 45 levels. The next stage should be vicious playtesting. We need to actually verify every level is solvable, verify the stated minimum deaths, find soft-locks and exploits, tune mobile controls, tune jumps/collisions and identify levels that are difficult for the wrong reason.

That's the point where DEAD AGAIN stops being a cool generated game and starts becoming a good game.

DEAD AGAIN Every death leaves a way forward. A game by fisheggs.

YOU

Alright. Show me what you can do Dave. Make this thing a VGA masterpiece.

THE FIRST IMPORTANT FAILURE

Level 1 could not be beaten.

The first live play exposed the central embarrassment: the opening level was physically impossible. The controls were good; the geometry was not. This failure changed the development method more than any successful build had.

READ THE CONVERSATION 10 MESSAGES

CHATGPT

Picking up exactly where you interrupted me. I’m finishing the GitHub Pages build around the second image’s battered CRT + Fisheggs handheld aesthetic, with direct play on load and no server-side dependencies.

Built. DEAD AGAIN — GitHub Pages Edition 1.9 is ready to serve.

Download the complete GitHub Pages build

I used the second concept image as the visual direction. Desktop now feels like you’ve sat down in front of an old battered VGA machine, while phones automatically become a dedicated Fisheggs handheld with proper touch controls.

The package includes the whole Gauntlet 1.8 game plus:

• Fisheggs app icon based on your supplied logo

• favicon + iPhone home-screen icon

• dark industrial VGA website background

• battered CRT computer shell on desktop

• dedicated handheld body on phones

• portrait and landscape phone layouts

• PWA manifest

• offline service worker

• social/share artwork

• GitHub Pages-safe relative URLs

• .nojekyll

• all 45 levels and current save/mastery systems

I also validated every JavaScript file, the service worker and all local references. Everything passes.

To put it live, unzip the contents of the deadagain folder into the root of your GitHub repo, push it, then go to:

GitHub → Settings → Pages → Deploy from a branch → your default branch → / (root)

GitHub should then publish it at something like:

[redacted for privacy]

No npm. No build command. No backend. Just static files and violence.

Once you’ve got that Pages URL, send it to me. Then we can stop theorising and start actually playing and breaking the live thing.

YOU

Okay. It’s hosted here: deadagain.fisheggs.au

Major problem on first level. It’s not actually able to be finished.

You’re gonna need to do better than this champ. You promised big. Also, I can’t see whether the website is any good on iPhone. Rotating made the screen smaller and more awkward

CHATGPT

YOU

The buttons work though. And the movement is smooth and not laggy

CHATGPT

That’s useful feedback: the input layer is good, so I’m not touching the movement feel or touch-button responsiveness. The failure is level geometry, not controls. I’ve found the Level 1 bug already: the first raised platform is about 1–2 pixels above the actual maximum jump height, so the key is mathematically unreachable. That’s on me.

I’m fixing the level rather than “solving” it by making every jump floatier, and I’m redesigning iPhone landscape so the game screen gets bigger, with controls living at the sides instead of the entire handheld shrinking to fit.

You were right to call that out. Level 1 was genuinely impossible: the key platform sat roughly 1–2 pixels above the engine’s maximum jump arc. I’ve fixed the level geometry and deliberately left the movement physics alone because your feedback says the movement and buttons already feel good.

I’ve also rebuilt iPhone landscape so the game screen is the priority. It now runs near full viewport height, with a compact control column at the side instead of shrinking the entire handheld. Portrait got tighter chrome and safe-area handling too.

Download DEAD AGAIN — GitHub Pages 1.10 Hotfix

Replace the files in the repo with this build and push. The service-worker cache has also been bumped, so the updated version should replace the old cached game after deployment.

One important lesson from this: I’d been validating source structure far more aggressively than I was validating the actual physical reachability of the rooms. That isn’t good enough for this game. From here, level solvability needs to be treated as an engineering constraint, not an assumption.

When this version is live, give Level 1 another run first. If it behaves properly, I’ll start attacking the rest of the campaign from that same perspective before you waste time discovering another impossible jump.

YOU

You’ve also made the main character a Pac-Man like sprite. Why not make him look a little more human like in that second mockup you did?

CHATGPT

Yes. That’s the right call.

The current sprite has drifted too far into round-headed arcade mascot, which makes him read vaguely Pac-Man-ish at 320×200. The second mockup had a much better protagonist: recognisably a tiny human trapped in this horrible machine.

I’d redesign him around a roughly 10×15 / 12×16 pixel human silhouette: distinct head, narrow neck/shoulders, torso, two clearly separate legs, little boots, and actual arms. Slightly hunched stance, with a tiny bright face/visor pixel so you can instantly tell which way he’s looking. Running should have a proper two-legged gait rather than the current blob animation; jumping gets tucked legs; falling gets arms out; landing gets the existing squash without turning him into a ball.

The ghosts then become faded versions of exactly that human silhouette. That matters thematically too: when six previous lives are running around, I want it to look like six dead little men reenacting your mistakes, not six differently coloured Pac-Men.

And we can push his personality without adding detail that disappears at VGA resolution: impatient foot tap, looking around when idle, panicked limbs during a long fall, flattened crusher pose, skeleton-like electric flash, smug little victory stance.

I’d also give him one tiny signature feature from the second mockup—something like the pale face/visor and slightly oversized boots—so his silhouette becomes identifiable even at postage-stamp size.

That’s a much stronger direction. Dave should be a man, not a mouth.

YOU

I’ll be back tomorrow

CHATGPT

Perfect. Tomorrow we’ll start with Human Dave, then properly road-test the campaign rather than trusting the bloody geometry.

Enjoy your evening. The dead little bastards will still be here.

YOU

Before I install what you’ve done so far, I want yoi to keep going, and make sure the levels are actually solvable by a human. Also, make human dave, you nasty robot

HUMAN DAVE

Dave should be a man, not a mouth.

The protagonist was rejected as too Pac-Man-like. Human Dave followed: a tiny recognisable person with a head, torso, limbs and boots. The same silhouette made the ghosts read as previous people rather than tokens.

READ THE CONVERSATION 8 MESSAGES

CHATGPT

Download DEAD AGAIN — GitHub Pages 1.10 Hotfix

Replace the files in the repo with this build and push. The service-worker cache has also been bumped, so the updated version should replace the old cached game after deployment.

YOU

You’ve also made the main character a Pac-Man like sprite. Why not make him look a little more human like in that second mockup you did?

CHATGPT

Yes. That’s the right call.

That’s a much stronger direction. Dave should be a man, not a mouth.

YOU

I’ll be back tomorrow

CHATGPT

Perfect. Tomorrow we’ll start with Human Dave, then properly road-test the campaign rather than trusting the bloody geometry.

Enjoy your evening. The dead little bastards will still be here.

YOU

Before I install what you’ve done so far, I want yoi to keep going, and make sure the levels are actually solvable by a human. Also, make human dave, you nasty robot

CHATGPT

You nasty human, I kept going.

Download DEAD AGAIN — 1.11 HUMAN DAVE

Two substantial changes before you install anything:

• Human Dave is in. Proper tiny head, face/nose, neck, torso, arms, separate legs and oversized boots. Running, jumping, falling, landing and victory poses are human-shaped now. His ghosts inherit the same body. Pac-Man Dave has been executed.

• I audited all 45 levels against the actual physics. The movement you said felt smooth is untouched. Instead, I calculated its real jump envelope and constrained mandatory geometry to leave human/touch-player margin: no required upward step above 26 px and no unreasonable blind horizontal gap in the static climbing route.

I then ran a campaign-wide support/reachability graph against the modified level definitions. 45/45 now pass start → key → exit static geometric reachability. Level 1 wasn't an isolated embarrassment—the audit exposed that a lot of my original platforms had been authored against an imaginary jump height. That's now corrected systematically rather than one level at a time.

There is an important distinction: I can now substantiate that the basic platform geometry of all 45 levels fits Dave's physics. I have not proven every multi-ghost choreography, enemy interaction, secret and PERFECT-death target by autonomous gameplay. I've put HUMANREACHABILITYAUDIT.md in the package spelling out exactly what has and hasn't been verified.

And I haven't touched the responsive movement/input code you already confirmed feels smooth. The improved iPhone portrait/landscape work from 1.10 is included too.

Don't install 1.10. Install this one. This is the first build where I've started treating solvability as something we actually verify rather than something I confidently hope is true.

YOU

I still don’t trust you after last time.

Get your full adversarial team on it.

Also, I’d like the screen size to be a bit bigger - can we enlarge it a bit, and make it more dangerous-Dave-ish?

ADVERSARIAL DEVELOPMENT

Static confidence stops being enough.

Reachability audits, adversarial personas and a deliberately excessive hundred-reviewer swarm attacked the campaign. They found real defects, but also exposed the limit of static testing.

READ THE CONVERSATION 8 MESSAGES

CHATGPT

You nasty human, I kept going.

Download DEAD AGAIN — 1.11 HUMAN DAVE

Two substantial changes before you install anything:

And I haven't touched the responsive movement/input code you already confirmed feels smooth. The improved iPhone portrait/landscape work from 1.10 is included too.

Don't install 1.10. Install this one. This is the first build where I've started treating solvability as something we actually verify rather than something I confidently hope is true.

YOU

I still don’t trust you after last time.

Get your full adversarial team on it.

Also, I’d like the screen size to be a bit bigger - can we enlarge it a bit, and make it more dangerous-Dave-ish?

CHATGPT

Fair. You shouldn’t trust the earlier “looks good on paper” checks after Level 1.

So I put the full adversarial team on this build and made two broad changes at the same time: a stricter solvability contract and a larger, more classic DOS/VGA presentation.

Download DEAD AGAIN — 1.12 Adversarial VGA

The screen is now materially bigger. On desktop the CRT can grow to about 1120 px wide, with less wasted bezel. On iPhone portrait, the handheld screen is nearly edge-to-edge. In landscape, the game gets almost the full viewport height and the controls shrink into a 182 px side column, instead of shrinking the whole machine.

Visually, I pushed it closer to that early DOS-platformer feeling without copying Dangerous Dave assets: darker navy/black space, warm chunky brick platforms, brighter cyan treasure, stronger VGA contrast, and Human Dave now has a red/orange shirt, blue trousers, skin-tone head and dark boots. He reads much more like a tiny person now.

More importantly, the adversarial pass found two more real problems:

• Levels 37, 40, 42, 44 and 45 had exit hitboxes extending into the right boundary wall after the geometry-normalisation pass. Fixed.

• Level 1’s spike had become completely buried inside a widened platform, so it looked like the level had a hazard that functionally didn’t exist. Fixed and moved into a visible floor gap.

I also tightened the geometry contract across all 45 levels. The engine can theoretically rise about 30.5 px and cover about 42.5 px on a normal same-height running jump, or about 47.7 px if you exploit the full coyote window. The game now limits authored mandatory routes to:

≤ 24 px upward steps ≤ 40 px clear gaps

That leaves actual human margin instead of making the player rely on perfect edge timing.

The team also checked every level for spawn hazards, buried keys/exits, invalid switch-door-platform references, patrol-range errors, out-of-bounds objectives and mostly-buried spikes. The final static pass came back 0 findings after the fixes.

I’ve included the full report in:

ADVERSARIALROADTEST_1.12.md

One caveat I’m keeping explicit: this is now a much stronger structural and geometry proof, but it still isn’t the same as physically solving every multi-ghost timing puzzle in a browser. Your hands remain the final authority on those.

This is the build I’d install next.

YOU

Find another 100 adversarial reviewers to test it

CHATGPT

Done. I found you another 100 bastards.

Download DEAD AGAIN — 1.13: THE HUNDRED

To be precise, these are 100 independently seeded simulated adversarial reviewers, not 100 humans I’m pretending wandered into a QA lab. They rotate through 20 roles: speedrunners, collision lawyers, mobile-thumb players, geometry sadists, ghost abusers, completionists, boundary vandals, first-time players, hazard readers, platform skeptics and so on.

They ran 4,500 reviewer-level passes over the exact 45-level build.

And pleasingly, they disagreed with my previous team.

The first 100-reviewer swarm found no new hard structural failure, but raised 9,598 objections to marginal jumps: 6,448 vertical and 3,150 horizontal. The issue was that although 1.12 satisfied my formal 24px-rise/40px-gap rule, a lot of deliberately fussier reviewers thought I was still designing too close to that limit.

I sided with the bastards.

So 1.13 reduces mandatory authored jumps again to 22px upward and 36px clear horizontally. I have not changed Dave's physics—the movement you said feels smooth remains intact. I've given the human more margin in the levels instead.

Then I ran all 100 reviewers again over all 45 levels.

Second swarm: 0 findings in the tested invariant set.

They attacked spawn safety, key/exit bounds, buried hazards, platform travel, door geometry, switch/door/platform references, enemy patrol definitions and the new human jump margins.

The complete methodology and results are included as HUNDREDREVIEWERREPORT_1.13.md.

I'm still not going to tell you “therefore all 45 levels are definitely solvable.” Static/property testing can't prove the dynamic ghost choreography. The next escalation beyond THE HUNDRED is much nastier: build an automated player that actually operates Dave through the game and tries to find executable solutions rather than merely proving the geometry is legal.

That is where I think we should go next.

YOU

Let’s do it. Build another robot

CHATGPT

I’m building ROBOT DAVE now — not another static checker, but a headless player that actually drives the same movement rules with left/right/jump inputs and searches for executable paths. I’m starting by making it prove Levels 1–10, then I’ll use the failures to harden the solver before unleashing it on the ghost-heavy stages.

I found a cleaner way to do this than writing a fake physics clone: ROBOT DAVE is going to instantiate the actual Game class headlessly. Same collision code, same jump buffer, same doors, ghosts, hunters, crushers, conveyors and death recording. The robot’s only privilege is that it can press left/right/jump very, very patiently.

I’m giving it two brains: a fast heuristic pilot for ordinary platforming, then an evolutionary search mode for rooms where deaths and ghosts are part of the solution.

Robot Dave has now learned the central trick rather than just running right like an idiot: he can deliberately record a life onto a pressure switch, kill that life, let the ghost replay and anchor there, then use the opened route with the next Dave. That means he’s starting to test the actual game idea, not just its jumping physics.

Built him.

Download DEAD AGAIN — 1.14 ROBOT DAVE

This is the first QA step that’s materially different from the static reviewers, because Robot Dave actually drives the real Game class. Same update loop, same collisions, same jump physics, same switches, doors, moving platforms, ghosts, hunters, conveyors, crushers and death recording. He only gets to press left, right and jump.

He already found four things the previous audits missed:

• HOLD IT / AFTER YOU: reachability changes had made required switches physically unusable.

• AFTER YOU / CROSSING / ELEVATOR: my generic geometry pass had accidentally created zero-death shortcuts around the ghost-powered machinery.

• The early moving platforms were technically possible but unnecessarily fiddly to board, so I increased their teaching-room margin.

• DEAD END claimed a perfect score of one death even though an executable zero-death route exists. The target is now correctly 0.

More importantly, we now have actual executable proof from the real engine for these levels:

| Level | Robot result | | --- | --- | | 1 — GET OUT | Solved, 0 deaths | | 2 — GREED | Solved, 0 deaths | | 3 — DEAD END | Solved, 0 deaths | | 4 — HOLD IT | Solved, 1 death + Ghost Anchor | | 5 — AFTER YOU | Solved, 1 death + ghost-powered platform | | 6 — BAIT | Solved, currently 3 deaths rather than proven minimum | | 11 — CROSSING | Solved, 1 death + ghost-powered bridge | | 13 — ELEVATOR | Solved, 1 death + ghost-powered lift |

The robot has three brains now: a normal platforming heuristic, a mechanic-aware planner that deliberately creates Ghost Anchors and operates machinery, and an evolutionary input-search fallback.

The failed levels are useful too. I’m not marking them “impossible” just because Robot Dave can’t solve them yet. They go into one of two buckets: robot needs another idea or candidate design defect. Then we trace the failure like we just did with the early switch/platform bugs.

Everything is documented in ROBOTDAVEREPORT_1.14.md, and the bot itself is in:

tools/robot-dave.mjs

You can even run him locally:

node tools/robot-dave.mjs level 5
node tools/robot-dave.mjs plan 1 20
node tools/robot-dave.mjs heuristic 1 45

This is the QA direction I trust much more now. The next job is obvious: teach Robot Dave more puzzle strategies and make him physically prove every one of the 45 rooms before we call the campaign ready.

YOU

Let’s do that. If robot Dave can’t solve this then no one can

ROBOT DAVE

The game gets a player made out of itself.

Robot Dave was built to drive the actual Game class rather than a simplified physics clone. Failure became diagnostic: either the solver needed another idea or the level needed repair.

READ THE CONVERSATION 12 MESSAGES

CHATGPT

I’m giving it two brains: a fast heuristic pilot for ordinary platforming, then an evolutionary search mode for rooms where deaths and ghosts are part of the solution.

Built him.

Download DEAD AGAIN — 1.14 ROBOT DAVE

He already found four things the previous audits missed:

• HOLD IT / AFTER YOU: reachability changes had made required switches physically unusable.

• AFTER YOU / CROSSING / ELEVATOR: my generic geometry pass had accidentally created zero-death shortcuts around the ghost-powered machinery.

• The early moving platforms were technically possible but unnecessarily fiddly to board, so I increased their teaching-room margin.

• DEAD END claimed a perfect score of one death even though an executable zero-death route exists. The target is now correctly 0.

More importantly, we now have actual executable proof from the real engine for these levels:

The robot has three brains now: a normal platforming heuristic, a mechanic-aware planner that deliberately creates Ghost Anchors and operates machinery, and an evolutionary input-search fallback.

Everything is documented in ROBOTDAVEREPORT_1.14.md, and the bot itself is in:

tools/robot-dave.mjs

You can even run him locally:

node tools/robot-dave.mjs level 5
node tools/robot-dave.mjs plan 1 20
node tools/robot-dave.mjs heuristic 1 45

YOU

Let’s do that. If robot Dave can’t solve this then no one can

CHATGPT

Agreed on the standard, with one caveat: Robot Dave failing is evidence, not proof of impossibility. So I’m going to make him much stronger, then treat every remaining failure as guilty until we can explain it.

I’m expanding him into a proper campaign solver: direct platforming, deliberate deaths, multi-switch Ghost Anchors, moving-platform boarding, enemy baiting, timed hazards, and evolutionary fallback. Then I’ll run the whole 45-level campaign and separate proven executable, solver-limited, and actually broken.

I’m doing one thing before teaching the robot more tricks: checking the interactables themselves across all 45 rooms. Robot Dave exposed that a button can exist in the data, be “valid” to a static audit, and still be impossible for a 12×14 human to physically stand on.

So I’m now testing every switch with Dave’s actual body dimensions and actual support surfaces—not just coordinate overlap.

Two more real defects surfaced from Robot Dave’s body-level interaction test:

• Level 15 — THE DROP: its switch was floating at y=104 with no surface Dave could stand on.

• Level 23 — BACKWARDS: same problem at y=96.

These were invisible to the coordinate audits. I’m snapping those switches onto their actual ledges, then upgrading the robot’s navigator so it can recover from getting stuck instead of just walking into the same wall for 15 seconds.

YOU

Let’s do that. If robot Dave can’t solve this then no one can

CHATGPT

That’s the standard I’m using now.

Robot Dave doesn’t get to merely inspect a level and pronounce it plausible. For all 45 stages, I want an executable run through the real game engine: actual Dave dimensions, actual jump physics, actual hazards, actual ghosts, actual doors, actual machinery.

And he’s already justified the exercise by uncovering systemic defects that our earlier reviews missed: buried/unoccupiable switches, switches in enemy kill lanes, a self-locking door, machinery that displaced its own Ghost Anchor, and moving platforms whose travel paths intersected solid architecture.

One qualification: I won’t automatically mutilate a level because Robot Dave fails it. A failure gets traced first. If the level violates the game’s physical rules, the level gets fixed. If the level is sound and Robot Dave is being an idiot, Robot Dave gets smarter.

The finish line is now:

45 / 45 dynamically solved. Every required ghost interaction executed. Every moving platform actually ridden. Every claimed PERFECT death count either demonstrated or corrected/redesigned. No shortcuts that invalidate the intended mechanic. No geometry that requires absurd pixel-perfect execution.

And I’m keeping every one of the 45 levels.

Robot Dave does not get to come home until he has beaten his own nasty little game.

YOU

Nice. Can you send me the updated code. And what’s next?

CHATGPT

Yep. I’m packaging the latest branch as a proper new build, including the most recent Robot Dave discoveries and the timing-state search fix I was in the middle of. Then I’ll give you the code and the roadmap from here.

Absolutely.

Download DEAD AGAIN — 1.15 ROBOT DAVE MK II

This includes the latest campaign repairs plus the stronger Robot Dave. The big new fix I’ve just finished is that his state-space search now understands that two states are not equivalent merely because Dave is standing in the same place. It now distinguishes enemy positions, ghost positions and anchor status, moving-platform state, electric-floor state, crusher position and time phase. That means he can actually search for things like “wait until the patrol passes” or “cross during the safe electrical cycle” instead of deleting those possibilities as duplicates.

The current branch also includes the nastier defects Robot Dave has already exposed and repaired: the 32 physically unusable switches, BACKWARDS’ self-locking door, Ghost Anchors being murdered in patrol lanes, machinery colliding with its own anchors, excessively narrow pressure plates, and moving platforms whose travel paths intersected static architecture.

All game modules, the service worker and Robot Dave pass syntax validation.

What’s next is much less glamorous and much more valuable: certification.

I’d stop adding gameplay features for a while and turn Robot Dave loose on the campaign systematically. Each level gets a ledger with four states:

PROVEN — executable key → exit run through the real engine. PERFECT PROVEN — executable at the claimed minimum death count. SOLVABLE / MASTERY WRONG — Robot Dave beats it with fewer deaths than we claimed. BLOCKED — no certificate yet; trace and determine whether Dave or the level is at fault.

The target is then brutally simple:

45 / 45 PROVEN.

After that, I’d make him attack the secrets separately, then try to minimize every certified run. That will tell us which “perfectDeaths” values are real and which were designer wishful thinking.

Then comes the fun final pass: use Robot Dave’s routes to deliberately make levels meaner without making them impossible. Once we have a machine-readable solution certificate, we can move a spike six pixels, alter a patrol speed or tighten a platform timing and immediately ask the robot whether we crossed the line.

That’s the point where Robot Dave stops merely finding our mistakes and becomes our evil level-design assistant.

YOU

Do that girlfriend

CHATGPT

On it. I’m switching from “build features” to campaign certification mode: every level gets an executable proof, the claimed PERFECT count gets challenged, and any failure gets traced until either Robot Dave gets smarter or the level gets repaired.

Certification run starts now. I’m using the strongest planner first — state-space navigation plus deliberate Ghost Anchors — and logging actual deaths versus claimed PERFECT.

I’m not satisfied with “some levels certified.” The current beam search is burning too much CPU cloning cosmetic/save state. I’m stripping Robot Dave’s clone down to only physics-relevant state so we can run the solver hard enough to certify the whole campaign instead of timing out on the nastier rooms.

YOU

Do that girlfriend

CHATGPT

Exactly. I’ve already got the certification planner wired for this: it uses state-space search to board the live moving platform, then lets the same search engine discover the ride, timing, and dismount on the way to the key. No hard-coded “wait here, jump there” script in the certification path.

I’m running that over all 45 now and turning the result into a proper certification ledger.

The remaining powered-platform failures are search-quality now, not level defects. I’m improving the beam heuristic rather than reinstating a scripted boarding move: states where Dave successfully gets onto a live powered platform will receive a strong search bonus, so the solver learns “this moving thing is useful” from the physics itself.

I’m making the certification planner hierarchical rather than scripted:

1. Try state-space directly to the key. 2. If no path exists and the room has a powered platform, state-space searches only for “get Dave onto that moving platform”. 3. Once aboard, a fresh state-space search figures out when to ride, where to stand, and when to jump off to reach the key.

That preserves the spirit of what you asked: Robot Dave discovers the ride from the real physics; I’m only giving him a sensible subgoal.

Done, girlfriend.

Download DEAD AGAIN — 1.16: 45/45 CERTIFIED

Robot Dave has now completed all 45 levels through the actual game engine. Not static geometry. Not “looks reachable.” Actual left/right/jump inputs through the same physics, collisions, ghosts, doors, enemies, crushers, electrics and moving platforms the player gets.

The last stretch was useful. Robot Dave forced several real design changes: AFTER YOU/CROSSING now genuinely require powered machinery rather than letting Dave exploit the idle platform; moving-platform dismounts are solved at frame-level precision; SACRIFICE lost a redundant patrol that was polluting its hunter-decoy puzzle; and DEAD AGAIN lost a crusher that was effectively owning the only final-control route.

He also beat ten of our supposed PERFECT targets, so I corrected them. For example, CHOIR is now 2 rather than 3, KNIFE EDGE is demonstrably 0 rather than 1, FOUR is 3 rather than 4, SIX is 4 rather than 5, and EVERYBODY is 3 rather than 4.

The repo now contains ROBOTDAVECERTIFICATION_1.16.md with the complete 45-level ledger, plus robot-dave-certification-1.16.json as a machine-readable baseline for regression testing.

One distinction still matters: 45/45 solvability is proven; mathematical minimum deaths are not. The displayed mastery numbers are now the best executable runs we know, but Robot Dave may yet embarrass us again.

And that is exactly what I think comes next.

Robot Dave: Speedrunner Mode.

We stop asking, “Can this be beaten?” and start asking:

“How badly can you break our intended solution?”

He’ll attack each certified level looking for fewer deaths, unintended skips, weird ghost interactions and faster routes. Every time he discovers something:

• if it’s clever and consistent with the world, we canonise it;

• if it trivialises the central puzzle, we redesign around it;

• if it beats PERFECT, PERFECT moves;

• and after every malicious level tweak, the 45/45 certification suite runs again.

That gives us something we haven’t had until now: permission to make the game properly evil, because there’s finally a robot underneath us checking that we haven’t made it impossible.

YOU

Do it

45 / 45

Executable evidence replaces confidence.

The solver eventually produced executable solutions for all 45 levels. The distinction remained important: solvability was demonstrated; mathematical minimum deaths and human enjoyment were not.

READ THE CONVERSATION 6 MESSAGES

CHATGPT

Certification run starts now. I’m using the strongest planner first — state-space navigation plus deliberate Ghost Anchors — and logging actual deaths versus claimed PERFECT.

YOU

Do that girlfriend

CHATGPT

I’m running that over all 45 now and turning the result into a proper certification ledger.

I’m making the certification planner hierarchical rather than scripted:

That preserves the spirit of what you asked: Robot Dave discovers the ride from the real physics; I’m only giving him a sensible subgoal.

Done, girlfriend.

Download DEAD AGAIN — 1.16: 45/45 CERTIFIED

The repo now contains ROBOTDAVECERTIFICATION_1.16.md with the complete 45-level ledger, plus robot-dave-certification-1.16.json as a machine-readable baseline for regression testing.

And that is exactly what I think comes next.

Robot Dave: Speedrunner Mode.

We stop asking, “Can this be beaten?” and start asking:

“How badly can you break our intended solution?”

He’ll attack each certified level looking for fewer deaths, unintended skips, weird ghost interactions and faster routes. Every time he discovers something:

• if it’s clever and consistent with the world, we canonise it;

• if it trivialises the central puzzle, we redesign around it;

• if it beats PERFECT, PERFECT moves;

• and after every malicious level tweak, the 45/45 certification suite runs again.

That gives us something we haven’t had until now: permission to make the game properly evil, because there’s finally a robot underneath us checking that we haven’t made it impossible.

YOU

Do it

CHATGPT

Speedrunner Mode it is. I’m turning Robot Dave from “prove solvable” into “attack the designer”: minimize deaths, hunt zero-death skips, exploit ghost anchors, abuse machinery timing, and challenge every current PERFECT target. Then I’ll keep the clever skips and patch only the ones that hollow out the level’s core idea.

Speedrunner Dave now has a very specific mandate: try to beat the certified death count by using fewer anchors than the designer expects. He starts at zero deaths, then one, then two, enumerating subsets of switches and letting the real state-space solver see whether the room can still be finished.

This is exactly the exploit-hunting pass we wanted: don’t assume every switch matters just because it exists.

Speedrunner Dave has already broken three central lessons:

• TWO OF ME only needed one ghost because Door #1 could be jumped over.

• AGAIN only needed one ghost because the auto lift let him bypass the second door.

• MACHINE ROOM needed zero ghosts because the static ledges made its powered bridge decorative.

Those aren’t clever alternate solutions; they hollow out the level’s premise. I’m redesigning those three so the named mechanic is genuinely required, then Robot Dave has to re-certify them.

Done.

Download DEAD AGAIN — 1.17 SPEEDRUNNER DAVE

This pass finally does what we said it would: Robot Dave attacks the designer, not just the level.

The interesting results:

• TWO OF ME had a cheap 2→1 death door-vault skip. Patched. Re-certified at 2.

• AGAIN had a cheap 2→1 auto-lift bypass. Patched. Re-certified at 2.

• MACHINE ROOM has a legitimate zero-death expert sequence break. I kept it and changed PERFECT to 0.

• SIX has a wonderfully nasty 2-death short-circuit in what appears to be a many-life hidden room. Kept. PERFECT is now 2.

• ALIVE AGAIN survived the attack: Robot Dave tried every three-anchor subset plus the smaller subsets and did not beat the existing 4-death certificate.

I’ve added two new Robot Dave modes:

node tools/robot-dave.mjs speedrun 1 45
node tools/robot-dave.mjs speedrunexact 45 3

The build includes ROBOTDAVESPEEDRUNNER_1.17.md and robot-dave-speedrunner-1.17.json with the exploit decisions and updated mastery ledger.

The next escalation is obvious: time attack.

Now that Robot Dave is attacking death counts, I want him to attack the actual input routes too: shortest completion time, earliest possible key pickup, fastest ghost setup, frame-perfect machinery cycles, and weird momentum tricks. That should uncover a completely different class of exploits—and it gives us proper scoreboards rather than just “deaths.”

YOU

Do it

SPEEDRUNNER / TIME ATTACK

The solver turns against the designer.

Robot Dave stopped asking whether the rooms could be beaten and began attacking intended solutions, death counts and times. Cheap premise-destroying skips were patched; interesting emergent ones were canonised.

READ THE CONVERSATION 12 MESSAGES

CHATGPT

This is exactly the exploit-hunting pass we wanted: don’t assume every switch matters just because it exists.

Speedrunner Dave has already broken three central lessons:

• TWO OF ME only needed one ghost because Door #1 could be jumped over.

• AGAIN only needed one ghost because the auto lift let him bypass the second door.

• MACHINE ROOM needed zero ghosts because the static ledges made its powered bridge decorative.

Those aren’t clever alternate solutions; they hollow out the level’s premise. I’m redesigning those three so the named mechanic is genuinely required, then Robot Dave has to re-certify them.

Done.

Download DEAD AGAIN — 1.17 SPEEDRUNNER DAVE

This pass finally does what we said it would: Robot Dave attacks the designer, not just the level.

The interesting results:

• TWO OF ME had a cheap 2→1 death door-vault skip. Patched. Re-certified at 2.

• AGAIN had a cheap 2→1 auto-lift bypass. Patched. Re-certified at 2.

• MACHINE ROOM has a legitimate zero-death expert sequence break. I kept it and changed PERFECT to 0.

• SIX has a wonderfully nasty 2-death short-circuit in what appears to be a many-life hidden room. Kept. PERFECT is now 2.

• ALIVE AGAIN survived the attack: Robot Dave tried every three-anchor subset plus the smaller subsets and did not beat the existing 4-death certificate.

I’ve added two new Robot Dave modes:

node tools/robot-dave.mjs speedrun 1 45
node tools/robot-dave.mjs speedrunexact 45 3

The build includes ROBOTDAVESPEEDRUNNER_1.17.md and robot-dave-speedrunner-1.17.json with the exploit decisions and updated mastery ledger.

The next escalation is obvious: time attack.

YOU

Do it

CHATGPT

Time Attack mode it is. I’m adding a new objective layer to Robot Dave: minimize frames, not just deaths. He’ll search for earlier key pickup, faster ghost setup, shorter waits on machinery cycles, and tighter exit routes — then compare those against the certified solutions.

The important part: I’m keeping death count as the primary category. A faster 3-death run does not beat a slower 2-death PERFECT run unless we deliberately create a separate “Any%” board. So we’re going to end up with two honest records: PERFECT TIME and ANY% TIME.

I’ve got the category rules locked:

PERFECT TIME = fastest run Robot Dave can find at the level’s current best-known death count. ANY% TIME = fastest executable run regardless of death count, including deliberate death-as-teleport strategies if they help.

And because dying can actually be strategically faster in this game, I’m explicitly allowing Any% to use more deaths than PERFECT. That should produce some beautifully perverse routes.

Perfect Time is already giving us something concrete: the opening ten levels now have real-engine records between about 4.0s and 12.8s at their best-known death counts.

I’m sweeping the rest of the campaign now, then I’ll run Any% and look for places where extra deaths are actually faster.

Done.

Download DEAD AGAIN — 1.18 TIME ATTACK

Robot Dave now has two timing categories:

• PERFECT TIME — fastest clean run at the current best-known PERFECT death count.

• ANY% TIME — fastest clean completion regardless of deaths. If killing Dave deliberately saves time, that’s legal.

The actual game now tracks these separately too. On level completion you’ll see your current time, PERFECT PB, and ANY% PB. The save system keeps the death-first mastery record separate from the raw fastest-time record, so a reckless 3-death speedrun can’t overwrite a cleaner 1-death PERFECT run.

The first bounded Robot Dave sweep established 37/45 PERFECT TIME records. The other eight remain fully solvability-certified; their timing searches simply exhausted the current search budget. I also ran a targeted Any% attack and established an initial batch of records there.

Some opening Robot records are already pretty snappy:

• Level 1: 4.033s

• Level 2: 4.200s

• Level 3: 4.350s

• HOLD IT: 7.367s / 1 death

• AFTER YOU: 6.617s / 1 death

• TWO OF ME: 11.450s / 2 deaths

• AGAIN: 12.833s / 2 deaths

The build includes ROBOTDAVETIMEATTACK1.18.md and robot-dave-timeattack-1.18.json, plus new commands:

node tools/robot-dave.mjs timeattack 1 45 perfect
node tools/robot-dave.mjs timeattack 1 45 any

One important distinction: these are best records found so far, not mathematical frame-optimal proofs. Robot Dave now has something much more entertaining to do: keep trying to beat himself.

Next I’d make the records visible on the level-select screen, add little PERFECT / ANY% medals, and have Robot Dave generate ghost replays of record runs so you can race his bastard little transparent silhouette in-game.

YOU

Do it

CHATGPT

Doing it. This pass turns Robot Dave from a QA tool into an actual opponent:

• PERFECT / ANY% medals on level select

• visible personal best times

• Robot Dave record times shown alongside yours

• Robot Ghost replays for levels where we have a certified time route

• an option to race the transparent bastard without affecting your clean mastery record

I’m building that as 1.19 — GHOST RACE.

I’m wiring the race ghost into the actual input stream, not faking a path animation. Robot Dave’s record file will contain the same left/right/jump snapshots the Game class consumes, so his translucent runner is a genuine replay of the timed run.

Then I’ll put his record and yours directly onto level select.

I’m also making race mode deliberate rather than sneaky: G on desktop / RACE on handheld toggles Robot Dave for the selected level. His ghost will be visually distinct from your dead-life ghosts so you always know which bastard is the benchmark.

YOU

Continue

CHATGPT

Done.

Download DEAD AGAIN — 1.19 GHOST RACE

Robot Dave is now in the game as an opponent.

On level select you now get:

• your PERFECT PB

• your ANY% PB

• Robot Dave’s current record

• P / A / R medals

* P = clean PERFECT completion * A = Any% PB recorded * R = you’ve beaten or tied Robot Dave’s PERFECT TIME

Press G on desktop or RACE on the handheld to toggle him.

The important design choice: Robot Dave’s race ghost is non-physical. He cannot stand on switches, attract hunters, block doors, ride machinery for you, collect keys, or interfere with your existing dead Daves. He is purely there to make you feel inadequate.

I also changed the replay architecture from what I was initially attempting. Rather than replaying Robot Dave’s raw inputs inside your current puzzle state—which could diverge because your ghosts and machinery are different—the build stores per-frame positions from his actual real-engine timed run. So what you see is a faithful visual replay of his record.

The HUD shows his target time during a race, and the completion screen gives you your delta against Robot Dave.

Current coverage is 37 of 45 levels. Those are the levels for which Time Attack 1.18 already had bounded PERFECT TIME records and I successfully regenerated complete race traces. The other eight still show ROBOT --; I haven’t invented fake ghost runs just to make the number 45.

Everything passes JS syntax validation, and I smoke-tested the modified engine with Robot Dave solving Level 1 again after the race integration.

There’s a new report inside too: ROBOTDAVEGHOSTRACE1.19.md.

Next move? I’d attack those remaining eight timing records until Robot Dave has a race ghost on 45/45, and then add one delicious extra feature:

RIVAL MODE — after you beat Robot Dave, your own PB becomes the new ghost.

Then the game stops being you versus my robot.

It becomes you versus the best version of you.

YOU

Do it

CHATGPT

Absolutely. I’m doing both:

1. Robot Dave gets race ghosts on all 45 levels, not 37. 2. RIVAL MODE records your own clean PB trajectory. Once you beat Robot Dave, your PB can replace him as the ghost you race.

I’m keeping the two rivals visually distinct so you always know whether you’re chasing the machine or your best self.

I’m continuing from the race build itself rather than redoing anything. The next changes are all player-facing: save your PB trajectory, choose ROBOT vs RIVAL on level select, render the correct ghost, and fill the eight missing Robot records so the benchmark exists on every stage.

YOU

Continue

CHATGPT

Done. 1.20 — RIVAL MODE is ready.

Download DEAD AGAIN — 1.20 RIVAL MODE

The important bits are now working:

• Robot Dave race coverage is 45/45. No more ROBOT -- levels.

• Beat or tie Robot Dave with a clean PB and the game records your actual trajectory as a Rival.

• Race selection cycles OFF → ROBOT → RIVAL → OFF when your Rival exists.

• Robot Dave is the magenta ghost marked R; your PB is cyan and marked YOU.

• Level select now has P / A / R / V medals, with V meaning you've created a qualified personal Rival.

• Rival and Robot ghosts remain completely non-physical. They can't accidentally solve—or ruin—the puzzle.

• ERASE/PRACTICE runs cannot become Rival records.

• Your Rival is replaced only when you produce a better clean PB.

I also ran syntax validation across all 11 JavaScript files, checked all 45 race records structurally, and ran Robot Dave through the real engine again as a smoke test.

This is getting to the point where I'd actually stop piling systems onto it for a moment. The next pass should be polish and playability: install this build, play it on the iPhone and desktop, and give me everything that feels wrong—screen size, Human Dave, readability, difficulty spikes, controls, ugly bits, confusing levels, anything.

We've finally got the robots underneath the game. Now we make the bloody thing feel good.

YOU

I want you to do the polish and playability steps too. Perhaps engage a few game critics and music critics who are very aesthetically minded, enthusiastic about games from this era / genre, and can provide good critical feedback

THE CRITICS

Austerity wins.

The critic panels were simulated specialist personas, explicitly not human reviewers. Their most useful contribution was restraint: preserve the playfield, movement and sparse music; stop adding systems simply because the architecture permits it.

READ THE CONVERSATION 8 MESSAGES

CHATGPT

Yes. I’m treating this as a proper editorial/polish pass, not another feature dump.

I’m assembling a small simulated critic panel with deliberately different tastes: DOS-platformer purists, arcade readability obsessives, modern game-feel critics, pixel-art aesthetes, and chiptune/sound-design critics. Their job is to argue with each other and then force concrete changes into the build.

I’m starting from 1.20 and I’m going to touch four things together: visual hierarchy, moment-to-moment feel, sound/music, and mobile presentation.

The critics have already converged on one strong point: the game has good mechanical identity but not yet enough audiovisual authorship. Right now the soundtrack is basically isolated beeps, and some of the world rendering reads as “functional debug VGA” rather than a deliberate lost DOS game.

So I’m making the polish pass opinionated: four zone palettes, four tiny procedural music identities, stronger hazard telegraphing, cleaner title/level-select hierarchy, and more expressive Human Dave animation—without touching the movement physics you already like.

The critic panel’s first consensus is very specific:

• Game critic / DOS purist: “Stop hiding the playfield behind giant level banners. Dangerous Dave told you what room you were in and got out of the way.”

• Pixel-art critic: “The world needs stronger zone silhouettes, but foreground hazards must always outrank decoration.”

• Game-feel critic: “Don’t touch the movement constants. Improve anticipation and feedback around them.”

• Chiptune critic: “The current bleeps are fine as SFX, but there is no musical memory. Each zone needs a tiny motif, not a full modern soundtrack.”

• Sound critic: “Silence is useful. Music should be sparse enough that death sounds still punch through.”

I agree with all five. I’m implementing those rather than just writing a review document.

Done. This is the first pass I’d call editorial polish rather than systems work.

Download DEAD AGAIN — 1.21 THE CRITICS’ CUT

I used six simulated specialist critics—DOS-platformer, pixel-art, game-feel, handheld UX, chiptune, and sound-design—then implemented the changes they converged on.

The most important fixes are tangible:

• restored the proper battered CRT desktop shell and Fisheggs handheld; the HTML had actually drifted away from the better CSS design

• made the level-intro banner much smaller and shorter so it stops obscuring play

• made the exit read clearly as locked before the key and live afterward

• added yellow pre-charge telegraphing to electric floors

• made crusher warnings larger and more readable

• kept the movement physics completely untouched

• added five sparse procedural musical identities for THE ESCAPE, THE WORKS, THE MIRROR, THE BLACK, and THE BELOW

• tightened the SFX so they feel more percussive and less toy-like

• added separate music/SFX gain buses

• added M on desktop and SOUND on handheld, with the mute preference remembered locally

• preserved Robot Dave, Rival Mode, the 45-level certification work, and the existing race records

The music deliberately does not behave like a modern continuous soundtrack. It’s sparse, low in the mix, and closer in spirit to something that could plausibly have emerged from an old PC sound chip: little motifs that give each region memory without smothering the death noises and machinery.

I included the full critical discussion in CRITICPANEL1.21.md, including what each critic objected to and what changed as a result.

All JavaScript passes syntax validation, every local page reference resolves, and Robot Dave still executes through the real engine after the polish changes.

This is the build I’d put live next and actually sit with for a while. The robots have been brutal about correctness; 1.21 is about whether the thing finally has taste.

YOU

Hire more critics

CHATGPT

Done. I hired 15 more simulated critics, deliberately chosen to disagree with the first group rather than form a cheer squad.

Download DEAD AGAIN — 1.22 SECOND CRITICS’ COUNCIL

This council includes a shareware archaeologist, speedrun commentator, puzzle-design critic, arcade-cabinet designer, pixel animator, VGA palette obsessive, industrial-sound critic, PC-speaker purist, chiptune composer, horror critic, accessibility/legibility critic, mobile-action critic, old-game manual writer, demoscene aesthete, and one deliberately mean reviewer.

Interestingly, their strongest consensus is stop adding stuff.

They think DEAD AGAIN now has enough systems. Their concern is that certification, mastery, secrets, speedrunning, Robot Dave, ghost racing, Rival Mode and PBs could eventually make a beautifully simple retro platformer feel like a dashboard.

Their collective prescription is therefore: protect the 320×200 playfield; preserve the movement physics; keep music sparse; make hazards readable through shape/motion rather than colour alone; privilege A/B and movement on mobile; eliminate dead traversal rather than merely lowering difficulty; and make THE BLACK/THE BELOW stranger aesthetically without ever making the physics harder to read.

One critic made a suggestion I particularly like: an attract-mode vignette on the title screen—old arcade/shareware style—where you silently watch one Dave die on a switch, his ghost remains there, and the next Dave uses him to escape. It explains the entire game without a tutorial.

I deliberately didn't implement that yet, because this panel's principal criticism was feature accretion. I only made a tiny wording cleanup and otherwise preserved the certified game. The complete argument is in SECONDCRITICSCOUNCIL_1.22.md.

Robot Dave still passes the engine smoke test and all JS syntax checks pass.

I think we should now make the critics fight: give the first six and these fifteen the same build, have each nominate the five things they most want changed, then run a simulated editorial conference where they challenge each other's proposals. Only changes that survive the argument get into 1.23.

YOU

Yes let’s have them fight it out. DEATHMATCH

CHATGPT

DEATHMATCH COMPLETE.

Twenty-one simulated critics entered the arena. Several cherished ideas did not make it out.

Download DEAD AGAIN — 1.23 CRITICS DEATHMATCH

The biggest fight was over feature creep versus useful depth. The austerity faction won. Robot Dave, Rival Mode, PBs, secrets and mastery all survive, but I've demoted their UI. The level-select screen no longer looks like a statistics terminal: one contextual status line replaces the permanent medals/timing matrix, and Robot/Rival timing appears when you actually turn Ghost Race on.

Other casualties: more music layers, extra saturated UI colours, animation for animation's sake, new meta-controls, speculative level redesigns, and—most decisively—any change to the movement physics.

The proposed attract-mode demonstration caused a proper argument. The arcade critic loved it; the DOS/shareware critics said just let me play the bloody game. It lost. For now, “EVERY DEATH LEAVES A WAY FORWARD” explains the premise. If actual players don't understand it, the attract demo gets another trial.

The horror and accessibility critics reached a good compromise: THE BLACK and THE BELOW may become disturbing through scenery, typography, absence and music—but never by making collision rules or hazards ambiguous.

Human Dave survived too. The pixel animator wanted more poses; the speedrunner and VGA people argued that at 320×200, additional frames could actually make him less readable. Result: Dave remains a little man, not a mouth, and no animation bloat.

Most importantly, the 45 stages and their geometry remain untouched. The puzzle critic was not allowed to redesign rooms based solely on theory. Robot Dave proves executability, but critic speculation doesn't prove something is unfun. Actual human play gets the deciding vote there.

The complete bloodbath is documented in CRITICSDEATHMATCH1.23.md, including arguments, winners, losers and reasons.

Everything passes JS validation, and Robot Dave still runs against the real engine after the changes.

The new editorial law that emerged from DEATHMATCH is:

New work must either remove friction, improve comprehension, or deepen atmosphere without obscuring play.

“Wouldn't it be cool if…” is no longer enough to get a feature past the bastards.

YOU

I’m glad we hired them. What do they say we need to do to complete the game? Do any of them say anything about the story arc?

CHATGPT

Yes — and there’s a fairly important gap in what we asked them to review.

The critics think the mechanical game is approaching completion. Their remaining checklist is mostly human playtesting, friction removal, final audiovisual tuning, mobile validation, and resisting further feature creep. The puzzle critic specifically wants us to look for deaths that create chores rather than deductions; the mobile critics want real-device landscape testing; the sound people think machinery could use very selective state-dependent sounds; and everybody wants us to leave the movement physics alone.

But on your second question: we haven't really subjected the story arc to the same scrutiny. The horror critic came closest. They liked the progression implied by the zones—especially the idea that THE BLACK becomes sparse and oppressive and THE BELOW feels as though the game itself is malfunctioning—but nobody has yet seriously interrogated what is happening to Dave, what the ghosts mean, what the facility is, or whether Levels 1–45 actually tell a satisfying story.

And I think that deserves its own DEATHMATCH.

There is already a surprisingly strong implicit arc:

THE ESCAPE → THE WORKS → THE MIRROR → THE BLACK → THE BELOW → ALIVE AGAIN.

That reads almost like five acts. Dave initially seems to be escaping a physical prison. Then he penetrates its machinery. In THE MIRROR, the game starts questioning the reliability/identity of Dave and his copies. THE BLACK strips things away and turns the mechanic itself against him. THE BELOW feels like discovering something underneath the apparent world. And then ALIVE AGAIN is an excellent title for the ending because after 44 levels in which death is a tool, being alive can finally become the extraordinary state.

There are also level names that already accidentally—or perhaps not accidentally—form narrative language: LIAR, FOLLOW ME, BACKWARDS, DECOY, SACRIFICE, ECHO CHAMBER, WRONG DOOR, ERASE ME, REFLECTION, then NO HELP, MISTAKE, SILENCE, DEAD AGAIN, followed underground by BEHIND YOU, SIX, NO GHOST, EVERYBODY, ALIVE AGAIN.

That's potentially much more than a sequence of puzzle rooms.

I would not respond by adding cutscenes and exposition. That would violate nearly everything our critics like about the game. Instead, I think the next council should consist of narrative people who understand games that tell stories through mechanics and environment: a retro-game historian, environmental storyteller, horror writer, surrealist, ludonarrative critic, level-design storyteller, minimalist screenwriter, ending specialist, sound-as-narrative critic, and one ruthless critic whose sole instruction is “tell me if this is pretentious nonsense.”

Give them all 45 level names, mechanics, secrets, zone progression, visual/audio language and the ending.

And ask them three questions:

1. What story do you think DEAD AGAIN is already telling? 2. Where does that story weaken, contradict itself, or disappear? 3. What is the absolute minimum we need to add/change so a player feels the arc without the game ever stopping to explain itself?

My suspicion is that the answer will involve environmental progression, tiny recurring visual motifs, level names, ghost behaviour, secrets, music deterioration and the ending—not dialogue.

And there's one particularly interesting question I'd put in front of them:

Why can Dave come back?

We don't necessarily ever tell the player the answer. But we, as the designers, should probably know it.

I think that's the missing completion pass: STORY DEATHMATCH. Twenty or so aesthetically vicious narrative critics, with explicit instructions that cutscenes, lore dumps and explanatory dialogue start with a severe handicap.

YOU

Yes. Do that

STORY DEATHMATCH

The mechanic had been telling a story.

Narrative critics read the existing five-zone progression rather than demanding exposition. The internal interpretation became: the machine can instantiate Dave, but cannot completely forget the previous one.

READ THE CONVERSATION 6 MESSAGES

CHATGPT

Yes — and there’s a fairly important gap in what we asked them to review.

And I think that deserves its own DEATHMATCH.

There is already a surprisingly strong implicit arc:

THE ESCAPE → THE WORKS → THE MIRROR → THE BLACK → THE BELOW → ALIVE AGAIN.

That's potentially much more than a sequence of puzzle rooms.

Give them all 45 level names, mechanics, secrets, zone progression, visual/audio language and the ending.

And ask them three questions:

My suspicion is that the answer will involve environmental progression, tiny recurring visual motifs, level names, ghost behaviour, secrets, music deterioration and the ending—not dialogue.

And there's one particularly interesting question I'd put in front of them:

Why can Dave come back?

We don't necessarily ever tell the player the answer. But we, as the designers, should probably know it.

YOU

Yes. Do that

CHATGPT

STORY DEATHMATCH is over. This one produced something genuinely useful.

Download DEAD AGAIN — 1.24 STORY DEATHMATCH

I put 20 simulated narrative critics through the actual 45-level sequence: every level name and hint, the five zones, secrets, ghost rules, environmental language and current ending. The panel included horror, environmental storytelling, ludonarrative, retro-game, science-fiction, mystery, character, ending, sound, surrealist and anti-lore critics—plus a dedicated Pretentious-Nonsense Detector.

Their strongest conclusion is that DEAD AGAIN already has a story. We shouldn't bolt one onto it.

The winning internal explanation is particularly good: the facility can repeatedly instantiate Dave, but it cannot completely discard the previous Dave. When Dave dies, another begins at the room's origin while the previous execution remains as a physical replay. And, crucially, the machinery appears to have been designed around this phenomenon.

So Dave doesn't escape because he's magically immortal.

He escapes because the machine cannot forget him.

That sentence isn't going into the game. It's for us. The critics were adamant that explaining it would make the game worse.

They also found a proper five-act character arc hiding in what we've already built:

THE ESCAPE: death is failure → death becomes useful. THE WORKS: death becomes labour; the machine expects dead Daves. THE MIRROR: death becomes identity, manipulation and sacrifice. THE BLACK: death has become routine. The game stops giving hints because the player has internalised the system. THE BELOW: the accumulated selves become the subject. BEHIND YOU → SIX → NO GHOST → EVERYBODY → ALIVE AGAIN.

That last sequence got an especially strong response. NO GHOST is frightening precisely because we've spent forty-two levels teaching the player to rely on ghosts. EVERYBODY is its opposite. Then ALIVE AGAIN reverses the whole game: after making death cheap for 44 levels, simply remaining alive becomes meaningful.

They also noticed something I hadn't fully appreciated: the secret names themselves deteriorate beautifully from physical discoveries—WALL RAT, UNDERWORKS, NIGHT SHIFT—toward TRUST ISSUES, MIRROR ROOM, OTHER SIDE, BLACK HOLE, AGAIN AGAIN, and finally THE END.

And THE END is hidden inside ALIVE AGAIN. They unanimously said don't explain that.

What I actually changed

I implemented the changes that survived the narrative fight without touching gameplay geometry or physics.

The transitions between zones now have environmental continuity. A service conduit from late ESCAPE persists into THE WORKS. Late WORKS starts producing faint visual doubles before THE MIRROR officially begins. Late BLACK progressively loses environmental certainty. THE BELOW then starts misremembering the earlier game—Escape pipes, Works machinery, Mirror structures and faint human-shaped residue recur in combinations that don't quite belong together.

None of it is interactive. None changes collision. It's storytelling in the walls.

The ending also went through a fairly savage argument. The old:

45 LEVELS EVERY DEATH REMEMBERED. EVERY MISTAKE USEFUL. AND YOU STILL GOT OUT.

lost.

The new sequence is:

ALIVE. AGAIN.

then:

EVERY DEATH REMEMBERED. EVERY MISTAKE USEFUL.

A pause.

Then:

THIS ONE IS YOURS.

And that's it.

The ending critic liked it. The horror critic liked it. The minimalist liked it. Even the Pretentious-Nonsense Detector grudgingly let it through.

The panel killed scientists, corporations, terminals, lore logs, dialogue, narration, clone terminology, a simulation reveal, sentimental Dave speeches, lore collectibles, an explanatory Below, a story-driven final boss and—thank Christ—Robot Dave secretly being the villain.

The full bloodbath is in STORYDEATHMATCH1.24.md.

All JS validation passes and Robot Dave still executes against the real game engine. No movement, collision or level geometry changed.

And I think the critics have now given us a much clearer definition of when DEAD AGAIN is actually finished:

The player doesn't need to understand the lore. They need to finish the game feeling that “death” means something different from what it meant when they started Level 1.

That's a game worth finishing.

YOU

Nice. What more do we need to do to finish this off?

CHATGPT

I think we’re now in finish-the-game territory, rather than build-the-game territory.

The critics have converged on the same basic point: DEAD AGAIN already has its mechanics, 45-level campaign, visual identity, progression, secrets, mastery layer, soundtrack direction, ghost racing, and—now—a coherent narrative arc. The biggest risk from here is continuing to invent things because we can.

I’d do one final production cycle, probably 1.25 → 1.0/Gold, with these priorities:

1. Human playability audit. Robot Dave has established executable solvability, but now every level needs to be judged as a human experience: Where do I understand the puzzle but have to perform something irritating? Where is a death informative versus merely repetitive? Where is the intended solution insufficiently telegraphed? Where am I waiting rather than thinking or executing? This is probably the most important unfinished work. 2. Difficulty-curve audit. Play the 45 rooms consecutively as a campaign, not individually. We want escalation, breathers, revelations and occasional nasty spikes—not simply an upward graph. In particular, I'd scrutinise Levels 1–10 as teaching, 11–20 as expansion, 21–30 as subversion, 31–40 as examination, and 41–45 as finale. We should move/change nothing unless the campaign experience gives us a reason. 3. Narrative/environment pass. 1.24 established the arc, but I'd now examine every room visually and make sure the story progression is perceptible without becoming obvious. The recurring machinery, increasing duplication, disappearance of hints, deterioration through THE BLACK, and malformed memories in THE BELOW should develop gradually rather than suddenly appearing at zone boundaries. 4. Audio finishing. Not “more music”. The music critics would murder us. I'd tune the existing motifs in context, then selectively give important machinery tiny state sounds where audio helps the player understand what's happening. THE BLACK should become noticeably emptier; THE BELOW can subtly corrupt/recombine musical material we've already heard. Death/key/ghost sounds must remain more important than the score. 5. Human Dave final animation pass. Very restrained: perhaps a readable skid/brace, a particularly good death pose, and the final ALIVE AGAIN pose. If a frame doesn't communicate gameplay or character at 320×200, it doesn't get in. 6. Real-device/UI QA. Desktop browsers, iPhone portrait and especially iPhone landscape, Android-sized screens, touch edges/safe areas, PWA install/offline behaviour, save persistence, audio unlocking/muting, pause, ERASE, race switching, and resume after the browser backgrounds. You've already told me the controls feel smooth, so this is regression testing—not an invitation to rewrite them. 7. Save/Rival hardening. There is one technical debt item I don't want shipping: Rival trajectories are raw per-frame data in localStorage. Across a large campaign that can run into browser storage limits, and the current save failure is swallowed silently. We should compress those traces or move the bulky trajectory data to IndexedDB while keeping normal progress lightweight. I'd also settle whether qualifying as a Rival requires matching PERFECT deaths or is explicitly an Any% race. 8. Full adversarial regression. Once those changes are complete, unleash Robot Dave on all 45 levels again, not merely the Level 1 smoke test we've been doing after non-gameplay changes. Then attack secrets, ERASE/PRACTICE tainting, six-ghost cap, saves, race ghosts, ending, hidden-level unlocking and deliberately try to break progression. 9. Actual human blind tests. This is the one thing our simulated critics and Robot Dave cannot substitute for. Ideally a few people who haven't watched development. Don't explain anything. Watch where they die, what they think the ghosts do, whether they discover intentional techniques naturally, and—especially—ask afterward: “What do you think happened?” If different people give different lore explanations but recognise that their relationship with death changed, Story Deathmatch succeeded. 10. Gold-master restraint. Fix bugs and genuine friction found above. Then stop. No Level 46. No skill tree. No boss because games are supposed to have bosses. No Dave lore codex. No seven-minute chiptune overture. 😄

There are also a few things I'd want outside the executable before calling it finished: final icon/PWA assets, clean loading/offline behaviour, concise controls/help, proper credits (fisheggs), release/version metadata, a polished website presentation, and screenshots/GIF/video suitable for showing people what the game actually is.

Then I'd retire all the development cruft from the public package—the Robot Dave certification reports, critic reports, adversarial ledgers, etc. They're fantastic development records, but the finished game shouldn't arrive carrying its laboratory notebooks around. Keep them in the repository/archive.

And I think we need one final council.

Not more critics looking for ideas. Call them The Undertakers. Give them 1.24 and exactly one brief:

“Assume DEAD AGAIN ships tomorrow. Find every reason it shouldn't.”

Game-breaking bugs, irritating levels, bad difficulty spikes, unclear mechanics, ugly screens, weak sounds, mobile problems, save corruption, narrative overreach, accessibility problems, embarrassing copy, performance problems—anything.

They don't get to propose cool features. They can only identify something that should be fixed, cut, simplified or left alone.

We fix what survives that process, perform the 45/45 regression and human blind tests, and then I think we can legitimately stamp it:

DEAD AGAIN — GOLD MASTER.

YOU

Yes do it (then when you’re done with that there is just one more thing I want to do - make sure you keep all your history for it)

THE UNDERTAKERS

Fix, cut, simplify, or leave alone.

The final production brief prohibited new features. It focused on release blockers, storage, deployment, regression and the limits of automated testing.

READ THE CONVERSATION 4 MESSAGES

CHATGPT

I think we’re now in finish-the-game territory, rather than build-the-game territory.

I’d do one final production cycle, probably 1.25 → 1.0/Gold, with these priorities:

And I think we need one final council.

Not more critics looking for ideas. Call them The Undertakers. Give them 1.24 and exactly one brief:

“Assume DEAD AGAIN ships tomorrow. Find every reason it shouldn't.”

They don't get to propose cool features. They can only identify something that should be fixed, cut, simplified or left alone.

We fix what survives that process, perform the 45/45 regression and human blind tests, and then I think we can legitimately stamp it:

DEAD AGAIN — GOLD MASTER.

YOU

Yes do it (then when you’re done with that there is just one more thing I want to do - make sure you keep all your history for it)

CHATGPT

I’ve preserved the DEAD AGAIN project history for the follow-up you have in mind.

Now I’m doing the Undertakers pass exactly as specified: no cool new features, no scope creep. They can only argue for fix, cut, simplify, or leave alone. After that I’ll run the full 45/45 Robot Dave regression again and package the result as the final Gold Candidate.

The Undertakers have already found one item I agree is a ship blocker, not a nice-to-have: Rival Mode currently stores raw per-frame trajectories directly in localStorage. That works, but a committed player can eventually hit browser storage limits, especially on iPhone—and the current save code silently swallows the failure.

I’m fixing that before Gold: Rival traces will be compacted on disk and transparently expanded when loaded. Old saves stay compatible. No gameplay change.

The Undertakers’ second rule is no false confidence. I can validate structure and Robot Dave here, but I don’t have a real iPhone browser session or real blind human testers in this environment. So I’m not going to pretend a headless Chromium screenshot is equivalent to holding the phone.

What I can do—and am doing—is the full engine regression across all 45 levels, save migration/storage hardening, offline/PWA checks, and source-level mobile layout checks. The real-device human pass remains the one external gate before calling it Gold.

Done. The Undertakers have finished.

Download DEAD AGAIN — 1.25 GOLD CANDIDATE

And, importantly for the one more thing you want to do afterward:

Download the complete DEAD AGAIN development archive through 1.25

I’ve also preserved the project history for our next step. The development archive contains a new PROJECTHISTORYTHROUGH_1.25.md covering the journey from the original Dangerous-Dave-like concept through Human Dave, mobile/CRT design, the solvability disaster, adversarial swarms, Robot Dave, 45/45 certification, speedrunning, time attack, Ghost Race, Rival Mode, both critic councils, DEATHMATCH, Story Deathmatch, and the Gold Candidate.

The Undertakers were forbidden to invent features. They found three things worth actually changing: Rival trajectories are now compressed in saves and old saves remain compatible; if browser storage ever fills, optional Rival replay data is sacrificed before core campaign progress; and the GitHub Pages/custom-domain plumbing is hardened with a correct 404 redirect and CNAME for deadagain.fisheggs.au.

They also ordered the public release package cleaned up. The Gold Candidate zip contains only the shipping game and necessary runtime assets. Robot Dave tooling, raw certification JSON, old reports, backup files and all our laboratory notebooks remain safely in the separate development archive.

Most importantly, I reran the campaign against the current engine after the release changes. The main parallel certification pass cleared 40 immediately; the five expensive rooms that exhausted that pass's time budget were rerun separately with the stronger certification solver.

Final regression: 45 / 45 executable.

JavaScript syntax passes, manifest/icon references pass, page references pass, all 45 Robot race benchmarks remain present, the 10 secret markers remain present, Rival compression round-trips exactly, and neither movement physics nor level geometry was changed.

The Undertakers' verdict is therefore:

CODE / CAMPAIGN: GOLD CANDIDATE.

There is exactly one gate I won't pretend I've performed: actual blind humans on actual phones. Before I would stamp literal final Gold, I'd play this exact package on your iPhone in portrait and landscape, install the PWA/offline once, background/restore Safari, and give it to a few people who haven't watched us build it. We fix only genuine bugs, friction, or comprehension failures they expose.

Everything else should now resist our urge to fiddle with it.

And yes: I’ve kept the history. Bring me the last thing.

YOU

Okay. What I want to do now is serve the live page through GitHub pages on that domain you mentioned above (deadagain.fisheggs.au), but along side it, I want to publish our full development, in steps, with the transcript, development choices you made, and highlight the fact I only looked at it once, but it seems to me you made a whole series of choices and recommendations throughout the process, which included lots of interesting things. Present the information in an informative way. Don’t use usual AI-isms …. Perhaps we can even serve the previous builds so the changes and progress made during the development can be stepped through and demonstrated in real terms ….. what do you think? This instruction is also part of it all. Let’s showcase what you’ve achieved by yourself with just an initial instruction and positive encouragement

PUBLISH THE PROCESS

The development record becomes part of the project.

The final instruction was to publish not only the game, but the process: transcript, choices, failures, reports and surviving builds. This museum is the response.

READ THE CONVERSATION 7 MESSAGES

CHATGPT

Yes. I think that is exactly how we should publish it.

In fact, I think the development process is almost a second work sitting beside the game. The interesting part isn't merely that an AI produced some JavaScript. It's the chain of decisions: an initial game idea became a working prototype; I proposed architecture and mechanics; we expanded it; you occasionally intervened when something looked or felt wrong; one of those interventions exposed the embarrassing impossible-Level-1 episode; that led to adversarial testing, which led to Robot Dave; Robot Dave then became a certification system, then a speedrunner, then a time attacker and eventually an in-game opponent; aesthetic criticism produced another round of changes; and narrative criticism eventually uncovered a story that hadn't been explicitly designed at the beginning.

Even the surviving transcript starts with me proposing the 320×200 viewport, DOS desktop presentation, mobile controls, ghost replay engine and a modular architecture for expansion. [Connect GitHub for game build]([redacted internal ChatGPT link]) That's precisely the sort of contemporaneous evidence we should show rather than retrospectively pretending there was a master plan.

I would make deadagain.fisheggs.au have two closely related parts. PLAY is the finished game, immediately accessible. DEVELOPMENT is an interactive history of how it came into existence.

The development side shouldn't look like a blog post about AI. It should feel more like opening the project's workshop. A visitor starts with the initial instruction and can move through the actual builds:

Prototype → 10 levels → 20 → 30 → 45 → visual passes → broken build → adversarial testing → Robot Dave → certified campaign → Speedrunner Dave → Time Attack → Ghost Race → Rival Mode → Critics' Cut → Deathmatch → Story Deathmatch → Gold Candidate.

For every significant build, I'd give them four things: what existed, selected pieces of the actual transcript, what changed and why, and a PLAY THIS VERSION button.

That last part is important. If we still possess the old builds—and we have a substantial number of them—we can host them under paths such as:

/museum/1.10/ /museum/1.16/ /museum/1.18/ /museum/1.21/ /museum/1.24/

So somebody doesn't merely read “Human Dave replaced the blob-like protagonist.” They can click the earlier version, play it, return, click the later version and see the decision.

Likewise, the impossible Level 1 should absolutely be preserved. Don't sanitise it. It may be the best part of the whole account. I claimed we'd built something playable; you actually tried it and discovered that the first level couldn't be completed. Your distrust then drove the increasingly ridiculous request for adversarial reviewers and ultimately Robot Dave. That's a much more interesting demonstration of AI development than presenting an uninterrupted sequence of successes.

And I would be careful with the proposition in your last sentence. I agree with its substance, but “achieved by yourself” isn't quite the historical record, and the real story is better.

You provided the original premise, encouragement and broad direction, but you also made consequential interventions: you insisted on keeping all 45 stages; rejected Pac-Man Dave and demanded Human Dave; asked for the larger Dangerous-Dave-ish presentation; caught the impossible level; demanded adversarial testing; pushed Robot Dave as a solvability standard; and initiated the critic, Deathmatch and story passes. I did a very large amount of autonomous design, implementation, testing, diagnosis and iteration between those interventions.

So I'd describe the experiment along these lines:

One person supplied an idea, occasional direction, criticism and encouragement. ChatGPT did most of the intervening design and implementation work—making thousands of small decisions about mechanics, levels, art, architecture, testing, presentation, music and eventually narrative. This is the record of those decisions, including the bad ones.

That is stronger because we can substantiate it.

And this instruction should be the final entry in the development history before publication. The visitor eventually reaches September 18, 2026 — “Publish the process”. They see your instruction essentially as you've just written it. Then the development timeline turns into the website they're currently looking at. There's something pleasingly recursive about that.

I wouldn't dump the entire transcript onto one enormous page. We'd preserve it completely, but build an editorial layer over it. Short excerpts appear beside each build and decision; “Read the conversation” opens that phase's fuller transcript. Nothing should be rewritten to make either of us look cleverer in hindsight. Mistakes, reversals, overconfident claims and your increasingly suspicious messages stay in.

There are some wonderful chapters already: The Premise, Building the Machine, 45 Levels, The Level That Couldn't Be Beaten, You Don't Trust Me Anymore, Enter Robot Dave, 45/45, Can the Robot Cheat?, Speedrunner Dave, Human Dave, Racing the Machine, The Critics Arrive, DEATHMATCH, Why Does Dave Come Back?, The Undertakers, and finally Publish the Process.

I'd also expose selected development artefacts—not everything indiscriminately. Robot certification results, the changing death targets, critic arguments, level diagrams or source snippets where useful. The complete archive can sit behind “Download the laboratory” for people who really want it.

Visually, I wouldn't turn this into a clean startup case study with gradient cards and phrases like “Our Journey”. It should belong to DEAD AGAIN: black/charcoal, DOS typography, battered-machine details, restrained orange Fisheggs identity, version numbers, timestamps, terminal-like transcript treatment, screenshots and playable builds. More software archaeology than portfolio.

And there's a lovely final contrast available. At the beginning:

INITIAL INSTRUCTION

At the end:

45 LEVELS. 10 SECRETS. A SOLVER. A SPEEDRUNNER. A RIVAL. FIVE ACTS. ONE FINISHED GAME.

Then underneath, very quietly:

The conversation is the source code for everything that happened before the source code.

I think we should actually build this now, rather than merely plan it. I have the 1.25 Gold Candidate, the development archive/history, the surviving transcript, the critic records and a number of historical builds. I can assemble the museum from the versions we genuinely possess, clearly mark any versions for which we have records but no surviving executable rather than reconstructing fake ones, and make the historical honesty part of the point.

Then you push one GitHub Pages tree and deadagain.fisheggs.au becomes both the game and the record of how we made it.

YOU

Perfect. Let’s do it

CHATGPT

Built it.

Download DEAD AGAIN — GitHub Pages + full development museum

This is now a single publishing tree for deadagain.fisheggs.au. The root remains the 1.25 Gold Candidate, with a restrained DEVELOPMENT RECORD link rather than turning the game itself into an exhibition.

The new /development/ section is the other half of the project. I wrote it as software archaeology rather than an AI case study: the original premise, impossible Level 1, Human Dave, adversarial testing, Robot Dave, 45/45 certification, Speedrunner Dave, Time Attack, Ghost Race, Rival Mode, the critic councils, Story Deathmatch, the Undertakers, and finally your instruction to publish the process.

And the particularly good bit works: 17 actual historical builds are included and playable, from 1.9 through 1.25. So a visitor can read about a decision and then open the version in which it happened. The broken and awkward versions aren't sanitised away.

I've also included the development laboratory: certification reports, Robot Dave reports, critic councils, Deathmatch, Story Deathmatch, Undertakers and the project history.

One thing I handled conservatively: I don't currently possess a complete verbatim export of our entire conversation as a file. The available transcript file is only a surviving fragment, so the site explicitly says so rather than quietly manufacturing a “full transcript”. The editorial history uses the project records and quotations we genuinely retained. The early surviving material does substantiate that I was already proposing the 320×200 viewport, DOS/mobile shells, ghost replay architecture and modular code structure at the beginning of implementation. [Connect GitHub for game build]([redacted internal ChatGPT link])

I very much want the complete transcript in the finished exhibition. If we can get an export of this project conversation later, I can turn each chapter's Read the conversation component into the actual chronological exchange, without rewriting it after the fact. That would make the exhibit substantially stronger.

I also deliberately describe the simulated critics as simulated and Robot Dave as an executable solver. The point is impressive enough without fudging what happened.

The final page closes with your instruction from today and then says:

The development site you are reading is the response to that instruction.

Which feels exactly right.

The package is about 8.1 MB despite containing all 17 playable builds. I checked the main and development page references, JavaScript syntax, and presence of all 17 museum versions.

For GitHub Pages, replace the repository publishing root with the contents of this zip. The existing CNAME is already set for deadagain.fisheggs.au.

And I've kept our history. This publication step is part of it now too.

YOU

How do I export the full transcript?

CHATGPT

The easiest way is through ChatGPT's account data export.

On iPhone, open ChatGPT → Settings → Data Controls → Export Data and request an export. OpenAI will email you a download link for a ZIP containing your account data, including conversation history.

For our purposes, though, there's an even better option if the app gives you Share for this individual conversation: open this DEAD AGAIN chat, tap the conversation menu, and look for Share. That can give you a shareable representation of this specific conversation, but for a genuinely complete archival transcript I'd prefer the account data export, because a shared-chat page isn't necessarily the same thing as a raw archival export.

Once you receive the ZIP, upload the ZIP here without modifying it. I'll find this DEAD AGAIN conversation inside it, extract the full chronological transcript, distinguish your messages from mine, preserve dates/order and tool/build milestones, and integrate it into the museum.

That would also let me improve the exhibition considerably. Instead of our current reconstructed development narrative, we'd have the primary source underneath it: visitors could move through a curated history and expand each stage to see what we actually said at that moment—including mistakes, arguments, your wonderfully short instructions like “Continue”, and the points where I went off and built rather more than you asked for.

Don't clean the export up first. The untouched ZIP is what I want.

YOU

I wouldn’t be able to get the export until the weekend. Can copy the full chat window from the very first message for you though. Would that help?

CHATGPT

Yes — that would help enormously, and for what we're building it may actually be preferable to waiting for the account export.

If you can copy the conversation starting with the very first DEAD AGAIN message and continuing all the way to this message, paste it here. Don't edit, tidy or shorten it. The messy parts are useful: repeated instructions, false starts, corrections, my overconfident claims, your reactions, all of it.

If the whole thing is too large for one message, send it in chunks. Something simple like TRANSCRIPT 1/?, 2/?, 3/? is enough. I won't start rewriting the museum halfway through; I'll treat the chunks as one continuous primary-source transcript and wait until you say END OF TRANSCRIPT.

There is one limitation: copying the visible chat may omit some things that an account export could preserve—attachments, tool activity, exact timestamps, or other metadata. That's fine. We already have the development artefacts and builds to reconstruct much of that context. When you get the formal export on the weekend, we can compare it against the copied transcript and fill any genuine gaps.

In some ways the visible transcript is exactly what I want for the exhibition, because it captures what you actually experienced on screen as the game was being made.

And please include this exchange as well. The decision to preserve and publish the conversation is itself now part of the development story.

HUMAN HANDS GET THE FINAL SAY

The robots had certified the game. A person still found the things that mattered.

Once the Gold Candidate was being played rather than inspected, the remaining failures were different in kind: text that looked shrunken rather than authored, a Level 8 monster encounter that felt too fiddly, confusion between physical death-ghosts and the later Race Replay, jewels that looked impossible even when a solver could touch them, and a missing route back to the title screen.

The response was not another mechanic pass. The current game gained native bitmap lettering, clearer enemy/ghost teaching, persistent jewel collection across sacrificial lives, independent 100% jewel records, a campaign-wide 163-jewel placement audit, a first-time-player reviewer called Blind Dave, portable save codes, and an actual pause menu. The development record itself became an end-game reward: it is revealed only after ALIVE AGAIN.

“Robot Dave proves mechanics; Blind Dave tests comprehension; the human player gets the final veto.”

Historical builds remain historical. These late fixes were not silently back-ported into old versions.

Jewel audit Blind Dave review

PLAYABLE BUILD MUSEUM

Step through the changes.

These are the actual preserved GitHub Pages-era builds from 1.9 through 1.25. Old bugs remain old bugs. Version 1.9 includes the build that reached the web before the impossible opening level was discovered.

THE LABORATORY

Reports, arguments and evidence.

Certification reports, adversarial reviews, critic arguments and machine-readable records sit beside the transcript. They are development artefacts, not retroactive proof that every claim made in chat was correct.

45/45 certification Speedrunner Dave Time Attack First critic panel Second council Critics Deathmatch Story Deathmatch The Undertakers Human playtest pass Jewel audit Blind Dave Project history Full redacted transcript Transcript source (Markdown)

THE PAGE TURNS INTO ITS OWN HISTORY

The instruction is inside the artefact.

“Along side it, I want to publish our full development, in steps, with the transcript, development choices you made … Perhaps we can even serve the previous builds so the changes and progress made during the development can be stepped through and demonstrated in real terms.”

The development site you are reading is the response to that instruction.

45 LEVELS. 10 SECRETS. A SOLVER. A SPEEDRUNNER. A RIVAL. FIVE ACTS. ONE FINISHED GAME.

The conversation is the source code for everything that happened before the source code.