Aprender AI-DLC creando un juego, parte 13: UI nueva y descargas
Esta es la parte 13 de una serie sobre aprender AI-DLC creando un juego, World Rift Conflict, en Godot con un backend en AWS. La parte 1 lo preparó, y la parte 11 terminó con la primera partida real, que mostró una pantalla que no cabía en la ventana. Esta sigue el trabajo que lo arregló, hasta su última etapa.
Partes hasta ahora:
- Parte 1: configuración
- Parte 2: prueba de concepto
- Parte 3: pruebas E2E automáticas
- Parte 4: lo que encontraron las revisiones
- Parte 5: dentro de una etapa
- Parte 6: un intent de corrección
- Parte 7: ideación
- Parte 8: incepción
- Parte 9: un error de despliegue en AppSync
- Parte 10: esqueleto funcional
- Parte 11: retrospectiva
- Parte 12: guardas y hooks
- Parte 13: UI nueva y descargas
- Parte 14: las capas de memoria
- Parte 15: los agentes y roles
En resumen
- Jugué el juego publicado, hice cuatro capturas de lo que fallaba y se las di a AI-DLC como un trabajo nuevo. Usó el plan
classic: seis unidades de trabajo y después una sola etapa de Build and Test para todas. - Todas las pruebas pasaron, y aun así había dos fallos en pantalla. Las imágenes que guarda la prueba de extremo a extremo para mí mostraban una caja vacía donde debía haber una flecha, y un anillo de selección sin sus bordes de arriba y de abajo. Build and Test devolvió los dos a Code Generation.
- La pantalla casi vacía de mi primera captura se reprodujo en un navegador real, ejecutando el commit antiguo junto al nuevo. La comprobación antigua de controles fuera de pantalla la había dado por buena.
- Build and Test vio que un requisito, una ronda solo con teclado, no tenía comprobación en una versión real, y añadió una.
- El último requisito era la primera publicación para escritorio. El comando de publicación se había creado y probado nueve días antes, pero su stack de descargas nunca se había desplegado. La primera ejecución real lo descubrió.
Dónde empezó
La primera partida real de la versión web fue en la parte 11. La pantalla de la partida salía cortada a la izquierda y arriba, con barras negras a los lados. Una captura mostraba una pantalla oscura casi vacía. Lo anoté y empecé un trabajo nuevo con una línea:
Improve the game's UI/UX: the match screen must fit the window at common sizes, show less text (short labels, help on demand), and add visuals (banner, map, country markers).
AI-DLC propuso su plan classic: 15 etapas y 15 aprobaciones. Se salta la Ideación, porque la idea y el alcance del juego ya estaban decididos. Empieza con Reverse Engineering, porque el código ya existía. Ese análisis explicó la mayoría de las capturas solo leyendo. El juego usaba una vista fija de 960 x 640, así que ponía barras negras con cualquier tamaño de ventana. El tamaño mínimo del panel era mayor que la vista, así que se cortaba por los cuatro lados. Y encontró lo que más importa para este artículo: ninguna prueba existente podía detectar el recorte. La comprobación de controles fuera de pantalla medía cada control contra la raíz de la pantalla, y la raíz crecía con su contenido.
La Incepción dividió el trabajo en seis unidades:
| Unidad | Qué construyó |
|---|---|
| Base de ajuste | un diseño que sigue a la ventana, y una prueba que compara cada control con lo que muestra la ventana |
| Recursos y marca | un logo, un banner, las banderas de los países y un mapa |
| Paneles de la partida | la pantalla de la partida rehecha en paneles, con ayuda cuando se pide y un menú |
| Mapa del mundo | el mapa con un marcador por país, hecho antes que las propuestas porque así lo elegí |
| Propuestas | un panel para tratados, comercio y conflictos, con una bandera en cada fila |
| Publicación | iconos para cada plataforma, y las comprobaciones de tamaño de descarga y tiempo de carga |
Lo que las pruebas no podían ver
La primera ejecución de Build and Test, el 2026-11-07, no tuvo ninguna prueba fallida que viniera del juego. Encontró dos fallos en el propio kit de pruebas, que arregló, y luego dos en el juego que ninguna prueba buscaba.
En la entrevista de Practices Discovery yo había elegido cómo juzgamos que una pantalla cabe y se ve bien. Las pruebas miden el rectángulo de cada control contra la ventana y fallan si algo se corta. La prueba de extremo a extremo además guarda una imagen de cada pantalla principal en cada tamaño, para que yo la mire. Nada compara esas imágenes de forma automática. Cómo se ve una pantalla sigue siendo mi juicio.
Las imágenes mostraron:
- "You ▯ Papua New Guinea". La línea de propuesta usaba una flecha, →, y la fuente del juego no tiene ese carácter, así que dibujaba una caja vacía. El ◆ de la marca de datos reales tenía el mismo problema.
- Un anillo con dos bordes. En el diseño más bajo, 1024 x 600, el anillo del marcador seleccionado perdía los bordes de arriba y de abajo. Se dibujaba fuera del marcador, más allá del área recortada del mapa.
Build and Test no arregla fallos en el código. Escribe un loop-back, con un diagnóstico, la etapa donde está la causa, un arreglo previsto y su coste, y devuelve el trabajo. El loop-back 1 volvió a Code Generation para dos unidades. Las líneas de propuesta pasaron a palabras simples en los dos idiomas, como "Tú a Papúa Nueva Guinea: tratado en espera". Una prueba nueva falla con cualquier carácter del texto del juego que la fuente no pueda dibujar. El anillo ahora se dibuja dentro del área del mapa.
Después Build and Test volvió a ejecutarse.
La pantalla casi vacía, hallada en un navegador
La pantalla casi vacía de mi primera captura era el único fallo que la lectura no explicaba. Un barrido sin ventana en la primera unidad encontró una causa probable, y la unidad de paneles la arregló con una prueba de regresión. El plan decía que la prueba en un navegador real llegaría en Build and Test.
La primera ejecución de Build and Test no la hizo. La comprobación estaba aplazada en los registros de una unidad, y la etapa no listó las comprobaciones aplazadas antes de empezar. La segunda sí. Sacó el commit antiguo en un worktree desechable, ejecutó allí el propio kit de pruebas de ese commit, y jugó la misma partida en las dos versiones. Usó español con el texto al 125%, porque ahí es donde el barrido había mostrado el desbordamiento.
El diseño antiguo se quedaba en blanco justo cuando llegaba la propuesta de un país del ordenador en la ronda 3. La portada de este artículo muestra ese momento en las dos versiones. La etiqueta de la propuesta se calculaba con 1 píxel de ancho, lo que estiraba su fila y luego toda la raíz de la pantalla, así que todo salía de la ventana. La comprobación antigua respondió "no hay nada fuera de pantalla" las dos veces, porque medía contra esa misma raíz.
Un hueco que la etapa cerró sola
Un requisito pide que un jugador solo con teclado pueda terminar una ronda. Lo comprobaba una prueba de escena, pero ningún escenario de extremo a extremo en una versión real. Build and Test trata un objetivo sin evidencia como un fallo, así que añadió el paso: durante una ronda completa, el orden de tabulación de la propia versión debe llegar a los cuatro controles deslizantes, los cuatro botones de ayuda y el botón Confirmar, y Confirmar debe terminar la ronda. Pasó en Linux, Chromium, Firefox y WebKit.
La publicación que nunca se había ejecutado
El último requisito era la publicación para escritorio: cuando la versión web pasa, publicar descargas para Windows, macOS y Linux. Aquí la etapa de AI-DLC solo podía parar y preguntar, porque el orden es subir main, que despliega producción, luego una versión web que pase, luego mi visto bueno, y después la publicación. Subo yo, nunca el agente. Así que la etapa se detuvo con dos opciones, "Accept failure" o "Abort". Yo respondí con una pregunta: "do i push main to check desktop first?" Y subí.
La versión web pasó, y también la comprobación rápida en producción. Después la publicación encontró un obstáculo tras otro:
- El modo automático de Claude Code la rechazó, como un despliegue en producción. Cambié a aprobación manual.
- No había sesión de AWS en el entorno. Mi sesión era válida, pero el script la quiere como variables de entorno.
- El árbol de git no estaba limpio. Tenía borradores del blog sin confirmar. El agente los apartó y los devolvió después.
- El stack de descargas no existía. El comando de publicación se había creado y probado en el trabajo anterior, contra imitaciones y un backend de pruebas, pero el stack donde publica nunca se había desplegado.
AI-DLC preguntó cómo terminar la etapa, y elegí desplegar el stack. Es un bucket de S3 y una distribución de CloudFront con su certificado, con un coste estimado de menos de 0,60 $ al mes. El script de despliegue hizo antes seis comprobaciones de solo lectura, entre ellas que existen las alertas de presupuesto, y desplegó en unos siete minutos. Después se ejecutó la publicación: tres versiones, comprobaciones de tamaño, secretos y firma, una ronda jugada por la versión de prueba de Linux, y cada archivo publicado descargado de nuevo y comparado con el construido.
Hubo un tropiezo más, del propio AI-DLC. Apartar mis borradores con git stash se llevó también las líneas que los hooks de AI-DLC acababan de escribir en su registro de auditoría. Devolverlas a mano fue rechazado, porque solo las herramientas de AI-DLC pueden escribir ese registro, la comprobación de integridad de la parte 12. El segundo intento confirmó primero el registro y apartó solo mis archivos.
Descargué la versión de Linux desde la página de descargas del juego, y funciona. No tengo a mano un PC con Windows ni un Mac, así que esos dos quedan como no probados todavía.
Las cifras
| Medida | Resultado | Límite |
|---|---|---|
| Pruebas unitarias y de escena de Godot | 752, 0 fallos, 87 s | como mucho 90 s |
| Cobertura de GDScript | 90,2% | al menos 80% |
| Fallos de extremo a extremo, cuatro plataformas y densidad de píxeles 2 | 0 | 0 |
| Primera carga web a 25 Mbit/s, gzip | 5,6 s | menos de 20 s |
| Imágenes añadidas | 0,47 MB | como mucho 2 MB |
| Fotogramas del mapa a 1920 x 1080 | 60 por segundo | al menos 30 |
| Descargas de escritorio | Windows 38,8 MB, macOS 61,5 MB, Linux 29,2 MB | 150 MB cada una |
Lo que me diría a mí mismo
- Guarda las imágenes, y míralas. Los dos fallos del loop-back pasaron todas las pruebas. Una imagen por pantalla y tamaño, juzgada por una persona, los encontró en minutos.
- Lista las comprobaciones aplazadas antes de empezar Build and Test. Una comprobación que una unidad deja "para Build and Test" se pierde con facilidad. La primera ejecución perdió una.
- Para demostrar un arreglo, ejecuta también la versión antigua. El commit antiguo en un worktree desechable, con su propio kit de pruebas, mostró el fallo al primer intento.
- Un comando que necesita infraestructura no está terminado hasta que se ha ejecutado una vez de verdad. El comando de publicación pasó todas sus pruebas durante nueve días sin un stack donde publicar.
Qué sigue
El trabajo de UI está terminado y publicado: la versión web está en producción, y las primeras descargas de escritorio están en la página de descargas. Windows y macOS aún necesitan su primera comprobación. El próximo trabajo todavía no está elegido. Hasta entonces, más artículos a fondo a partir de los mismos registros.
El primero de esos artículos es la parte 14: cómo recuerda AI-DLC lo que aprendió.