F-Zero X llega al 3DS: 147 agentes de IA y 60 fps

Un port de F-Zero X al 3DS hecho con 147 subagentes de IA

El port de F-Zero X al Nintendo 3DS pasó de una pantalla negra a correr a 60 fps en estéreo en apenas 24 días, con una sola persona dirigiendo el proyecto y 147 subagentes de IA construyendo la primera fase. Para cualquier founder que esté armando un flujo de trabajo con agentes, el post-mortem de G-Diffuser (así se llama el proyecto, basado en la decompilación de F-Zero X) es un caso de estudio sobre cómo repartir trabajo entre agentes sin perder el control del resultado.

El proyecto se publicó en dos fases: la primera, del 11 de agosto al 3 de septiembre, llevó el juego a un New 3DS a 60 fps con 3D estereoscópico. La segunda, no planificada originalmente, corrió del 7 de septiembre al 19 de octubre y agregó soporte para el Old 3DS, un renderizador nativo y el Expansion Kit de 64DD.

¿Qué se construyó exactamente?

Tres builds de consola salen de un mismo árbol de código, todas arrancando desde el menú HOME (.cia) o el homebrew launcher (.3dsx): la versión base para Old 3DS / 2DS, la de New 3DS / New 2DS XL, y una build de New 3DS con el Expansion Kit de 64DD (editor de circuitos y creador de máquinas, jugable con una imagen de disco que aporta el usuario).

Ninguna build incluye una ROM ni una imagen de disco: el juego lee archivos de assets pregenerados desde la tarjeta SD. El port cubre Grand Prix, Time Trial, Practice, Death Race y las pantallas del editor de máquinas, con música y efectos sobre el DSP real, 3D estereoscópico en el slider y un dashboard en la pantalla inferior con tres layouts de HUD.

La arquitectura se apoya en tres piezas: la decompilación de F-Zero X (inspectredc/fzerox), el runtime de N64 libultraship (Kenix3), que necesitó un parche de 13 líneas en newlib para compilar en devkitARM, y una capa propia port/3ds que ya sumaba 15.039 líneas al cierre de la primera fase.

¿Cómo se orquestó el trabajo con agentes?

La estructura es la parte más replicable. Una sola persona dirigió todo el proyecto, una sesión larga de Claude hizo de orquestadora y 147 subagentes construyeron la primera fase. La segunda sumó muchos más.

El método fue dividir cada fase en frentes paralelos con un objetivo medible. Del 11 al 14 de agosto, por ejemplo, cinco streams de fundación corrieron en paralelo hasta lograr la primera carrera en emulador. Del 27 al 28 de agosto, una flota de cinco agentes cerró el paquete de release. Del 1 al 2 de septiembre, la campaña LOCKED-60 lanzó cuatro palancas en paralelo.

El detalle que más vale la pena copiar: antes del release v1.0.0, una revisión adversarial permanente auditó el resultado ya integrado. El post-mortem también publica una página de costos con tokens, dólares y subagentes, donde los valores estimados aplican precios de lista publicados de API a conteos exactos de tokens, con el supuesto declarado al lado de cada cifra.

¿Por qué el cuello de botella no era el que parecía?

La segunda fase arrancó con una meta que el propio equipo había descartado: hacer correr el juego en el Old 3DS, un hardware de 268 MHz con una región de app de 64 MB. Para entrar ahí, los agentes redujeron a la mitad la arena de RDRAM, pasaron el audio a streaming en lugar de residente y limitaron las subidas de texturas.

En la primera sesión en hardware real, el 29 de septiembre, la build que ya se distribuía murió al arrancar; el perfil -DGDX_3DS_O3DS=ON, ajustado a la memoria de la consola, sí arrancó y corrió a unos 10 fps.

