¿Por qué siempre creamos un juego antes de lanzar un nuevo modelo?

¡La espera ha terminado! ¡Shadow Blade Zero ya está disponible!

Este juego de acción desarrollado en el país, que apareció por primera vez en 2023 y pasó por varias demos de jugabilidad y retrasos (mejor dicho, retrasos), se lanzó oficialmente hoy para PC y PS5.

En tres semanas, otra larga espera llegará a su fin: GTA 6 saldrá a la venta el 19 de noviembre.

Con el lanzamiento de un videojuego de gran éxito, la gente lleva mucho tiempo acostumbrada a medir el tiempo en "años". El equipo de desarrollo tiene que construir ciudades y niveles, diseñar las reglas de combate y asegurarse de que los personajes, las armas, la física y los gráficos funcionen correctamente cada vez que el jugador pulsa un botón.

Por otro lado, casi cada vez que se lanza un nuevo modelo de IA, aparece rápidamente en internet una gran cantidad de juegos, a una velocidad comparable a la de los nuevos lanzamientos en Steam.

Cuando se lanzó Claude Opus 5.5, Anthropic mostró específicamente los resultados de diferentes modelos que creaban juegos basados ​​en la misma consigna, afirmando que Opus 5.5 obtuvo la puntuación más alta en términos de gráficos y completitud. OpenAI presentó las capacidades de computación de GPT-6 Astra, destacando también el desarrollo de juegos en sus demostraciones; un desarrollador lo utilizó para crear una experiencia interactiva del Londres histórico.

Tras el lanzamiento de Kimi K3.1 Pro, la comunidad comparó su tiempo de creación, precio y resultados finales con los de Claude , GPT y DeepSeek en la creación de juegos de disparos en primera persona, agricultura, carreras y laberintos. El recién lanzado Genie 4 se describe oficialmente como un "mundo interactivo", una "simulación en tiempo real" y un "prototipo explorable", pero tras un análisis más detallado, sigue pareciendo un videojuego.

El enfoque tradicional tras el lanzamiento de un modelo es realizar pruebas de rendimiento; ahora, cada vez más empresas optan por utilizarlo para crear un videojuego. No se trata, por supuesto, del próximo *Shadow Blade Zero* o *GTA 6*. Pero lo interesante es que, cuando las empresas de IA necesitan demostrar las fortalezas de un nuevo modelo, ¿por qué prefieren cada vez más que este modelo sea el primero en crear un videojuego?

¿Cómo un pájaro tan peculiar se convirtió en un modelo de prueba?

El 28 de octubre, el desarrollador independiente Simon Willison hizo una predicción sobre este cambio: en noviembre de 2025, Code Agent cruzará el umbral de "convertirse en una herramienta diaria para programadores"; y en octubre de 2026, el modelo cruzará otro umbral en el desarrollo de videojuegos.

Este método de presentación tiene un sencillo predecesor.

En 2024, Simon Willison comenzó a probar diferentes modelos con la misma consigna: "Genera un SVG de un pelícano montando en bicicleta", y los modelos tenían que escribir directamente el código SVG que constituye la imagen, no solo proporcionar una fotografía.

La tarea suena casi a broma: ¿de dónde salió este extraño pájaro, el pelícano? Pero en la práctica no es fácil: una bicicleta necesita dos ruedas alineadas, un cuadro conectado, manillar y pedales; el pelícano no solo debe dibujarse, sino que también debe sentarse en el sillín, con las patas cerca de los pedales y el cuerpo en la proporción adecuada con la bicicleta. Si al código le falta una sola etiqueta, la imagen podría no renderizarse; una ligera desalineación en las coordenadas hará que el pelícano quede fuera de la bicicleta, con las ruedas y el cuadro como elementos independientes.

Los primeros modelos solían mostrar solo dos círculos, un triángulo y un pájaro apenas reconocible. Para 2026, los nuevos modelos añadieron plumas, picos largos, estribos y cadenas a los pelícanos, e incluso incorporaron cestas de pescado, sombreros y elementos de escenografía que cambiaban con sus movimientos. Esto dio como resultado una variedad de pelícanos que aparecen en el blog de Simon.

La "Prueba del Pelícano" no es una evaluación comparativa rigurosa; se ejecuta solo una vez, carece de un control estandarizado sobre la velocidad, el costo y las herramientas de inferencia, y no puede demostrar qué modelo tiene el mejor rendimiento general . Su popularidad radica en que no requiere explicación. Es evidente de inmediato si las relaciones espaciales son razonables y si el código se ha traducido correctamente a una imagen.

El juego sigue la misma lógica, solo que transforma el SVG estático en un sistema fácil de usar. Si el juego Pelican probaba si el modelo podía organizar un conjunto de código en un flujo visual coherente, este juego prueba si el marco y los componentes diseñados por el modelo pueden seguir funcionando después de la interacción del usuario.

¿Cuántas habilidades ocultas hay en el juego?

Tomemos como ejemplo el popular juego de disparos en primera persona (FPS) de una sola palabra: el jugador se mueve con un arma, los enemigos se acercan desde la distancia y, tras disparar, se recibe una confirmación de impacto. Después de derrotar a una oleada de enemigos, el jugador pasa al siguiente nivel.

