Deadfall started as a JavaScript game pretending to be a 1990s console game.
Three days later, it was running as a SNES ROM.
That still sounds a little absurd to me, even after doing it. The original version of Deadfall was built with Phaser, a JavaScript game framework. It ran in the browser on modern hardware. The new version runs as a Super Nintendo game, built in C with PVSnesLib, with native SNES graphics and music.
I never expected it to pan out this well. I started it as a “let’s see what happens” experiment because Claude Code has been getting better and better at complex engineering tasks. Lately it has been doing things for me that would have sounded completely ridiculous not that long ago. So I gave it a ridiculous challenge.
Could it help me port one of my JavaScript games to the Super Nintendo?
Turns out, yes.
And the wild part is that the SNES version is now better than the original in several ways.
What Deadfall is
Deadfall is a cute retro-style arcade game where you play as Flux, a little pink character who mines gems and rocks while trying to survive Gloop and Clanky the robot.
The objective is simple: mine all the gems in a level. Once all gems are cleared, a portal opens and Flux can escape to the next level.
The game has a physics component where gems, rocks, and indestructible objects fall down when space is freed below them. That means you can use the level itself as a weapon. Drop something on Gloop and you can kill it. Clanky is different. Clanky is invincible, dangerous, and can zap Flux with lightning. With the right timing, you can trick Clanky into zapping Gloop too.
Deadfall is loosely inspired by Boulder Dash, but I did not want to make a clone. I researched similar games because I wanted the mechanic to have its own identity. The nostalgia was intentional, but the game itself had to be original.
That mattered to me from the beginning. I love old games, but I do not think the world needs more clones of things that already exist. The exciting part is making something new that feels like it could have existed back then.
The browser game already lived inside a console-shaped box
The original Phaser version of Deadfall was designed to look like a real console game from the early 1990s.
I used the exact 256×224 pixel resolution of the Super Nintendo. The sprites are 16×16 pixels. Everything is hard pixels. No modern effects. Limited colors. The game was already built with the kind of discipline you need when trying to make something feel authentic.
That is probably why it ended up being such a good candidate for a real SNES port.
A lot of “retro-inspired” games are retro in mood only. They use modern resolutions, huge backgrounds, alpha effects, high-resolution assets, MP3 music, unlimited memory, modern input assumptions, and then apply a pixel art style on top.
Deadfall was different. It was already pretending to live inside old hardware limits. The SNES port forced it to stop pretending.
The ridiculous part
The original Deadfall ran in JavaScript on a modern multi-core, multi-GHz computer.
The Super Nintendo runs on a CPU around 4 MHz. It has 128 KB of RAM and 64 KB of VRAM. The graphics need to fit tile and palette budgets. The audio cannot just play MP3 files. The whole thing has to be compiled into something the machine can actually run.
That is a pretty big leap.
I did not start this because I already knew exactly how to make SNES games. C and SNES homebrew were not my usual stack. Claude Code figured out the technical path and landed on PVSnesLib. From there, the port became a tight loop of building, testing, adjusting, converting assets, testing again, and polishing.
The first version was extremely crude.
It showed the game elements on a black background: rocks, indestructible objects, Flux, Gloop, Clanky. No HUD. No background graphics. No proper sprite animations. No section transitions. Everything moved 16 pixels at a time and looked rough.
But it ran.
That was the important part. Level 1 existed. The basic game logic worked. It was ugly, but alive.
That was enough to keep going.
Then the SNES started saying no
The first big wall was graphics.
The original Deadfall backgrounds were way too big for the SNES version. In the Phaser game, I could use a large background that spanned all sections of a level. The SNES version needed something much more careful.
So I went back to the design table and created 256×256 seamless tile backgrounds using Midjourney as source material. Then I manually resized, edited, cleaned up, and reduced the colors in Photoshop.
A SNES can show a limited number of colors on screen at once, and sprites need palette budget too. I reduced the backgrounds to roughly 24 colors to leave room for everything else.
That color reduction changed the look in a good way. The backgrounds became more constrained, more graphic, and honestly more authentic.
The same thing happened across the rest of the art. Gems, sparkles, rocks, indestructible objects, sprite animations. There was a lot of back and forth. Convert, test, look at it, edit again, convert again, test again.
A gem cannot merely look nice in Photoshop. It has to still read as a gem after being crushed through tile conversion and palette limits. A sparkle has to work with very few colors. A rock has to be readable at 16×16. A sprite animation has to communicate personality with almost nothing.
That kind of detail is where a project either starts to feel like a real game or starts to feel cheap.
The music problem
The original Deadfall used MP3 files created with Suno to sound like chiptune music.
That worked fine for the browser version. It sounded retro enough.
The SNES version had no use for those files. A Super Nintendo cannot play MP3 music like that. It uses the SPC700 audio chip, and for this project I needed music that could work within a much tighter channel structure: 6 channels for music, with 2 more reserved for sound effects.
I tried finding suitable free-to-use SNES-compatible music online and mostly hit a wall. Then I tried something that I honestly did not expect to work.
I asked Claude to create original looping MIDI tracks that would stay within the channel limits and convert cleanly to SNES music.
ChatGPT failed pretty badly at this. Claude, to my surprise, did an amazing job. It generated nice-sounding looping MIDI tracks and even built a little HTML player on the fly so I could listen to them.
Those MIDI files converted beautifully into a format the SPC700 could actually play.
That changed the whole feel of the game.
The original music sounded like chiptune. The SNES version has actual native SNES music. That is a completely different level of authenticity.
The workflow
The workflow became very tight:
Original Phaser game as reference. Claude Code working on the C/PVSnesLib implementation. Build the ROM. Test in SNES emulators. Notice what felt wrong. Direct Claude more tightly. Edit assets in Photoshop. Convert again. Test again. Repeat.
Claude Code handled the code side shockingly well. I did not have to review every line of C, and realistically I would not have been the best person to do that anyway. C and SNES homebrew are not my day-to-day stack.
But I was directing the work very closely.
That part matters.
AI-assisted engineering still needs engineering judgment. You need to know what is wrong, what to ask for, what is plausible, what matters, what can be simplified, what should be preserved, and when something technically works but feels bad.
That is where experience shows up. Not always in writing every line yourself, but in steering the system, recognizing problems, and pushing the work toward something polished.
I do not see this project as AI doing my thinking for me. I see it as using AI as a serious engineering tool.
Toolchain
| Layer | What I used |
|---|---|
| Original game | Phaser / JavaScript |
| SNES port | C + PVSnesLib |
| Code assistant | Claude Code |
| Music | Claude-generated 6-channel looping MIDI converted for SPC700 playback |
| Background source art | Midjourney seamless tiles |
| Asset prep | Photoshop, palette reduction, manual cleanup, conversion, more cleanup |
| Testing | Multiple SNES emulators |
| Release | Freeware ROM + open source code |
PVSnesLib: https://github.com/alekmaul/pvsneslib
The SNES version became better
The funny thing is that I expected the SNES version to be a compromised version of the original.
In several ways, the opposite happened.
The biggest improvement came from the background limitation. The JavaScript version used a large background across all sections. Since that was too much for the SNES version, I rebuilt the backgrounds as smaller 256×256 tile images.
At first, when Flux moved from one section to another, the whole tile would slide. It worked, but it felt basic.
Then I had an idea: what if the foreground slides fully, but the background only scrolls a little bit?
That created a beautiful parallax effect. The foreground moves in and out dramatically, while the background shifts only about 25%. It instantly made the section transitions feel more polished and more “console.”
That effect exists because of a limitation. I had to use a much smaller background, and the solution ended up looking better than the original.
The same thing happened with music. The SNES version could not use the MP3 tracks, so I had to replace them with real native chiptune music. That made the whole game feel more authentic.
I also improved the enemy behavior.
In the JavaScript version, enemies could sometimes move out of the section the player was in and then come back. It worked, but it could feel a little dumb. In the SNES version, enemies keep hunting within their own section and only transition when the player is in a different section. The behavior feels much more intentional.
Several tiny details improved too.
Enemies now come in and out of the frame pixel by pixel instead of popping in. Falling objects have tuned timing so they do not feel too instant or too sluggish. Pushed blocks have their own threshold so the interaction feels physical instead of twitchy. I also added a triangular blinds fade-in/fade-out effect inspired by that classic Super Nintendo era presentation style. The original version did not have that.
The one I obsessed over most is the iris transition from Super Mario All-Stars, where the screen closes and reopens through a shrinking and expanding circle. I spent hours fighting the timing and the masking to get it working within the SNES hardware constraints. When it finally clicked, it was incredibly satisfying to watch. It is a tiny detail, but it is exactly the kind of touch that instantly tells you this is a real console game.
Those details matter.
Most players may not consciously notice every one of them, but they feel the difference. The timing, smoothness, transitions, and presentation all add up.
That is also where I think a lot of AI-assisted projects go wrong. People stop when something technically works. I keep going until it feels right.
The game itself
The finished SNES version has 10 levels.
Levels are made out of connected sections on a wrapping grid. Early levels start at 2×2 sections. Later levels grow through 2×3, 3×3, 3×4, and eventually 4×4. So by the end, you are managing up to 16 connected sections.
The wrapping grid makes the game more dynamic than hard boundaries. If you go left from the far-left section, you end up on the far-right section of the same row. Same for top and bottom. That creates more interesting movement, evasion, and enemy behavior.
Flux has 3 lives. Some levels contain hidden extra lives. When those are gone, the player gets 3 continues before starting over. When Flux dies, the level state does not reset. Gems stay mined. Rocks stay where they fell. Enemies keep their state. Flux simply respawns at the dedicated player spawn tile.
Killed enemies respawn at their own spawn tile after a delay. The delay gets shorter in later levels, which adds to the difficulty curve.
Scoring rewards mined gems, killing Gloop, and tricking Clanky into zapping Gloop. There is also a time bonus that starts at 5000 and counts down toward 0. Finish the level in a decent time and you get the full bonus. Take too long and it disappears.
The controls are simple: D-pad to move, A to crush or mine, and blocks move by pushing into them.
The presentation is complete too. Title screen, attract mode, credits, and ending.
The attract mode introduces the characters almost like a tiny silent cartoon. The title fades out. Flux walks in, pushes a block onto a gem, crushes it, idle-blinks, walks off, and his name appears. Gloop walks across. Clanky walks in, zaps with lightning and sound, then walks off. Then it fades to a credits image and loops back to the title.
There is no big story. Deadfall does not need one. It is an arcade game. Here is Flux. Here are the gems. Here are Gloop and Clanky. Survive.
Childhood dream unlocked
This whole thing hit me harder than I expected.
As a kid, I wanted to make games for real consoles. That felt completely out of reach. Console games were made by studios, with dev kits, specialized knowledge, and people who knew things I did not know how to even begin learning.
Now I have an original game running as a Super Nintendo ROM.
That feels magical.
I know it is a technical project. I know it is a ROM. I know it was built with modern tools and AI assistance. But emotionally, it feels like Deadfall escaped the browser and became real.
That is the part I keep coming back to.
What I learned
The SNES constraints made the game better in ways I did not expect. Smaller backgrounds led to better transitions. The audio limitations led to real native chiptune music. Revisiting the game logic led to smarter enemies.
Old hardware forces decisions. You cannot hide behind infinite memory, modern audio, high-resolution assets, or brute force. Everything has to earn its place.
AI changed what was possible here, but it did not remove the need for craft. The game still needed an original concept, characters, mechanics, art direction, engineering judgment, testing, iteration, and polish.
I think we may be heading into a really fun era for retro homebrew. People have been playing these old consoles for decades. Now more people can actually create for them too.
That is the exciting part to me. Not more clones. New games. Weird games. Personal games. Games that feel like they could have existed back then, but did not.
Release
Deadfall SNES will be released as a free ROM, along with the source code.
The goal is simple: put it out there as a complete, playable, open example of what is possible now.
I may eventually embed it directly on the website through a JavaScript SNES emulator so people can play it in the browser. For now, the plan is to make the ROM available for download and publish the source on GitHub.
Three days ago, this was a JavaScript game pretending to be a console game.
Now it is a Super Nintendo game.
That is still wild to me.
Play it right here
And since you made it this far, here it is. Deadfall running as a real Super Nintendo ROM, playable right in your browser.
Click the screen, then press Enter to start. Arrow keys move Flux, Space mines and crushes. This is the actual SNES ROM running in your browser via EmulatorJS, so give it a moment to load.
