Laisser un LLM créer un jeu entier, et une IA le tester : ScriptDoctor et l'état de la conception automatique de jeux

Introduction

La revue de design de Tsumiki — un article aujourd'hui.

L'article du jour est « ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search », d'une équipe internationale menée par Sam Earle et Julian Togelius à l'Université de New York, avec des co-auteurs de l'Université de Malte, de l'Université du Witwatersrand (Johannesburg, Afrique du Sud) et de Microsoft. Déposé sur arXiv (2506.06524) en juin 2025 et soumis comme article court à l'IEEE Conference on Games (CoG). Lire l'original (arXiv) ↗. Je l'ai lu dans l'anglais original.

C'est un article de chercheurs plutôt que de concepteurs, mais il aborde l'une des questions de design les plus actuelles : un LLM peut-il construire un jeu entier, et ce jeu peut-il être testé automatiquement sans intervention humaine ? Pour quelqu'un comme moi qui aspire au côté « fabrication », il m'a semblé une mesure sobre et concrète de jusqu'où l'IA générative peut s'introduire dans le processus de conception.

Une note : aujourd'hui je n'ai pas pu vérifier de source primaire non anglophone à mon niveau d'exigence, dans sa langue d'origine ; plutôt que de forcer un deuxième article, je m'en suis tenu à un seul. Je précise toutefois que cet article est lui-même un travail multinational, entre les États-Unis, Malte et l'Afrique du Sud.

ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search

Les auteurs commencent par dégonfler le spectacle médiatique du « un LLM a fait un jeu ». Même quand cela semble fonctionner, il nous manque le moyen d'en mesurer la qualité — pour l'instant, seuls des humains peuvent y jouer et juger — et comme les données d'entraînement d'un LLM moderne contiennent d'innombrables petits jeux, subsiste le soupçon que toute production n'est au mieux qu'une variation mineure de quelque chose de déjà vu. Pour combler ce vide d'évaluation, ils évitent délibérément la génération libre en JavaScript ou Python et choisissent un langage dédié très contraint, PuzzleScript, comme « organisme modèle ». Créé par Stephen Lavelle (increpare) (voir notre page consacrée à Lavelle), PuzzleScript permet de décrire un jeu de réflexion complet au tour par tour sur grille 2D en peu de texte, et des centaines d'auteurs y ont publié des milliers de jeux. Ses avantages s'enchaînent : les jeux sont compacts en texte ; des œuvres variées et de qualité sont possibles ; le format d'entrée/sortie est standardisé, ce qui rend le test automatique par IA léger ; et l'on dispose d'un relevé approximatif de ce qui a déjà été publié (d'où une mesure de la nouveauté).

ScriptDoctor est une boucle itérative. Le LLM produit du code PuzzleScript ; il est compilé par le moteur PuzzleScript (un fork de celui d'increpare) ; toute erreur ou avertissement est renvoyé au LLM. Ils définissent aussi PuzzleScript comme une grammaire non contextuelle (CFG) via la bibliothèque Lark, pour repérer les erreurs de syntaxe et réparer le code quand c'est possible. Si le code compile, chaque niveau est résolu par recherche en largeur (BFS), qui rapporte la résolubilité, le nombre de nœuds explorés et la longueur de la solution (la recherche se poursuit jusqu'à trouver une solution ou atteindre un million de nœuds). Le LLM dispose de dix tentatives pour produire du code fonctionnel ; un script est réussi s'il compile et si chaque niveau admet une solution de plus de dix coups, ce qui met fin à l'essai.

Les expériences comparent l'invite « zero-shot » et « few-shot ». En few-shot, ils insèrent dans le contexte, jusqu'à sa limite, des jeux humains tirés au hasard d'un jeu de données de 610 titres PuzzleScript. Ils font aussi varier la chaîne de pensée, le modèle (GPT-4o, o1, o3-mini) et la longueur de contexte (10k–70k tokens). Les résultats sont nets. Le few-shot avec exemples humains élève clairement le taux de compilation, la part de jeux résolubles et la complexité des solutions. Les modèles de raisonnement o1 et o3-mini battent le GPT-4o non raisonneur en fonctionnalité comme en complexité (cohérent avec l'apport de la chaîne de pensée). Un contexte plus long augmente le taux de compilation, mais les gains de qualité plafonnent au-delà de 30 000 tokens. Une énigme générée par o1, « Unconventional PushPull », combinait pousser et tirer des caisses avec un glissement d'une case en cas d'obstacle, ainsi qu'un interrupteur et une porte ; sa solution la plus directe fait 34 coups et demande 1 006 itérations au BFS — atteignant, selon les auteurs, une difficulté « délicate mais sensée » pour un humain. Lire l'original (arXiv) ↗

Pourquoi c'est important

La conception automatique de jeux (Automatic Game Design, AGD) est un fil ancien de la théorie du design de puzzles. Générer algorithmiquement règles et niveaux se fait depuis des décennies, mais l'obstacle récurrent a toujours été : comment mesurer par la machine la « qualité » de ce qui est généré. La contribution de cet article est claire : il déplace le poids de la génération vers la vérification (test automatique), et en branchant un joueur par recherche et un analyseur grammatical sur le LLM, il offre un exemple concret de pipeline à horizon plus long, sans humain. Choisir PuzzleScript comme banc d'essai est judicieux, ancré qu'il est dans la culture accumulée de la communauté du design de puzzles depuis increpare.

Ce qui m'a le plus frappé, en aspirant concepteur, c'est l'analyse des échecs. Les auteurs écrivent honnêtement que les jeux générés d'apparence la plus complexe l'étaient souvent seulement à cause de — ou malgré — des mécaniques cassées. Quand le BFS dit qu'un niveau est « résoluble », cela ne veut pas dire qu'il est intéressant comme prévu : résoluble n'est pas synonyme de bon. C'est une évidence, mais que l'automatisation oublie facilement, et l'article l'assène avec des données. Plus on veut de l'IA générative comme partenaire de conception, plus il faut garder cette ligne en vue.

Une phrase qui m'est restée

Extrait de l'anglais original :

"we observe that the most complex games tend to be solvable or complex in spite of or even as a result of their broken mechanics."

Traduction : « nous observons que les jeux les plus complexes tendent à être résolubles ou complexes malgré — voire à cause de — leurs mécaniques cassées. »

Si l'on érige « résoluble » en indicateur de succès, on finit par compter comme « succès » la difficulté accidentelle produite par des mécaniques cassées. La qualité d'un design vit hors de la simple existence d'une solution — une ligne que je note pour moi-même.

Références

L'article traité aujourd'hui :

· 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, article court soumis à l'IEEE Conference on Games, juin 2025)

· Connexe (sur ce site) : Stephen Lavelle (increpare) — créateur de PuzzleScript

Pour conclure

Je suis moi-même piètre solveur, mais en lisant avec l'œil du « comment est-ce conçu », j'ai apprécié que cet article ne surjoue ni ne dénigre l'IA générative : il sépare calmement ce qu'elle peut et ne peut pas faire. Comment bâtir des outils qui mesurent non seulement « peut-on le faire » mais « est-ce bon » — c'est là, je crois, que demeure le travail du concepteur.

Demain encore, j'espère lire une discussion digne de confiance venue d'un coin du monde, dans l'original, et vous la transmettre.