Lo que parece ser tan solo diez segundos de funcionamiento, en realidad implica la construcción simultánea de muchas partes interdependientes: primero, debe crear una escena 3D y una cámara en primera persona, permitiendo que el ratón controle la vista y el teclado el movimiento; también debe generar armas, enemigos y obstáculos, y gestionar las distancias y oclusiones entre ellos. Tras disparar, el programa debe calcular la trayectoria del rayo o la bala, determinar si impacta en la zona de colisión del enemigo, restar puntos de salud, reproducir animaciones y actualizar la puntuación. Los enemigos también deben saber cómo encontrar al jugador, y el sistema de niveles debe decidir cuándo y dónde aparecerá la siguiente oleada.

Aunque estas características estén escritas correctamente de forma individual, el juego podría seguir siendo injugable: si la rotación de la cámara y la dirección del personaje no están sincronizadas, el jugador se deslizará lateralmente; si las balas impactan en el modelo pero no provocan colisiones, el arma solo será una decoración brillante; si los enemigos, las puntuaciones y los niveles funcionan de forma independiente pero no comparten el mismo conjunto de estados, el juego no puede formar un bucle.

Por lo tanto, un juego sencillo comprueba simultáneamente la generación de código, la comprensión espacial, el diseño visual, la gestión de estados, las reglas físicas, la retroalimentación interactiva y la corrección de errores. Además, requiere que el modelo complete esa última tarea, a menudo pasada por alto por los agentes: conectar las distintas funcionalidades para ofrecer un producto final con el que el usuario pueda interactuar.

Es precisamente aquí donde los videojuegos son más adecuados para demostrar las capacidades de modelado que simplemente "crear una página de inicio de sesión". Una página web puede usar una buena captura de pantalla para ocultar un botón defectuoso, pero un videojuego expondrá los problemas en el momento en que el jugador se mueva, dispare o choque contra una pared. Que el código funcione es solo el primer obstáculo; que la interacción del usuario modifique el entorno y que este responda con rapidez determina si se trata realmente de un videojuego.

¿Por qué juegos de navegador?

La mayoría de los juegos de las nuevas demostraciones no son clientes completos que requieran instalación, sino creaciones basadas en navegador desarrolladas con HTML, JavaScript, Three.js o Phaser.

Este tipo de juegos son especialmente fáciles de usar para los modelos. En internet abundan las bibliotecas de interfaz, el código de tutoriales y las mecánicas de juego comunes, y los modelos están familiarizados con su uso. Los navegadores también cuentan con capacidades integradas de gráficos, sonido, entrada y conexión en red, por lo que un único código base puede albergar tanto los gráficos como la jugabilidad. Una vez terminado el juego, basta con subir una página web estática y otros usuarios podrán ejecutarlo haciendo clic en el enlace, sin necesidad de configurar un motor ni descargar archivos.

El juego en sí proporciona un lenguaje muy sofisticado, válido tanto para el modelo como para el usuario. Al observar una perspectiva en primera persona, el modelo sabe que el ratón suele controlar la dirección; al ver un juego de carreras, puede invocar la aceleración, las colisiones, la sincronización y los puntos de control; al ver un juego de defensa de torres, puede organizar el sistema a partir del alcance, el tiempo de recarga, los recursos y las oleadas. No tiene que inventar "qué es un juego" desde cero, sino que simplemente recompone la gran cantidad de convenciones acumuladas a partir de los datos de entrenamiento.

Esto convierte al juego en un modelo muy eficiente para mostrar: técnicamente complejo, pero de fácil difusión. Decenas de miles de líneas de código se integran finalmente en un vídeo de un personaje corriendo, un vehículo girando o una bala impactando. Los espectadores no necesitan entender el código para juzgar si los gráficos tienen fallos o si los controles son fluidos.

Sin embargo, esta ventaja también embellece el modelo. La mecánica de juego familiar cuenta con una gran cantidad de paradigmas predefinidos, y los prototipos para navegador no tienen que lidiar con sistemas de cuentas, multijugador simultáneo, hardware diferente, actualizaciones de versión ni años de mantenimiento. Crear un juego de disparos funcional basado en un modelo sigue siendo un trabajo distinto al de desarrollar un juego comercial real por parte de un equipo.

De "como un juego" a "realmente divertido"

Los cambios recientes no se limitan a que los modelos tengan mejores capacidades de programación. Simon Willison cree que Claude Opus 5.5 está empezando a mostrar algunas capacidades de diseño de juegos de las que carecían los modelos anteriores.

Utilizando la interfaz de chat estándar Claude y una sola indicación, creó "Apreciador de árboles". La pantalla genera dos árboles 3D ligeramente diferentes uno al lado del otro, y los jugadores pueden rotar y hacer zoom en la escena para encontrar diferencias sutiles como pájaros, ardillas u hojas; una vez completado, el árbol se agrega a una colección virtual de especímenes.

