A lo largo de una semana de julio de 2026, publiqué cinco juegos de navegador en mi propio sitio: un juego de supervivencia de vóxeles al estilo Minecraft, un juego de carreras de karts en 3D al estilo Mario Kart, un rompecabezas de combinar tres al estilo Candy Crush, un juego de gran estrategia que se juega sobre un mapa del mundo real con más de mil provincias generadas de forma procedimental, y una plataforma al estilo Super Mario construida alrededor del folclore coreano. Los cinco funcionan enteramente en el navegador, sin backend, sin proceso de compilación y sin más presupuesto que el nombre de dominio. Los cinco se construyeron casi por completo trabajando junto a un agente de codificación de IA, mientras yo hacía de dueño de producto, tester y la única persona que realmente mira la pantalla.
Llevo este sitio sobre temas de IA y tecnología, pero quería ver hasta dónde podía llegar un agente de IA en una categoría de software completamente distinta a las aplicaciones CRUD y los pipelines de contenido de los que suelo escribir: juegos en tiempo real, con física, contenido procedimental e IA enemiga, donde “compila” está muy lejos de “es divertido”. Esto es lo que aprendí sobre el proceso real al publicar cinco de ellos, y sobre la única decisión que hizo posible todo el proyecto.
Cinco juegos, una sola estructura de carpetas estática
Cada juego vive en public/games/<slug>/ del sitio como un puñado de archivos estáticos: un index.html y uno o dos archivos .js, y en ocasiones una pequeña librería incluida como Three.js para el 3D. No hay empaquetador, ni proceso de compilación, ni un árbol de dependencias de npm que mantener parcheado. Un único archivo de registro enumera el slug, el título y la descripción de cada juego en cinco idiomas; la página índice de juegos, la página de detalle de cada juego y el mapa del sitio se generan todos a partir de esa única lista. Añadir un sexto juego significa añadir una entrada a un array.
Los cinco, brevemente:
- Un juego de supervivencia de vóxeles — ciclo de día y noche, siete tipos de monstruos con comportamientos distintos, una pelea contra un jefe cada tercera noche, un sistema de logros y una vista de combate en primera persona con balanceo de armas.
- Un juego de karts en 3D — un circuito con colinas, peraltes y curvas en S, once personajes jugables con estadísticas distintas, turbo cargado por derrape y oponentes controlados por la CPU con “rubber-banding” para que las carreras se mantengan reñidas sin sentirse guionizadas.
- Un rompecabezas de combinar tres — un tablero de 8x8, cuatro tipos de fichas especiales (incluida una ficha arcoíris que elimina un color entero), efectos de partículas y una banda sonora sintetizada a 132bpm generada por completo con la Web Audio API, sin un solo archivo de audio.
- Un juego de gran estrategia — un mapa del mundo real dividido en unas 1.200 provincias mediante teselación de Voronoi a partir de las fronteras reales de los países, simulación de población y producción de alimentos, y 230 naciones controladas por IA con su propia lógica de diplomacia y guerra.
- Una plataforma — un juego de correr y saltar con enemigos del folclore coreano (un gumiho, un dokkaebi, una especie de mensajero de la muerte) en lugar de goombas y koopas, cinco niveles diseñados a mano y un unicornio montable que cumple el papel de Yoshi.
Ninguno de ellos necesitó un servidor. El progreso y las clasificaciones locales viven en localStorage, con un botón de exportar/importar que convierte el archivo de guardado en una simple descarga JSON —la única solución real a la falta de backend— además de un enganche dejado ahí (una constante REMOTE_API sin usar) por si algún día quiero conectar clasificaciones reales entre dispositivos.
El ciclo de despliegue
El propio sitio es una compilación estática de Astro, publicada en GitHub Pages mediante un push forzado de la carpeta dist/ recién compilada a una rama gh-pages — un script de dos líneas que se ejecuta cada vez que hay algo nuevo que publicar. El cambio de idioma en los juegos (y en el resto del sitio) usa un simple parámetro de consulta ?lang= en lugar de rutas localizadas independientes, lo que permite que una sola compilación de un juego sirva cinco idiomas sin ningún framework de i18n. El soporte móvil llegó después, como una capa añadida encima en lugar de una reescritura: los dispositivos táctiles se detectan automáticamente (pointer: coarse, con un ?touch=1 para forzarlo al probar en escritorio), y una cruceta y botones virtuales alimentan el mismo objeto de estado de teclas que ya usaban los controles de teclado, así que la lógica del juego en sí nunca necesitó saber si la entrada venía de un pulgar o de un teclado.
La decisión que más importó: probar sin un ser humano
Aquí está la parte que realmente hizo que esto se pudiera publicar al ritmo en que ocurrió. Los juegos son interactivos y visuales por naturaleza, lo que los hace inusualmente difíciles de verificar para un agente de IA por sí solo: no se puede afirmar fácilmente que “la física se siente bien” a partir de un diff de texto. El primer instinto fue recurrir a un navegador headless y manejar el juego como lo haría una persona. Eso no funciona, por una razón que no es obvia hasta que te topas con ella: el presupuesto de tiempo virtual de Chrome en modo headless no impulsa de forma fiable requestAnimationFrame. Un bucle de juego construido sobre rAF simplemente no corre a una velocidad útil bajo automatización headless, sin importar cuánto se alargue ese presupuesto de tiempo virtual. Cualquier prueba construida sobre “cargar la página, esperar, tomar una captura” no está probando casi nada.
La solución que hizo verificables los cinco juegos sin que un humano tocara jamás el ratón: cada juego incluye un modo ?test=sim que avanza la física del juego de forma síncrona con un paso de tiempo fijo, completamente desacoplado de requestAnimationFrame y del reloj real, y registra las aserciones con console.warn en lugar de console.log — la captura de stderr de Chrome headless recoge de forma fiable los warnings pero descarta los logs normales. Ese único patrón —avance síncrono y determinista más registro a nivel warn— es lo que permitió a un agente de IA comprobar que las cinco fases de la plataforma se podían completar, que el tablero de combinar tres nunca se bloquea, que la adyacencia de provincias en el juego de estrategia se mantiene simétrica después de decenas de turnos controlados por IA, y que cada archivo de guardado se restaura correctamente, todo sin que nadie abriera el juego en una pestaña de navegador real. Un segundo modo más ligero, ?shot=1, congela el reloj de fotogramas por un instante para que una captura de pantalla pueda registrar un momento dramático específico (una explosión a mitad de vuelo, un encuentro con un jefe) sin depender de la suerte del tiempo.
El error del que más aprendí
El juego de gran estrategia dibuja sus aproximadamente 1.200 provincias codificando el identificador numérico de cada una como un color en un lienzo oculto, y luego leyendo esos colores de vuelta para responder preguntas como “qué provincia hay en esta coordenada” o “qué provincias son adyacentes”. Es un truco elegante —usar un lienzo como tabla de consulta en lugar de como una imagen— hasta que recuerdas que los lienzos aplican antialiasing en los bordes de las formas. Ese mezclado inventaba silenciosamente identificadores que no correspondían a ninguna provincia real en cada borde, lo que corrompía los cálculos de centroides y los datos de adyacencia de formas que, por separado, eran diminutas pero que juntas resultaban extrañas: el centro calculado de Alemania terminó en algún punto del Atlántico. La solución fue validar cada píxel decodificado contra el cuadro delimitador vectorial real de esa provincia, y recurrir a una votación por mayoría entre los píxeles vecinos cuando un píxel fallaba esa comprobación. La lección general se trasladó también a otros juegos: cada vez que reutilizas una superficie de renderizado como estructura de datos en lugar de como una imagen, las propias comodidades del pipeline de renderizado —antialiasing, mezclado, mipmapping— se convierten en errores de corrección esperando a ocurrir.
Para qué sirve realmente aquí un agente de IA
Después de estos cinco juegos, mi lectura honesta es que un agente de codificación de IA es genuinamente fuerte precisamente en lo que hace lento el desarrollo de juegos en solitario: conectar sistemas de guardado, generar arte vectorial de forma procedimental en un lienzo en lugar de conseguir assets de sprites, ajustar curvas de dificultad una vez que se pueden medir (un ajuste de balance de combinar tres, por ejemplo, no es más que ejecutar miles de partidas simuladas y comparar la puntuación media por movimiento con un objetivo), y trasladar un patrón que ya funciona de un juego al siguiente. No sustituye a jugar de verdad el resultado: algunos errores solo salieron a la luz porque las aserciones de una prueba sintética se cumplían técnicamente mientras el comportamiento real era incorrecto, y la única defensa real fue mirar capturas en hoja de contacto o jugar la compilación a mano antes de darla por terminada. El trabajo de mayor impacto de todo el proyecto no fue ningún juego en concreto: fue construir bien, una sola vez, el patrón ?test=sim, de modo que cada juego posterior al primero heredara una forma de ser verificado sin que nadie tuviera que mirarlo.
Los cinco juegos están en línea y son gratuitos para jugar en menewsoft.com/games.