Claude portó un juego JavaScript a SNES en solo 3 días

¿Qué pasaría si pudieras convertir un juego JavaScript en una ROM funcional de Super Nintendo en solo tres días, sin ser experto en C ni en hardware retro? Eso es exactamente lo que acaba de demostrar Marco van Hylckama Vlieg usando Claude Code, la herramienta de programación asistida por IA de Anthropic. Y el resultado tiene implicaciones enormes para toda la comunidad homebrew y romhacking.

Deadfall: de navegador a cartucho SNES

Deadfall nació como un juego de navegador construido en Phaser, el popular framework de JavaScript para videojuegos 2D. Su estética ya era intencionalmente retro: resolución exacta de 256×224 píxeles, sprites de 16×16, píxeles duros y paleta de colores limitada. Marco lo diseñó así desde el principio, queriendo que pareciera un juego perdido de los años 90. Esa disciplina visual resultaría ser clave para lo que vendría.

El juego en sí es un arcade de acción y puzzles donde el jugador controla a Flux, un personaje que extrae gemas mientras esquiva a dos enemigos: Gloop y Clanky el robot. La mecánica principal gira en torno a la física de objetos: rocas y gemas caen cuando se libera el espacio bajo ellas, y eso puede usarse como arma. Inspirado vagamente en Boulder Dash, pero con identidad propia.

El salto técnico era enorme. El juego original corría en hardware moderno de varios GHz. La Super Nintendo tiene una CPU de unos 4 MHz, 128 KB de RAM y 64 KB de VRAM. Sin embargo, en tres días de trabajo intensivo con Claude Code y la librería PVSnesLib, Deadfall se convirtió en una ROM de SNES funcional, completa y pulida.

Cómo trabajó Claude Code en el port

Marco no partía con experiencia en C ni en homebrew de SNES. Fue Claude Code quien planteó la ruta técnica, eligió PVSnesLib como base y comenzó a traducir la lógica del juego en JavaScript a código C compatible con el hardware de Nintendo. El flujo de trabajo fue un ciclo muy ajustado: compilar la ROM, probarla en emuladores SNES, identificar problemas, redirigir a Claude con más precisión, ajustar assets en Photoshop, volver a compilar.

Lo que queda claro en el relato es que la IA no eliminó la necesidad de criterio técnico y creativo. Marco dirigía el trabajo de cerca: sabía qué estaba mal, qué pedir, qué simplificar y cuándo algo funcionaba técnicamente pero no se sentía bien. Ese juicio editorial y de diseño siguió siendo humano. Claude manejó la carga de ingeniería en C; Marco manejó la dirección del proyecto.

El problema del audio: Claude generó música MIDI nativa para el SPC700

Uno de los retos más inesperados fue el sonido. El juego original usaba archivos MP3 creados con Suno que sonaban a chiptune. La Super Nintendo no puede reproducir MP3: usa el chip de audio SPC700, con una estructura de 6 canales para música y 2 reservados para efectos.

Marco buscó música libre compatible con SNES sin éxito. Entonces le pidió a Claude que generara pistas MIDI originales en bucle respetando el límite de canales. El resultado le sorprendió: Claude no solo generó las pistas sino que construyó un pequeño reproductor HTML para poder escucharlas antes de convertirlas. Esas pistas MIDI convirtieron perfectamente al formato SPC700, dando al juego música nativa de SNES real, algo cualitativamente distinto a simular chiptune con MP3.

Las limitaciones del hardware mejoraron el juego

Algo paradójico ocurrió durante el proceso: varias de las restricciones del hardware SNES mejoraron el juego respecto al original. Los fondos de la versión JavaScript eran demasiado grandes para la SNES, así que hubo que reconstruirlos como tiles de 256×256. Eso llevó a implementar un efecto parallax en las transiciones de sección: el plano frontal se desplaza al 100% mientras el fondo solo avanza un 25%. El resultado visual es más cinematográfico que el original.

Lo mismo pasó con el comportamiento de los enemigos, que en la versión SNES es más inteligente y coherente, y con detalles de presentación como transiciones de fundido en forma de persianas triangulares o el célebre efecto iris de Super Mario All-Stars, que Marco reprodujo luchando horas contra las restricciones de timing y masking del hardware. Son detalles que el jugador quizá no nota conscientemente, pero que hacen que todo se sienta como un juego de consola real.

Qué significa esto para el homebrew y el romhacking

Esta es la parte que más debería interesar a nuestra comunidad. El homebrew de SNES ha sido históricamente territorio de programadores con años de experiencia en ensamblador o C de bajo nivel, conocimiento profundo de la arquitectura del hardware y mucho tiempo libre. PVSnesLib ya democratizó bastante ese acceso, pero seguía siendo una barrera considerable.

Lo que demuestra el caso Deadfall es que una IA como Claude puede actuar como copiloto técnico experto para proyectos homebrew: conoce las limitaciones de hardware, elige las librerías adecuadas, traduce lógica de alto nivel a C optimizado para la plataforma y resuelve problemas específicos de arquitectura retro. No reemplaza al creador, pero amplía drásticamente quién puede crear.

Para el romhacking, las implicaciones son similares. Tareas que requieren conocer offsets de memoria, formatos de gráficos propietarios o estructuras de datos de ROMs específicas son exactamente el tipo de conocimiento técnico acotado en el que los LLMs como Claude rinden especialmente bien. Ya hemos visto esto en proyectos recientes como el DoomGeo-AES para Neo Geo o el Doom Fix Patch v0.3 para Sega Saturn: la IA como herramienta de investigación y traducción técnica en proyectos de la escena.

La toolchain completa del proyecto

Para quien quiera replicar o aprender del proceso, esta fue la pila tecnológica utilizada:

• Juego original: Phaser / JavaScript
• Port SNES: C + PVSnesLib
• Asistente de código: Claude Code (Anthropic)
• Música: MIDI de 6 canales generado por Claude, convertido para el SPC700
• Arte de fondos: tiles generados con Midjourney, reducción manual de paleta
• Preparación de assets: Photoshop + conversión manual
• Testing: múltiples emuladores SNES
• Release: ROM freeware + código fuente abierto en GitHub

El código fuente será publicado en GitHub como referencia abierta. El objetivo declarado del autor es dejar un ejemplo completo y jugable de lo que es posible hoy. Eso lo convierte en un recurso valioso para cualquier homebrew developer que quiera explorar este flujo de trabajo.

Una nueva era para los juegos retro originales

Marco cierra su relato con una reflexión que resuena: de niño quería hacer juegos para consolas reales, pero eso estaba fuera de alcance. Ahora tiene un juego original funcionando como ROM de Super Nintendo. No es un clon. No es una demo técnica. Son 10 niveles completos, con pantalla de título, modo atraer, créditos y ending, construidos en tres días con ayuda de IA.

La escena homebrew lleva décadas manteniendo vivo el hardware retro como plataforma creativa. Si herramientas como Claude Code reducen la barrera técnica de entrada, lo que viene no son más clones sino juegos nuevos, raros y personales que podrían haber existido en los 90 pero no existieron. Eso es exactamente lo más emocionante.