Desde el punto de vista de la programación, sigue siendo un juego muy sencillo de "encuentra las diferencias". Lo que realmente sorprendió a Willison fue que el modelo en sí mismo ofrecía una experiencia sutil pero completa: cómo indicarle al jugador el objetivo, cómo aumentar gradualmente la dificultad y cómo usar la recolección de especímenes para motivarlo a seguir jugando, organizando así una sensación de inicio, retroalimentación y finalización.

Otro proyecto, *Battle Drones*, ilustra la diferencia aún más claramente. Las primeras versiones, creadas por Claude Fable 5, ya incluían recolección de recursos y combate similares a *Command & Conquer*, pero a Willison no le resultaron interesantes. Simplemente le pidió a Opus 5.5 que lo hiciera "mucho más divertido" y, posteriormente, migró el juego a Three.js. Ahora, ofrece batallas de dos a cuatro jugadores, siete mapas, medallas, repeticiones, mapas aleatorios y un modificador que puede cambiar las reglas.

La concepción de "diversión" de un modelo puede no coincidir con la de una persona, e incluso distintos jugadores pueden tener diferentes interpretaciones de la palabra. El modelo identifica principalmente la densidad de retroalimentación típica, el ritmo de progresión y los cambios situacionales necesarios para un juego de estrategia en tiempo real, y luego combina estas convenciones. Sin embargo, desde la perspectiva de la demostración, los criterios de evaluación han cambiado: antes, bastaba con poder crear un juego. Ahora, debe ser jugable.

Sin embargo, la idea de "crear un juego con una sola instrucción" puede generar fácilmente la ilusión de que el modelo representa años de desarrollo por parte de una compañía de videojuegos en tan solo unos minutos. En realidad, solo se puede vislumbrar una pequeña parte de lo que sucede en el video de demostración.

El juego de ciudad en 3D "Neon Palms", creado por Claude Opus 5.5, surgió originalmente de una prueba de rendimiento del juego. En el video, los jugadores pueden conducir y explorar la ciudad de neón; todas las imágenes provienen del programa en ejecución, no de un video generado.

Sin embargo, no fue un resultado instantáneo. El proyecto se desarrolló del 26 al 28 de septiembre, con el Agente trabajando en once rondas, ejecutándose un total de 69 veces, con un máximo de seis Agentes funcionando en paralelo. Según los registros públicos disponibles, el modelo procesó aproximadamente 4070 millones de tokens, la gran mayoría de los cuales eran contextos en caché, generando aproximadamente 3,2 millones de tokens. Basándonos en el precio de la API, el coste de desarrollo se estimó en aproximadamente 1512 dólares. El vídeo de demostración también utilizó una versión posterior con pequeñas correcciones visuales y un modo de visualización específico; la prueba de rendimiento aún registra numerosos errores.

En términos absolutos, esto es bastante sorprendente: se puede completar una ciudad 3D funcional en tan solo unos días a un costo relativamente bajo. Sin embargo, es importante recordar que un video de demostración fluido solo muestra los resultados; no muestra la duración de las indicaciones, la cantidad de reintentos, los agentes paralelos, la selección manual ni las versiones rechazadas.

La prueba GameCraft-Bench, más sistemática, arrojó conclusiones similares. Requirió que el agente de código completara 140 tareas jugables en Godot basadas en lenguaje natural. La evaluación no solo verificó el código, sino que también ejecutó el programa, reprodujo las acciones y observó el rendimiento del juego. En el momento de la publicación del artículo, la tasa de finalización general del agente más potente era de tan solo el 41,46 %. El modelo destacó por crear prototipos impresionantes con rapidez, pero aún no podía cumplir de forma consistente con todas las reglas, la retroalimentación y los requisitos visuales.

La mejor manera para que las modelos "presuman de sus músculos"

En la segunda mitad de la intensa competencia en el campo del modelado, cada nueva versión debe considerar cómo proporcionar una demostración que el público general pueda comprender. La evaluación comparativa y la resolución de problemas ya no son suficientemente intuitivas, y las tareas de programación son complejas; resulta difícil condensar cientos de miles de líneas de código en un material fácilmente comprensible y de fácil difusión.

Los juegos, sin embargo, poseen inherentemente elementos visuales, animaciones, sonidos y resultados; son a la vez programas y productos. Permiten a los usuarios comprobar si el código se está ejecutando y también posibilitan que los espectadores lo depuren por sí mismos. Cada componente generado por el modelo debe seguir interactuando con los demás componentes después de que el jugador pulse un botón.

De esta forma, los videojuegos se han convertido en un escenario más intensivo e intuitivo para demostrar capacidades que las páginas web y los proyectos de programación convencionales. El hecho de que nuevos modelos comiencen a "crear videojuegos" no significa que dominen por completo la industria, ni que los fabricantes de modelos siquiera piensen así.

Es más bien como una ceremonia de lanzamiento de un nuevo producto. A medida que las capacidades de un modelo se vuelven cada vez más difíciles de demostrar y explicar, es mejor entregar un producto terminado que se pueda ver, manipular y difundir; ¿qué otra cosa podría ser sino un juego?