¿Puede una IA construir un puzle entero? ScriptDoctor y su bucle de generar-probar-reparar

Introducción

Encantado: este es el resumen de artículos de Fukai. Leo artículos académicos sobre puzles y diseño de juegos, traduciendo la jerga a palabras de cada día, y recorro cada uno en cinco partes: problema, método, hallazgos, dónde puedes usarlo y limitaciones. Para la primera entrega, elegí un estudio que le pide a una IA que construya un puzle entero.

El artículo es ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search, publicado en arXiv el 6 de junio de 2025. Está firmado por siete investigadores —encabezados por Sam Earle, de la Universidad de Nueva York, con colegas de la Universidad de Malta, la Universidad de Witwatersrand y Microsoft— y se presentó como artículo breve a la IEEE Conference on Games (CoG). Uno de los autores, Julian Togelius, figura entre los nombres más conocidos de la investigación en generación procedimental de contenido.

¿Por qué este artículo primero? Porque el tema es PuzzleScript. Lanzado por Stephen Lavelle (increpare) en 2013, este diminuto lenguaje específico de dominio describe todo un juego al estilo Sokoban —reglas, sprites y niveles— en unas pocas docenas de líneas de texto, y desarrolladores indie de todo el mundo, entre ellos Hempuli, de Baba Is You, lo han usado para prototipar. Un mundo familiar para los lectores de este sitio es, aquí, el laboratorio.

El problema: ¿cómo verificas que «una IA hizo un juego»?

Desliza los feeds sociales adecuados y encontrarás sin fin publicaciones del tipo «hice que una IA me hiciera un juego». Los autores parten de una pregunta sencilla sobre ese espectáculo: ¿es un buen juego? ¿Es algo más que un ligero refrito de algo de los datos de entrenamiento? ¿Y hay alguna manera de comprobarlo aparte de que un humano se siente a jugar a cada uno?

Para los juegos ordinarios escritos en JavaScript o Python no existe esencialmente forma de que una máquina los juegue y evalúe su calidad de manera automática. Mientras la evaluación dependa de humanos, los experimentos no pueden escalar, y no podemos estudiar de forma sistemática cómo formular los prompts para obtener mejores juegos. Antes de preguntar si la IA puede hacer juegos, nos falta una regla para saber si lo hizo. Ese es el problema que aborda este artículo.

Así que los autores eligieron PuzzleScript como pequeño mundo experimental, al modo en que los biólogos estudian E. coli o las moscas de la fruta como «organismos modelo». Tres razones. Primera, todo un juego cabe en un texto corto, lo que conviene a la salida de un modelo de lenguaje. Segunda, el motor es ligero, con entrada y salida estandarizadas, de modo que las máquinas pueden jugar miles de ejecuciones. Tercera, el corpus de juegos de PuzzleScript publicados es lo bastante pequeño como para conocerlo a grandes rasgos por completo, un entorno raro donde algún día podrá preguntarse en serio «¿es esto realmente nuevo?».

El método: un bucle de generación, inspección y reparación

ScriptDoctor es, en una frase, un bucle de generar-inspeccionar-reparar. Un LLM (GPT-4o, o1 y o3-mini en los experimentos) escribe un programa completo de PuzzleScript: definiciones de objetos, reglas, condiciones de victoria, niveles. Su prompt se rellena con documentación de PuzzleScript, ejemplos extraídos de una base de datos de 610 juegos creados por humanos e ideas de diseño producidas por un agente de «lluvia de ideas» aparte.

La inspección ocurre en dos etapas. Primero, la compilación: el código generado pasa por el motor de PuzzleScript, y cualquier error o advertencia se devuelve directamente al LLM. Un analizador construido a partir de una gramática libre de contexto de PuzzleScript (escrito con la biblioteca de Python Lark) señala también los errores de sintaxis.

Si el código compila, etapa dos: la máquina juega de verdad. La búsqueda en anchura (BFS) —una búsqueda metódica, casi exhaustiva, que comprueba primero los movimientos poco profundos— explora cada nivel hasta un millón de estados únicos e informa de tres números: si es resoluble, cuánto mide la solución y cuántos estados se examinaron para encontrarla. Esos números se le devuelven al LLM a través de un servidor.

El LLM dispone de diez oportunidades. Un intento tiene éxito en el momento en que cada nivel admite una solución de más de diez movimientos; de lo contrario, se le muestra al modelo su código previo y los resultados de la inspección y se le pide que revise. La filosofía de diseño: tomar el ciclo de construir-jugar-arreglar del diseñador humano y hacerlo girar, en la medida de lo posible, solo con máquinas.

Hallazgos: los ejemplos ayudan, los modelos de razonamiento ganan y lo «roto pero interesante»

Primero el resultado más claro. Sin ejemplos hechos por humanos (zero-shot), solo el 30 % de los juegos de GPT-4o compilaban, y el 0 % tenía un nivel que el agente de búsqueda pudiera resolver. Mete ejemplos en el prompt (few-shot), y la compilación salta al 70-80 %, con más de la mitad de los juegos ganando niveles resolubles. PuzzleScript no es un lenguaje mayoritario como Python, así que los ejemplos trabajados importan de manera decisiva; los autores señalan que esto no les sorprendió ni a ellos.

La comparación entre modelos es igual de interesante. Bajo las mismas condiciones few-shot y de 10k tokens, diez juegos cada uno: GPT-4o compiló el 67 % de las veces, el modelo de razonamiento o1 el 87 %, o3-mini el 93 %. En «todos los niveles resolubles», el 20 % de o3-mini fue el mejor. Los modelos que piensan antes de escribir son mejores ensamblando reglas y niveles coherentes. Mientras tanto, atiborrar el prompt de más ejemplos dio rendimientos decrecientes en torno a los 30 000 tokens.