El giro vino al día siguiente. Los contadores de rendimiento del hardware mostraron que el límite real eran los fallos de caché de instrucciones, no la cantidad de instrucciones. Con ese dato, el equipo descartó un fallback de pose-replay y construyó un renderizador nativo: un bucle chico por categoría de carrera, dimensionado para caber en los 16 KB de caché de instrucciones. El tiempo de frame mediano en una carrera 2D de Grand Prix bajó a 16,5 ms.

Entre el 3 y el 8 de octubre, un resubmit por ojo con su propio modo de swap-pacing llegó a 59-60 fps en 3D en la mayoría de circuitos de Grand Prix. Los más pesados (Silence, Sand Ocean) todavía pueden activar la red de seguridad de frame-skip y caer a 30 fps estables a mitad de carrera. El Expansion Kit de 64DD se verificó idéntico tick por tick bajo el renderizador nativo y arrancó en el Old 3DS, que resultó demasiado lento para distribuirlo ahí.

¿Qué dice el resto del ecosistema sobre los ports con IA?

No todo el mundo celebra este tipo de proyectos. TechSpot reportó que el desarrollador Dario, figura de la comunidad de ports caseros y contribuidor principal de un port de Banjo-Kazooie, publicó el 4 de octubre de 2026 una crítica dura al uso de LLMs para decompilar y recompilar juegos retro.

Su argumento: los LLMs permiten que alguien sin experiencia ponga un juego a correr, pero eso ya era la parte fácil. Sostiene que el código generado es verboso y difícil de auditar, y compara dos ports de Donkey Kong 64 con el mismo nombre: el que no usó IA avanzó rápido, mientras el otro se estancó por falta de conocimiento del juego original y de las herramientas de recompilación de N64.

El mismo reporte señala que HarbourMasters, el equipo detrás de ports conocidos de Super Mario 64, Mario Kart 64, Star Fox 64, Ocarina of Time y Majora's Mask, lleva años usando LLMs. La tensión de fondo es real: los ports nativos habilitan resoluciones y tasas de refresco que la emulación no permite, pero el debate sobre cómo se construyen sigue abierto.

¿Qué significa esto para tu startup?

Cuatro lecciones concretas que puedes aplicar esta semana:

• Instrumenta antes de reescribir. El equipo pasó días optimizando la cuenta de instrucciones hasta que los contadores de hardware mostraron que el problema era la caché. Antes de reescribir un módulo lento, mide con la herramienta del sistema, no con tu intuición.
• Un director, muchos ejecutores. La estructura que funcionó fue una sesión larga manteniendo el contexto y subagentes paralelos atacando frentes acotados con una meta medible. Si repartes trabajo entre agentes sin un orquestador que conserve el hilo, terminas con 147 piezas que no encajan.
• Presupuesta los tokens como presupuestas el cloud. El proyecto publica tokens, dólares y cantidad de subagentes, con los supuestos de precio declarados. Si no sabes cuánto te cuesta una corrida de agentes, no puedes decidir cuándo conviene usarlos.
• Audita el resultado integrado. La revisión adversarial previa al release es lo que separa un prototipo de un producto. Un agente que revisa lo que otro agente escribió, con criterio explícito, es más barato que descubrir el bug en producción.

Conclusión

G-Diffuser es un caso raro: un proyecto de una sola persona que entregó tres builds de consola, soporte para dos generaciones de hardware y un renderizador propio en menos de tres meses, orquestando agentes de IA. Lo replicable no es el port en sí, sino el método: frentes paralelos con metas medibles, un orquestador que sostiene el contexto, medición con contadores reales antes de optimizar y una auditoría adversarial antes de publicar. La crítica de la comunidad de ports también deja una advertencia útil: la IA acelera la primera versión, pero la calidad final sigue dependiendo de cuánto entiendas el problema que estás resolviendo.

Fuentes

• F-Zero X on Nintendo 3DS - post-mortem (fuente original)
• Banjo-Kazooie port developer blasts AI vibe coding (TechSpot)