💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

Este artículo presenta GameCraft-Bench, un banco de pruebas de 140 tareas basadas en Godot diseñado para evaluar la capacidad de los agentes de codificación para generar juegos completos y jugables de extremo a extremo, revelando que los modelos de frontera actuales luchan significativamente por lograr la completitud del artefacto y la coherencia interactiva a pesar de implementar mecánicas reconocibles.

Autores originales: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

Publicado 2026-06-17

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que contratas a un robot chef y le das la receta para una cena compleja de varios tiempos. No quieres que el robot simplemente escriba la receta en un papel; quieres que realmente cocine la comida, la sirva en el plato y la presente para que puedas darle un bocado y probarla.

Eso es esencialmente de lo que trata este artículo, GameCraft-Bench. Es una prueba para ver si los agentes de codificación de IA pueden realmente "cocinar" un videojuego jugable desde cero, en lugar de solo escribir el código de uno.

Aquí tienes un desgón de las ideas principales del artículo utilizando analogías sencillas:

1. El problema: "La receta vs. El plato terminado"

En el pasado, cuando probábamos a la IA en la codificación, la mayoría de las veces comprobábamos si el código parecía correcto sobre el papel (como verificar si los ingredientes de la receta estaban listados correctamente). Pero para los videojuegos, mirar el código no es suficiente. Un juego necesita ejecutarse, los gráficos deben aparecer y el jugador debe poder mover a un personaje y ver qué sucede.

Los autores argumentan que para probar verdaderamente la capacidad de una IA para crear un juego, necesitamos tres cosas:

La cocina real (Anclaje al motor/Engine Grounding): La IA debe trabajar en un motor de juego real (utilizaron Godot, una herramienta popular y gratuita), no en una versión falsa o simplificada. Es como pedirle al chef que use una estufa real, no una de juguete.
El plato completo (Integridad de los artefactos/Artifact Completeness): La IA no puede darte simplemente un ingrediente (como un script para que un personaje salte). Debe entregar el juego completo y empaquetado, listo para lanzarse. Sin piezas faltantes.
La prueba del sabor (Verificación interactiva/Interactive Verification): No puedes limitarte a mirar el plato terminado; tienes que comerlo. El juego debe jugarse. El éxito de la IA se juzga ejecutando el juego, presionando botones y viendo si el mundo reacciona correctamente.

2. La prueba: GameCraft-Bench

Los investigadores construyeron una gran cocina de pruebas llamada GameCraft-Bench.

El menú: Crearon 140 desafíos diferentes repartidos en 15 tipos de juegos (como plataformas, juegos de carreras, juegos de estrategia y juegos de terror).
El proceso:
1. Se le da a la IA una descripción en lenguaje natural (por ejemplo, "Haz un juego de plataformas en 2D donde recolectes monedas y evites enemigos").
2. La IA construye el juego en el motor Godot.
3. La IA también tiene que grabar un "trazo de demo" (demo trace)—un guion de video que muestra exactamente cómo jugar al juego para demostrar que funciona.
4. Un sistema informático "juega" al juego usando ese guion, graba el video y luego un juez de IA inteligente observa el video para calificarlo.

3. Los resultados: "Bueno escribiendo, malo cocinando"

Los resultados fueron sorprendentes y un poco humillantes para la comunidad de la IA. Incluso los modelos de IA más inteligentes y avanzados (como Opus-4.7 y GPT-5.5) tuvieron dificultades.

La puntuación: La mejor IA solo obtuvo alrededor de un 41% en la prueba. La mayoría puntuó por debajo del 40%.
En qué fueron buenos: Las IA fueron decentes construyendo el "bucle central" (core loop). Si pedías un juego donde un personaje salta, el personaje normalmente podía saltar. Podían construir las partes del motor.
En qué fallaron: Tuvieron dificultades para unir todo en una experiencia completa.
- Contenido faltante: A menudo creaban un juego que era demasiado corto o que no tenía niveles para progresar.
- Visuales rotos: Los gráficos podían estar ahí, pero no tenían sentido (por ejemplo, el jugador no puede ver al enemigo o la interfaz de usuario está rota).
- La brecha de la "demo": Muchas IA construyeron un juego pero olvidaron grabar el "trazo de demo" requerido para demostrar que funcionaba. Es como si el chef cocinara la comida pero olvidara servirla en el plato para el juez.

4. Descubrimientos clave (El "¿Por qué?")

El artículo investigó por qué fallaron las IA:

Ver es creer: Las IA que mejor lo hicieron fueron aquellas que miraban la pantalla del juego mientras lo construían. Trataban la salida visual como una herramienta de depuración. Si el personaje se veía raro, corregían el código. Las IA que solo escribían código sin mirar la pantalla cometían más errores.
Estar ocupado no es mejor: Un modelo de IA (MiMo) escribió mucho código y ejecutó muchos comandos, pero no obtuvo una puntuación más alta. Era como un chef picando verduras furiosamente pero sin llegar a cocinar realmente el plato. Hacer más trabajo no garantiza un mejor resultado si se omite el paso final.
Diferentes habilidades: Hacer que la mecánica de "salto" funcione (Mecánicas) es diferente de hacer que el juego se vea bonito (Arte) o de tener suficientes niveles (Contenido). Una IA puede ser buena en una cosa pero mala en las otras. No están todas vinculadas entre sí.

5. La conclusión

El artículo concluye que, si bien la IA se está volviendo muy buena escribiendo código, la creación de juegos de extremo a extremo (end-to-end) sigue siendo un desafío masivo.

Las IA actuales pueden construir "fragmentos" de juegos o prototipos simples, pero aún no pueden tomar de manera fiable una idea creativa de un humano y convertirla en un paquete de juego pulido, jugable y completo por sí solas. La brecha entre "escribir código que parece correcto" y "entregar un sistema que funciona" sigue siendo muy amplia.

En resumen: La IA puede escribir la receta, pero todavía está aprendiendo a cocinar el plato completo y servirlo al cliente.

Resumen Técnico: GameCraft-Bench

Definición del Problema

El artículo aborda el desafío de la generación de juegos de extremo a extremo (end-to-end), definida como el proceso en el que un agente autónomo transforma una especificación de juego en lenguaje natural ( $s$ ) en un sistema interactivo jugable ( $G$ ) dentro de un entorno de desarrollo y ejecución específico ( $E$ ). A diferencia de las tareas de codificación tradicionales donde el éxito se mide por la correza del código o las pruebas unitarias, la generación de juegos requiere la producción de un artefacto coherente y lanzable que responda a las entradas del jugador en tiempo real.

Los autores argumentan que los métodos de evaluación existentes no logran capturar la complejidad total de esta tarea. Los benchmarks actuales suelen centrarse en:

Juegos basados en la web que carecen de la complejidad de los entornos de motores reales.
Ediciones localizadas de proyectos existentes en lugar de una construcción completa.
Inspección estática de código o activos, lo que no logra verificar el comportamiento real del juego.

Para abordar esto, el artículo formaliza la generación de juegos de extremo a extremo como un mapeo $(s, E) \mapsto G$ e identifica tres desiderata críticos para un benchmark válido:

Anclaje al Motor (Engine Grounding): El desarrollo debe ocurrir dentro de un motor de juego real con su documentación nativa, activos y restricciones de tiempo de ejecución.
Completitud del Artefacto: El agente debe entregar un proyecto de juego completo y lanzable (incluyendo metadatos, escenas, scripts y activos), no solo código parcial o prototipos.
Verificación Interactiva: La evaluación debe basarse en las interacciones observadas del juego (acciones del jugador y respuestas del sistema) en lugar de la inspección estática del código.

Metodología: GameCraft-Bench

Los autores instancian estos desiderata en GameCraft-Bench, un benchmark diseñado para evaluar agentes de codificación en el motor Godot 4.

1. Suite de Tareas

Escala: 140 tareas a través de 15 familias de juegos distintas (p. ej., Plataformas, Estrategia, Roguelike, Novela Visual, Tycoon).
Estructura de la Tarea: Cada tarea $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ consiste en:
- $s$ : Una especificación en lenguaje natural que describe la fantasía del jugador, el bucle central (core loop) y las mecánicas.
- $E$ : Un entorno basado en Godot que proporciona un espacio de trabajo, herramientas y activos compartidos.
- $\rho$ : Una rúbrica de evaluación oculta utilizada por el verificador.

2. Pipeline de Evaluación

El benchmark emplea un pipeline de cinco etapas (Figura 5):

