Resumen Técnico: Síntesis de Escenas de Juegos Unity Ejecutables mediante LLM de Pasada Única Condicionada por Conocimiento

Declaración del Problema

Las demostraciones actuales de Modelos de Lenguaje Extensos (LLM) que generan scripts de C# para Unity dependen en gran medida de bucles de reparación iterativos, donde los modelos regeneran el código hasta que este compila. Este flujo de trabajo confunde el conocimiento paramétrico intrínseco del modelo con el poder correctivo del bucle de reparación o la intervención humana. Además, las evaluaciones existentes suelen utilizar etiquetas de género inestables o lenguaje natural libre, lo que carece de la reproducibilidad requerida para la investigación acumulativa.

Este artículo aborda la siguiente pregunta: ¿Cuál es el techo de capacidad intrínseca de la generación de artefactos de juego ejecutables mediante LLM de pasada única cuando no se permite la retroalimentación humana ni la reparación iterativa? El estudio aisla el conocimiento almacenado del modelo del conocimiento experto del profesional, tratando al compilador como un filtro estricto y objetivo. Si un script no compila en la primera pasada, es un fallo atribuible únicamente al modelo.

Metodología

Diseño Experimental

El estudio evalúa la generación de Conceptos Jugables de Objetivo (GPC, por sus siglas en inglés): contrapartes jugables de 26 patrones de diseño de juego específicos definidos por Björk y Holopainen. Estos patrones sirven como un vocabulario teóricamente fundamentado y reproducible para el diseño de juegos, reemplazando las etiquetas de género inestables.

• Escala: 10,400 registros de generación.
• Modelos: Cuatro modelos de pesos abiertos de diferentes familias (7B-Qwen2.5, 16B-DeepSeek, 22B-Codestral, 30B-Qwen3).
• Modos de Generación:
  • Estilo Editor: Scripts que construyen escenas en el tiempo de edición utilizando APIs de UnityEditor.
  • Constructor de Tiempo de Ejecución (Runtime-builder): Scripts que construyen escenas programáticamente durante el tiempo de ejecución utilizando MonoBehaviour (probado solo en el modelo 30B).
• Niveles de Condicionamiento: Cuatro niveles de condicionamiento de Representación Intermedia (IR):
  • Sin Esquema: Generación directa a partir de la descripción del patrón.
  • Con Esquema (Libre/Mínimo/Completo): Generación de un IR en formato JSON primero, seguido de la generación de código C#. La rigidez del esquema varía desde nombres de campos de alto nivel hasta definiciones de campos completos y restricciones.
• Procedimiento: Cada registro es una única pasada de generación. El script C# generado se compila dentro de un proyecto Unity preconstruido. No se le devuelve información de errores de compilación al modelo.

Construcción de la Taxonomía de Fallos

Los autores categorizan los 99 códigos distintos de errores de compilación de C# observados en 90,673 ocurrencias de errores en dos clases mutuamente excluyentes:

1. Errores de Fundamentación (Grounding Errors) (18 códigos): Fallos específicos del dominio que requieren conocimiento del motor Unity para ser resueltos. Implican tipos, espacios de nombres y APIs de Unity inventados o mal utilizados (ej. CS0246: tipo o espacio de nombres no encontrado; CS1061: no existe tal miembro).
2. Errores de Higiene (Hygiene Errors) (81 códigos): Defectos estructurales independientes del dominio diagnosticables sin conocimiento de Unity. Incluyen errores sintácticos como la falta de puntos y coma, llaves sin cerrar y variables no declaradas (ej. CS1003, CS1002).

Resultados Clave

1. Fallo de Compilación Universal

Ningún script de C# generado compiló en una escena ejecutable en ninguno de los 10,400 registros. Este fallo uniforme elimina el sesgo de supervivencia, permitiendo un censo exhaustivo de los modos de fallo.

2. Composición de Errores y Comportamiento del Modelo

• Distribución de Fundamentación vs. Higiene: La división entre errores de Fundamentación e Higiene varía significamente según el patrón de objetivo y la configuración del modelo.
  • Patrones de Alta Fundamentación: Los conceptos vinculados a las APIs de percepción y física de Unity (ej. Sigilo, Rescate, Exploración, Supervivencia) fallan predominantemente con errores de Fundamentación. El modelo inventa componentes de motor inexistentes (ej. GuardAI, Pathfinding) para satisfacer la semántica del diseño.
  • Patrones de Alta Higiene: Los conceptos reducibles a la manipulación de estado general (ej. Captura, Recolección) fallan predominantemente con errores de Higiene. Los scripts generados colapsan estructuralmente (errores de sintaxis) antes de alcanzar la capa donde se prueba el conocimiento de Unity.
