¿Cómo se lanza un juego móvil 3D en Unity con agentes de programación de IA?

Soy el CTO de GOGOGO LLC, y la mayor parte del código de GoTasty la escribieron agentes de programación de IA (Claude Code) trabajando en nuestro repositorio, conmigo dirigiendo, revisando y fusionando. El juego es un idle arcade 3D low-poly en Unity 6: empiezas con un horno de simit en Estambul, llevas montones de comida al mostrador, contratas aprendices y abres puestos nuevos. A 8 de noviembre de 2026 tiene 167 ubicaciones jugables en 33 países. Este es el montaje que lo hace posible, incluidas las partes que se rompieron.

¿Por qué la CI es el compilador?

En nuestro día a día no hay una sesión interactiva del Unity Editor. Un agente no puede hacer clic por la vista de escena, y yo no quería un flujo en el que el estado real del juego viva en el editor abierto de una sola persona. Así que cada cambio es un commit y GitHub Actions lo compila. Cada push que toca Assets/, Packages/ o ProjectSettings/ produce un build de Android, y un build de iOS está a un lanzamiento manual de distancia.

Esa regla obliga a ser honesto. Si el build está en rojo, el cambio no ha ocurrido. Un fallo pasajero del linker se vuelve a lanzar; todo lo demás recibe un commit de arreglo. También significa que nadie necesita Unity instalado para tener un APK jugable, algo que importa cuando un fundador lleva la ingeniería y el otro el producto.

Los builds empezaron en runners Linux alojados por GitHub con GameCI, pasaron a un runner más grande de 8 núcleos cuando el número creciente de ciudades dejó sin memoria al paquete de la tienda, y desde el 4 de noviembre de 2026 se ejecutan por defecto en un Mac mini M4 propio. Allí, un espacio de trabajo caliente convirtió un build de Android de 52 minutos en frío en unos 8 minutos. Ese runner lo explico aparte en ezagor.com.

¿Cómo evitas que un agente de IA rompa una escena de Unity?

Las escenas y prefabs de Unity son ficheros YAML grandes que se fusionan mal y casi no se pueden revisar. Evitamos por completo las escenas editadas a mano: un script de editor (PrototypeSceneBuilder) genera la escena del juego en cada build. Cuando un agente quiere mover un mostrador o añadir una estación, cambia el C# que construye la escena, y ese cambio aparece en un diff normal.

Otros tres límites hacen la mayor parte del trabajo:

• Un solo sitio para los números. Cada valor ajustable (precios, tiempos, curvas de mejoras) vive en un único asset EconomyConfig, y el juego solo lee números a través de GameManager. Un agente que ajusta el ritmo toca un fichero, no veinte.
• Un solo sitio para los SDK. Analítica, anuncios, consentimiento e informes de fallos se llaman solo desde Services/. Los nombres de eventos siguen el documento de diseño y no cambian tras el lanzamiento, así que un refactor no puede romper un embudo en silencio.
• Una clase por fichero, y el nombre del fichero es el de la clase. Aburrido, pero mantiene las ediciones de los agentes pequeñas y fáciles de revisar.

¿Cómo se crean 167 ubicaciones sin construir cada una a mano?

Las primeras ciudades se construyeron a mano en C#: puestos, animaciones de estaciones y decorados escritos para cada ciudad. Eso no escala, y cada ciudad hecha a mano además agrandaba la app base. A finales de octubre pasamos a un kit de ciudades. Ahora una ciudad es un fichero JSON con sus productos, cinco puestos, fachadas, colores, fondo y textos en inglés, turco y español. Unos arquetipos compartidos (espetón, parrilla, freidora, horno, vertido, olla y otros) construyen los puestos, y un único intérprete los anima con una línea de tiempo definida en los datos.

Los agentes rinden bien en este trabajo cuando el formato es estricto. Un validador comprueba el esquema, los tres idiomas, el bloque de productos y el equilibrio de ingresos antes de que una ciudad llegue a un build. 102 de las 167 ubicaciones son ciudades del kit; las anteriores, hechas a mano, siguen igual. Los puestos del kit se preparan durante el build y, en los builds de tienda, se descargan de nuestra CDN la primera vez que el jugador viaja allí, así que la app no crece con cada ciudad.

¿Quién juega el build si los testers no lo hacen?

Pronto vimos que los testers instalan los builds y casi nunca los juegan. Por eso, tras cada candidato a versión o cambio de jugabilidad, los agentes hacen QA en el emulador de Android. Un agente juega el build de lanzamiento como un jugador nuevo: primero marca el dispositivo como tester, sigue el tutorial y nunca toca un anuncio real. Otro ejecuta un build de desarrollo con un bot integrado que juega como un jugador atento y registra su ritmo cada 15 segundos.

Así ajustamos el ritmo sin adivinar. Las pruebas de ritmo son deterministas (un paso fijo de 1/30 s y un aleatorio con semilla), de modo que dos ejecuciones del mismo build dan los mismos números y un cambio de equilibrio aparece como una diferencia real. Un script de recorrido lleva la cámara por una lista de ciudades y genera hojas de capturas, y así una persona revisa diez calles nuevas en pocos minutos. En el emulador los agentes tienen un alcance acotado: dirigirse siempre a un solo dispositivo con adb -s, nunca lanzar un comando de cierre general, usar dos instancias en puertos fijos.

¿Qué sigue haciendo la persona?

Los agentes escriben la mayor parte del código, la documentación y las notas de QA, y tienen permiso permanente para hacer commit y push en ramas de trabajo. Preguntan antes de cualquier cosa irreversible, de cualquier gasto y de cualquier cosa que toque credenciales, y algunos pasos de consola están reservados directamente para nosotros. Yo decido qué se construye, reviso las fusiones a la rama de integración y juzgo si una calle se ve bien. Mi hermano Okan lleva el producto: fichas de tienda, testers y qué lanzamos después.

La otra tarea humana es mantener honesta la memoria compartida. El repositorio tiene un CLAUDE.md largo que cada sesión de agente lee primero: las reglas técnicas, el historial de versiones, la configuración de cuentas y qué se rompió la última vez. Cuando un agente aprende algo por las malas, lo escribe ahí. Ese fichero es la diferencia entre una sesión que empieza de cero y una que empieza desde ayer.

¿En qué punto está GoTasty?

GoTasty está en pruebas en Android e iOS: prueba cerrada en Google Play y TestFlight en iOS. Las ciudades, los platos y el tráiler están en la página de GoTasty, y el diseño se cuenta en el diario de desarrollo de GoTasty. Para ver cómo uso agentes fuera del desarrollo de juegos, lee cómo operar sistemas de IA multiagente en producción.