Lo he ido diciendo de pasada en casi todas las entregas, así que toca contarlo entero. Obviamente, la práctica totalidad del código de Orbafall Legions lo escriben agentes de IAProgramas basados en modelos de lenguaje que hacen tareas de varios pasos por su cuenta: leen el código, lo cambian, pasan las pruebas y piden revisión. bajo mi dirección. Es mi primer videojuego, y también la primera vez que llevo un proyecto de este tamaño así, de principio a fin, sin escribir yo cada línea. Esta última entrega va del método (qué decido yo y qué no, cómo se reparte el trabajo y qué revisiones han parado una fusión), con lo que ha ido mal y el día en que el desarrollo pasó de días a horas, porque creo que es la parte sobre la que más preguntas razonables se pueden hacer.
1 - Qué decido yo
Lo que no delego es el diseño, que es lo más entretenido. Cada decisión lleva un número [las de diseño del juego, las de alcance de cada hito, las de arquitectura], queda escrita con su fecha y la firmo yo. La manera de tomarlas la fijé el primer día y me ha servido desde entonces: las preguntas me llegan de una en una, con su contexto, una propuesta y las alternativas con sus pros y sus contras, y yo elijo o pido más detalle. Cuando una decisión no es obvia, pido el desarrollo completo, con sus cifras, y lo abro en un editor para estudiarlo con calma, como hice con las distribuciones de los tramos de dificultad de la entrega 11. Ningún agente decide por inferencia lo que es mío. Lo que se resuelve en mi ausencia (y es mucho, porque muchas noches me voy a dormir dejando la orden de avanzar sin mí) queda marcado como provisional hasta que lo firmo por la mañana, y si no me gusta, se deshace.
Las decisiones viven en un plan por fases, con criterios que se verifican con una orden, una prueba o un artefacto. Una fase cerrada no se reabre, y un defecto posterior se corrige hacia delante, con su entrada de alcance. En cada fase hay, además, puertasUn punto del plan en el que no se sigue hasta que juego lo hecho y doy el visto bueno, o digo qué no me gusta. en las que juego yo, en el PC y en la Steam Deck, y digo qué no me gusta; de ahí han salido el flujo del turno, los mapas pequeños, la muerte súbita y media docena de cosas más que las pruebas no veían.
Imagen 1. Qué decido yo y qué no.
2 - Quién escribe el código
Una sesión principal hace de controladora: lee las decisiones, escribe el plan de cada funcionalidad como un conjunto de tareas con sus entradas y sus salidas, y lanza implementadores, un agente por tarea, cada uno en su propia copia de trabajoUna carpeta propia con el repositorio entero, en su propia rama, para que cada agente trabaje sin pisar lo que hacen los demás. En Git, un worktree. del repositorio (nunca dos escritores en el mismo árbol). Las tareas se dimensionan para que un implementador las termine en una sesión, con un módulo y unos pocos ficheros de salida como mucho. Un revisor independiente, que no ha visto escribir el código, revisa cada plan antes de fusionarIntegrar en la rama principal los cambios preparados en una rama aparte. En inglés, merge., y antes de que nada entre en la rama principal corre la verificación local: guardianes, pruebas unitarias, el corpus de partidas grabadasUna colección de partidas guardadas que las pruebas rejuegan enteras en cada cambio. Si un resultado se mueve, algo ha cambiado en las reglas. y la matriz de capturas, en Windows y en un contenedor Linux desde un clon limpio. Solo la sesión controladora fusiona, y nunca a la fuerza.
Los modelos se eligen por tarea: los contratos y la aritmética del motor van al más capaz, y lo mecánico, a los más baratos. El diario de desarrollo del que sale esta serie es, a su vez, un repositorio que los agentes mantienen al cerrar cada hito, con capturas y cifras del repositorio del juego, y que se copia solo a mi Obsidian; lo pedí el 18 de octubre con estas palabras: «Quiero a futuro poder contar una historia del desarrollo. Recordar todo este bonito proceso».
3 - Las revisiones que pararon una fusión
Lo que más me ha convencido del método es el revisor, que ha parado fusiones por fallos que a mí se me habrían colado. Os dejo una muestra, en orden:
- Un remapeo del mando que guardaba Shift+Tab como Tab a secas y, al volver a arrancar, borraba todos los controles de la persona.
- Tres fallos de la IA que podían colgar una partida real: invocar una y otra vez sobre una trampa oculta que anula la invocación, un portador capaz de sacrificarse a sí mismo y un desarmador que alternaba órdenes sin fin.
- La huella de la tabla de resultado esperado, que no veía la sección de la arena de los datos de la IA y servía filas viejas como exactas.
- Un camino del modo espectador que cambiaba el registro de la partida al guardar y salir a mitad de un combate.
- Al retirar el modo clásico, unas pruebas de propiedadesPruebas que comprueban que algo se cumple para miles de casos generados al azar, en lugar de para unos pocos ejemplos escritos a mano. que se quedaron sin segundo reglamento y dejaron de probar nada sin que nadie lo notase.
- Una IA que, en el tablero hexagonal recién estrenado, contaba las casillas fuera del mapa como zonas por explorar y mandaba piezas a las esquinas sin parar.
- Las flechas del segundo jugador moviendo el menú de pausa del primero en la misma arena.
Creo que ninguno de esos siete lo habría encontrado yo jugando, y casi ninguno una prueba escrita por quien escribió el código.
4 - Lo que ha ido mal
Ha ido mal bastante, y casi todo de ritmo. A los pocos días de empezar ya tenía la sensación de que íbamos lentos, y la he tenido en cada fase. Las tablas de resultado esperado se pararon dos veces en una noche porque la regla seguía cambiando, y cuando pregunté por qué no se me había propuesto abaratar lo sintético, no había una buena razón. Los reselladosVolver a calcular y guardar las huellas y los resultados esperados del corpus de pruebas después de un cambio legítimo de las reglas. del corpus de partidas grabadas (que al principio me parecían un trámite y luego, una obsesión) me hicieron escribir que no quería una postura sistemática de evitar rehacer cosas en detrimento de hacerlas bien. Y el 1 de noviembre lo dije en voz alta, y sin ninguna elegancia: el desarrollo estaba siendo un tedio enorme, lento en cada fase, y la culpa la tenían unos planes ineficientes, que sellaban cada dos por tres y pasaban pruebas completas en cada tarea, con días para algo que debería durar horas. Para más inri, no estábamos usando el simulador de la entrega 12 cuando era treinta veces más rápido e idéntico, y nadie paralelizaba sin que yo lo pidiera.
De esa mañana salieron cuatro cambios, que desde entonces están en las reglas del proyecto. El corpus deja de sellar la identidad del paquete de datos, que era lo que obligaba a resellar por cualquier cambio de contenido; las pruebas pasan a ser escalonadas, con un único resellado al cierre de cada plan; el simulador va primero en todo lo pesado y es un carril del plan desde la primera tarea, y los planes son un grafo de tareasUn plan en el que cada tarea declara de qué otras depende. Las que no dependen entre sí pueden hacerse a la vez. que se lanzan solas en cuanto sus entradas están congeladas, en lugar de una lista que avanza de una en una.
Imagen 2. El 1 de noviembre, antes y después de cambiar el proceso.
La diferencia se vio el mismo día: antes del cambio, seis tareas en unas nueve horas, casi siempre de una en una, y después, otras seis en unas tres, con hasta cinco agentes a la vez y el simulador portando cada tarea en cuanto se cerraba. No sé si aguantará, pero fue el día más productivo del proyecto, y el que más me hizo pensar en lo que había estado haciendo mal durante un mes.
5 - Palabras finales
Hasta aquí la serie, de momento. De todo el método, lo que más valoro es el revisor, y lo que de verdad decide si el juego va bien son las puertas en las que juego yo. El resto (el ritmo, las reglas del proceso, qué se prueba y cuándo) lo he cambiado ya tres veces, y lo cambiaré más. Os dejo dos preguntas. Para quien use agentes en su desarrollo, ¿qué no delegaríais nunca? Y para quien no los use, ¿qué os haría empezar?
5.1 - Para el futuro
La serie seguirá conforme avance el juego: el siguiente hito es el 0.5, el juego entero jugable de principio a fin con arte provisional e IA, y después vienen las sesiones de diseño de la fase 6, empezando por la que más ganas tengo de contar, qué es el portador del orbe. Si habéis llegado hasta aquí desde la primera entrega, gracias de corazón; y si queréis charlar, el hilo del proyecto en el subforo de gamedev de Mediavida es donde más me muevo.
Orbafall Legions es un proyecto personal no oficial, no afiliado con Silicon Knights, SSI, Mindscape ni Ubisoft.
Versión 1.0R1 (02/11/2026)
Changelog
- Versión 1.0R1 (02/11/2026)
- Repaso de redacción.
- Versión 1.0R0 (01/11/2026)
- Versión inicial.