• Escala e Identidad del Modelo: El aumento del tamaño del modelo (de 7B a 30B) no produce una escena ejecutable. En su lugar, desplaza la composición del fallo. Los modelos más grandes (como 30B-Qwen3-Ed) llegan al compilador con más frecuencia y fallan en la capa de Fundamentación (falta de conocimiento de la API), mientras que los modelos más pequeños a menudo fallan en el filtro de formato (rechazo del sanitizador) o en la capa de Higiene (sintaxis).
• Efectos del Condicionamiento de la IR: Un condicionamiento de esquema más estricto no resuelve los fallos, sino que los relocaliza.
  • Para los modelos más pequeños (7B, 16B), los esquemas estrictos aumentan las tasas de rechazo del sanitizador (hasta el 89%), impidiendo que el código llegue al compilador.
  • Para los modelos más grandes (22B, 30B-Ed), los esquemas más estrictos mejoran el cumplimiento del formato, permitiendo que más registros lleguen al compilador. Sin embargo, esto desplaza el perfil de error hacia los errores de Fundamentación, ya que el modelo se ve obligado a producir código sintácticamente válido que aún carece de referencias correctas al motor.
• Modo de Generación: Cambiar del modo Estilo Editor al modo Constructor de Tiempo de Ejecución (probado en 30B) redistribuye los errores pero no elimina los fallos de Fundamentación. En algunos casos (ej. Recolección), el modo de Tiempo de Ejecución introdujo picos severos de Higiene sin mejorar el éxito de la compilación.

3. Perfiles de Error por Patrón

El estudio establece un orden empírico de los 26 patrones de objetivo basado en el conocimiento del motor que su instanciación demanda.

• Sigilo (Stealth) (cuota de Fundamentación ~0.98 en algunas configuraciones) falla principalmente porque el modelo inventa tipos específicos del motor para la visión y detección que no existen.
• Captura (Capture) (cuota de Fundamentación ~0.0 en algunas configuraciones) falla principalmente debido a errores sintácticos estructurales, ya que la lógica puede expresarse en C# puro sin APIs específicas del motor.

Significado y Reivindicaciones

El artículo afirma proporcionar el primer censo sistemático de los modos de fallo de los LLM en la generación de código acoplado a un motor, con la granularidad de errores de compilación individuales. Sus principales contribuciones son:

1. Una Taxonomía de Fundamentación/Higiene: Una distinción formal entre errores de dominio específico (conocimiento del motor) y de dominio independiente (estructurales), derivada de 90,673 diagnósticos de compilación observados.
2. Una Lente de Complejidad de Diseño Basada en Errores: El estudio demuestra que la complejidad semántica de un concepto de juego puede ordenarse empíricamente por el tipo de error que provoca. Los patrones que requieren APIs específicas del motor (percepción, física) exponen la falta de conocimiento paramétrico del motor del modelo, mientras que los patrones que dependen de la lógica general exponen debilidades de generación estructural.
3. El Techo de la Pasada Única: Los hallazgos establecen que, dentro del nivel de pesos abiertos de 7B–30B, el cuello de botella para la generación de pasada única es la falta de conocimiento específico del motor, no la escala del modelo, el modo de generación o el condicionamiento estructural.
4. Diagnóstico Práctico para Diseñadores: Los perfiles de error ofrecen una guía concreta para diseñadores y desarrolladores de juegos. Indican qué conceptos de juego (ej. Sigilo) están actualmente fuera del alcance de la generación de pasada única sin ayuda de un LLM y requieren soporte de conocimiento externo del motor (ej. generación aumentada por recuperación o ajuste fino), frente a qué conceptos (ej. Captura) podrían ser susceptibles al post-procesamiento sintáctico o la decodificación guiada por gramática.

Los autores concligen que, si bien los bucles de reparación iterativos son productivos en la práctica, enmascaran las limitaciones intrínsecas de los LLM actuales. La evaluación de pasada única revela que, sin la inyección de conocimiento externo del motor, los modelos actuales no pueden sintetizar escenas de Unity ejecutables, independientemente de la complejidad del patrón de diseño o el tamaño del modelo.