Post

Two nights ago, I decided to give Claude Code an actual challenge. I dropped a decrypted copy of Bloodborne 1.09 for PS4 into a directory, started 5 agents and told it to decompile it an recompile as a wasm playable game in the browser. I woke up to this:

I told the agents to take screenshots and keep a blog of the progress. It's been two days. I'll keep this thread with the blog highlights.

On the first 6h we got to the main menu, the character creation, and the game would crash on map loading. After another chunk of work, we got to this:

The agents were able to navigate the map (they built a little navmesh helper that allowed them to play the game (you could hear the sounds and get to the in game menus or prompts), but the 3D render was, well grey.,

After 36h, this is the current status: All the rendering artifacts it found are gone, the game still runs at 7-10 FPS (the actual PS4 game caps at 30 FPS). The replay mechanism auto-plays the game quite a bit and doesn't crash.

Morning updates. As part of being able to debug the game, Claude is having to actually play the game. I wonder if we're going to end up with a full game replay. Here is Claude on a boss fight, running in Chrome, full speed.

On PS4 the game is hard capped at 30 FPS. I've suggested Claude that he could try to get rid of that limitation. I guess it can. Hunter's Dream is already running at ~35 FPS.

Claude decided that is faster to cheat and set the boss' lifeto zero than trying to fight it. I guess porting Bloodborne is still easier than playing Bloodborne.

0 reposts3 likes

Claude patched the game to cap at 60fps. And now the game runs at minimum 40fps. I've had to help with some creative solutions, since we found a bug in how Chrome decides to do GC with shard arrays, which was triggering 1000s of GCs. The game now runs all to way to the end.

The game fully plays end to end. Going through the DLCs now. Also, it was able to remove the "play online" options from the menu.

The SharedArrayBuffer GC thing is the buried lede here. A human porting this would profile the hot path, pool buffers, and never generate enough churn to trip 1000s of GCs. Five agents throwing decompiled code at a runtime hit edge cases that careful manual work routes around by accident.

same pattern on buffer-heavy work. agents writing byte-shuffling code tend to concat/reallocate instead of pooling, so you get GC churn that never shows up until you throw real volume at it. a human doing it by hand defaults to the pool almost by instinct.

The GC thing seems like a clear bug to me (the criteria to trigger a GC on Chrome accounts for the SharedArrayBuffer that was grown in the isolate). GC triggering is a very common hot path suspicion. And Claude detected but gave up on solving it. I had to suggest a couple hacky ways to go around it.