Ocho agentes de VibeGame crean un juego 2D a partir de un prompt y superan a sus rivales en GameCraft-Bench

Los equipos del laboratorio PRLab de la Universidad de Nankín y del S-Lab de la Universidad Tecnológica de Nanyang han publicado VibeGame, un framework que, a partir de una descripción en texto y de imágenes de referencia opcionales, crea un proyecto de juego 2D completo: con código, escenas, animación, física y configuración. Por dentro trabaja un equipo de ocho agentes especializados, y el propio proyecto se almacena como archivos de texto que el agente puede leer y editar sin un editor gráfico. En un subconjunto de GameCraft-Bench, en el modo en que el sistema dibuja él mismo los gráficos, superó a otros harnesses de agentes con el mismo modelo base, incluido GPT-6.1-Sol.

Por qué los juegos son más difíciles que el código convencional

Los autores parten de que un juego es uno de los tipos de software más exigentes. Tiene que mantener un mundo interactivo en tiempo real, conservar un estilo visual coherente y respetar reglas equilibradas. Muchos errores solo aparecen durante la partida: la entrada del jugador, la física, la animación y la lógica de interacción se combinan de tal modo que un proyecto formalmente correcto se rompe sobre la marcha.

Según los autores, los enfoques existentes resuelven la tarea solo en parte. Los modelos de mundo como Genie generan experiencias interactivas a partir de vídeo, pero no ofrecen código fuente editable. Los LLM integrados en motores comerciales, como DreamGarden para Unreal, chocan con un estado del proyecto repartido entre interfaces gráficas y archivos binarios. Y muchos sistemas de agentes comprueban el juego solo al final, o se limitan a verificar que compila y se ejecuta.

Un motor pensado para que los agentes lo lean

Como base se tomó el framework web Phaser, en el que los proyectos se expresan por completo en texto. Para que los agentes no generen caos, los autores añadieron estructura. El juego es un conjunto de escenas con configuración en archivos JSON con comprobación de tipos. Cada escena es una jerarquía de nodos, y cada nodo reúne apariencia, geometría de colisiones, scripts de comportamiento y ajustes. Los nodos comunes se guardan en archivos aparte. El esquema detecta referencias rotas, por ejemplo a un asset inexistente, antes de la ejecución.

La segunda propiedad es el control fotograma a fotograma. El agente puede pausar el juego, avanzarlo un número determinado de fotogramas, leer o modificar la posición y la velocidad de los nodos, enviar una orden semántica como «pulsar salto» y hacer una captura de pantalla. Así, la verificación avanza al ritmo del agente y no en tiempo real: fotograma a fotograma, con scripts o con bots. La tercera: el código fuente completo y sin comprimir del motor se coloca en el directorio del proyecto, para que el agente consulte las API exactas y no documentación obsoleta.

Un equipo que discute consigo mismo

Los roles se reparten así: orquestador, diseñador, artista, arquitecto, programador, auditor, jugador y revisor. El diseñador convierte una petición como «una pelea de jefe al estilo de Hollow Knight» en un documento de diseño con mecánicas, progresión y sistemas numéricos. El artista, mediante modelos de generación de imágenes, entre ellos GPT-Image-2, crea el concept art y los assets, elimina el fondo y normaliza los tamaños. Cuando el usuario lo confirma, el documento y el concept pasan a ser la referencia común.

El código pasa por una cadena formada por el arquitecto, el programador, el auditor y el jugador. El auditor revisa estáticamente el resultado con herramientas de consistencia del motor. El jugador ejecuta el juego a través de la interfaz de runtime y, con un modelo de visión, evalúa si la imagen coincide con lo planteado. Una subtarea se considera terminada solo después de ambas comprobaciones. Al final, un revisor independiente evalúa el proyecto por el comportamiento del juego, la completitud visual y la coherencia, así como por la sensación de control. Si algo no pasa la revisión, devuelve el proyecto con los motivos, y el orquestador los convierte en tareas de mejora.

Autoevolución sin entrenamiento

Tras aceptar un proyecto, el sistema extrae de él experiencia reutilizable de tres tipos: esqueletos, módulos y contratos de interacción. Un esqueleto es una plantilla ejecutable de proyecto para un género: sin assets, pero con la arquitectura del código, los valores ajustados y el flujo de escenas. Los proyectos nuevos adaptan y vuelven a verificar este material, en lugar de copiarlo a ciegas. Lo no verificado y lo específico de cada proyecto queda aislado. Los pesos del modelo no cambian en ningún momento.

Las ablaciones muestran que eliminar el motor AI-nativo o los revisores adversariales reduce de forma notable la puntuación global. La experiencia extraída por un modelo más potente ayuda a mejorar el resultado de uno más débil.

Qué conviene tener en cuenta

La evaluación se hace sobre un subconjunto de GameCraft-Bench, en cuatro ejes: mecánicas básicas, profundidad de contenido, parte visual funcional y presentación artística. El resultado es una puntuación ponderada que figura en el apéndice del artículo. El texto disponible no incluye valores concretos, por lo que no se puede comprobar la magnitud de la ventaja sobre los competidores.

La comparación con otros harnesses la han realizado los propios autores. El framework se limita a 2D y depende de Phaser. Para los desarrolladores, la conclusión es práctica: la representación del proyecto en texto, el control del runtime fotograma a fotograma y el papel de un revisor independiente son técnicas que se pueden trasladar a otros pipelines de agentes.

El código y la demo están publicados en el sitio del proyecto y en un repositorio de GitHub.