Empaquetado de Tarea: Los agentes reciben la especificación y el entorno.
Generación del Agente: El agente produce un proyecto de Godot completo ( $G$ ) y un conjunto de trazas de interacción reproducibles ( $\Pi$ ) que contienen eventos de teclado/ratón temporizados.
Puerta de Construcción (Build Gate): El verificador intenta lanzar el proyecto. Si la construcción falla o las trazas son imposibles de procesar, la puntuación es cero.
Reproducción (Replay): El verificador reproduce las trazas en una instancia de Godot sin interfaz gráfica (headless), grabando videos de la jugabilidad y muestreando fotogramas (2 FPS).
Calificación: Un juez multimodal califica la evidencia de la jugabilidad frente a la rúbrica oculta en cuatro categorías:
- Mecánicas Centrales (M): Reglas, transiciones de estado y objetivos.
- Profundidad de Contenido (D): Progresión, variedad y alcance en tiempo de ejecución.
- Visuales Funcionales (V): Legibilidad, retroalimentación y estabilidad de la interfaz de usuario.
- Arte y Presentación (A): Coherencia estética y sensación de ser "autoría".
- Fórmula de Puntuación Final: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , con pesos que priorizan la Profundidad de Contenido y la Presentación.

3. Selección del Motor

Se seleccionó Godot por su naturaleza de código abierto, configuración ligera, flujo de trabajo nativo en 2D, archivos de escena basados en texto y capacidades de ejecución por línea de comandos/headless, las cuales son esenciales para una evaluación automatizada reproducible.

Resultados Clave

Los autores evaluaron siete configuraciones de agentes de codificación de frontera (incluyendo Claude Code, Codex, Kimi Code y Code Buddy) en el benchmark completo.

Rendimiento General: La generación de juegos de extremo a extremo sigue estando altamente sin resolver. El agente más fuerte (Claude Code con Opus-4.7) logró una puntuación general del 41.46%. La mayoría de los otros agentes puntuaron por debajo del 40%, con algunos (p. ej., DeepSeek-V4-Pro) puntuando tan bajo como 2.15%.
Desglose por Categoría:
- Mecánicas: Los agentes se desempeñaron relativamente mejor aquí (p. ej., Opus-4.7 puntuó 55.34%), creando a menudo bucles de interacción local reconocibles.
- Contenido y Presentación: Las puntuaciones disminuyeron significativamente para la Profundidad de Contenido y el Arte/Presentación, lo que indica que los agentes tienen dificultades para ensamblar mecánicas en sistemas completos, pulidos y coherentes.
Ejecución vs. Jugabilidad: Aunque muchos agentes lograron altas "Tasas de Paso de Construcción" (lanzar el juego), frecuentemente fallaron al proporcionar trazas de reproducción válidas o fallaron en realizar la jugabilidad pretendida dentro de las trazas, lo que llevó a puntuaciones finales bajas.

Hallazgos Diagnósticos

La Retroalimentación Visual es Crítica: Los agentes que utilizaron inspecciones de pantalla renderizadas (p. ej., Kimi-K2.6) mostraron mejores capacidades de depuración, corrigiendo problemas como interfaces de usuario desalineadas o diseños de niveles rotos que eran invisibles solo en el código fuente.
Uso de Herramientas $\neq$ Calidad: Altos volúmenes de llamadas a herramientas (particularmente comandos de shell) no se correlacionaron con puntuaciones más altas. El éxito dependió de cerrar el ciclo entre la construcción, la provisión de trazas de demostración y asegurar la jugabilidad.
Factorización Parcial: El rendimiento en mecánicas, contenido y visuales solo tuvo una correlación moderada. Un agente podía producir un juego mecánicamente funcional que carecía de profundidad de contenido o pulido visual.

Significado y Reivindicaciones

El artículo afirma que GameCraft-Bench establece un nuevo estándar para evaluar agentes de software creativos al desplazar el enfoque de la corrección del código hacia la corrección del sistema interactivo.

Contrato de Benchmark: Define un contrato de benchmark que requiere que los agentes operen en un motor real, entreguen artefactos completos y sean juzgados mediante la interacción.
Limitaciones Actuales: Los resultados demuestran que los agentes de frontera actuales son capaces de generar "fragmentos" de software de tipo juego, pero aún no pueden transformar de manera confiable las especificaciones de lenguaje natural en experiencias de juego completas, coherentes y visualmente consistentes.
Paradigma de Evaluación: El trabajo argumenta que evaluar sistemas creativos ejecutables requiere una evaluación basada en la interacción (jugabilidad) que vaya más allá de la inspección estática del código, el éxito de la construcción o la plausibilidad visual por sí sola.

Los autores enfatizan que, si bien el benchmark está actualmente limitado a juegos 2D de Godot y evaluación visual (excluyendo audio), proporciona un marco riguroso para diagnosticar las brechas específicas en la capacidad de los agentes actuales para construir sistemas interactivos complejos.