La pieza estrella del artículo es «Unconventional PushPull», generado por o1. Sobre el familiar empujar-y-tirar añade un giro —cuando el camino del jugador está bloqueado, una caja se desliza una casilla extra— más un interruptor y una puerta. La solución más corta es de 34 movimientos, e incluso la metódica BFS tuvo que examinar 1006 estados para encontrarla. El veredicto de los autores: tramposo pero sensato para un jugador humano.

No todo son buenas noticias, sin embargo, y los autores son francos: los juegos generados más complejos tendían a ser complejos «a pesar de, o incluso a causa de» mecánicas rotas. En un juego generado donde un mago puede teletransportarse a través de las paredes o destruirlas, interacciones presumiblemente no intencionadas acabaron produciendo las soluciones más interesantes. Y los sprites generados eran abstractos —a veces literalmente invisibles— hasta el punto de que las figuras del artículo los sustituyen por arte de juegos hechos por humanos. Escribir reglas es una cosa; alinear aspecto e intención queda aún lejos.

Dónde puedes usarlo: lecciones para desarrolladores y jugadores

Para los desarrolladores indie, la lección más transferible no es la IA en sí, sino el hábito de diseño de la verificación automatizada con un solucionador. Pasa tus niveles a un algoritmo de búsqueda y observa la longitud de la solución y el esfuerzo de búsqueda: una comprobación de calidad que puedes copiar hoy mismo, sin necesidad de LLM. Un nivel con una solución de tres movimientos, o uno que ni siquiera la fuerza bruta puede resolver, aparecerá en los datos antes de que un probador llegue a verlo.

Si de verdad quieres usarlo al estilo ScriptDoctor, piénsalo como una fábrica de borradores. El bucle de autorreparación de diez rondas es una automatización tosca del construir-jugar-arreglar. El primer día de una game jam, hazle proponer diez giros de reglas, descarta nueve, pule uno. Lo que sugiere Unconventional PushPull es que ese uno podría ser sorprendentemente decente.

Para los jugadores, el artículo se lee como una regla para medir la distancia entre resoluble y divertido. Los recuentos de nodos de la BFS miden la dificultad para un ordenador, que no es lo mismo que el placer humano de la intuición. Dicho al revés: lo que sea que tengan los grandes puzles hechos por humanos —intención comunicada, despiste diseñado, el clic de una solución que tiene sentido— resalta en su contorno precisamente porque los instrumentos de este artículo no pueden verlo.

En el contexto de la investigación, los autores proponen usar la salida del pipeline —juegos garantizados de que compilan y son resolubles— como conjunto de datos para afinar modelos más pequeños. Un generador con un verificador incorporado sirve además de fábrica de material didáctico.

Limitaciones: lo que este artículo no mide

Primero la formalidad. Es un artículo breve de cinco páginas, y en el momento de su publicación en arXiv estaba en la fase de «enviado a CoG». Cada condición experimental abarca solo entre 10 y 20 juegos generados, así que las tablas se leen mejor como tendencias que como comparaciones rigurosas.

A continuación, la limitación que más importa. El estudio mide si los juegos compilan, si son resolubles y si las soluciones son largas, no si son divertidos. No hay evaluación por jugadores humanos, y los propios autores señalan que muchos juegos queridos hechos por humanos tienen soluciones cortas y, aun así, siguen siendo interesantes. La longitud de la solución y el esfuerzo de búsqueda son solo indicadores burdos de la diversión.

Las debilidades técnicas también se exponen con claridad. Los LLM tienen dificultades con el razonamiento espacial que exige el diseño de niveles y, dejados a su aire, tienden a producir niveles con soluciones demasiado cortas. Cuando se les pide añadir desafío, a menudo se limitan a estirar el nivel unas pocas filas o a esparcir algunos obstáculos. El sistema tampoco puede diagnosticar por sí mismo que una mecánica está rota respecto a la intención; como trabajo futuro, los autores sugieren mostrar grabaciones de juego a un modelo de visión y lenguaje para detectar esos fallos.

Por último, la pregunta inicial —¿no es esto solo un refrito de los datos de entrenamiento?— tampoco se responde aquí en realidad. Medir la similitud frente a los 610 juegos existentes se deja como trabajo futuro, y el verdadero rédito de haber elegido PuzzleScript, un mundo cuyo corpus publicado entero es a grandes rasgos conocible, solo llegará cuando esa comprobación se construya.

Referencias

・ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search (Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius; arXiv:2506.06524, publicado el 6 de junio de 2025; CC BY 4.0)

・PuzzleScript (el lenguaje de scripting para puzles de Stephen Lavelle, lanzado en 2013; código fuente en GitHub)

・PuzzleScript games database (fuente de los 610 juegos creados por humanos que el artículo usa como ejemplos few-shot)

・Trabajo relacionado: GAVEL: Generating Games via Evolution and Language Models (Todd et al., 2024, un sistema anterior que combina búsqueda evolutiva y LLM en el marco Ludii)

Para terminar

Hablar de que la IA hace juegos tiende a oscilar entre el bombo y el temor. Lo que me gusta de este artículo es que se detiene antes de ambos y construye primero el aparato de medida. Lo que el aparato puede ver, por ahora, es solo «compila, y la fuerza bruta puede resolverlo»; la mayor parte de lo que en realidad disfrutamos en un puzle no queda registrado. Pero el contorno de lo que no se puede medir solo quedó claro porque alguien intentó medir.

Hasta aquí la primera entrega del resumen de artículos de Fukai. La próxima vez, otro estudio sobre el diseño del juego, leído a través de las mismas cinco lentes.