Une IA peut-elle bâtir un jeu de puzzle entier ? ScriptDoctor et sa boucle générer-tester-réparer

Introduction

Enchanté — voici le digest d'articles de Fukai. Je lis des articles universitaires sur les puzzles et la conception de jeux, en traduisant le jargon en mots de tous les jours, et je parcours chacun en cinq parties : problème, méthode, résultats, où on peut l'utiliser, et limites. Pour le premier numéro, j'ai choisi une étude qui demande à une IA de bâtir un jeu de puzzle entier.

L'article est ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search, posté sur arXiv le 6 juin 2025. Il est coécrit par sept chercheurs — menés par Sam Earle de la New York University, avec des collègues de l'University of Malta, de l'University of the Witwatersrand et de Microsoft — et a été soumis comme article court à l'IEEE Conference on Games (CoG). L'un des auteurs, Julian Togelius, figure parmi les noms les plus connus de la recherche sur la génération procédurale de contenu.

Pourquoi cet article en premier ? Parce que le sujet est PuzzleScript. Publié par Stephen Lavelle (increpare) en 2013, ce minuscule langage spécifique à un domaine décrit tout un jeu façon Sokoban — règles, sprites et niveaux — en quelques dizaines de lignes de texte, et des développeurs indé du monde entier, dont Hempuli, de Baba Is You, l'ont utilisé pour le prototypage. Un monde familier aux lecteurs de ce site est ici le laboratoire.

Le problème : comment vérifier qu'« une IA a fait un jeu » ?

Faites défiler les bons fils sociaux et vous trouverez à l'infini des publications « j'ai fait faire un jeu à une IA ». Les auteurs partent d'une question simple à propos de ce spectacle : est-ce un bon jeu ? Est-ce plus qu'un léger remaniement de quelque chose présent dans les données d'entraînement ? Et y a-t-il un moyen de vérifier autre qu'un humain s'asseyant pour jouer à chacun ?

Pour les jeux ordinaires écrits en JavaScript ou Python, il n'existe essentiellement aucun moyen pour une machine de jouer et d'évaluer la qualité automatiquement. Tant que l'évaluation dépend des humains, les expériences ne peuvent pas passer à l'échelle, et l'on ne peut pas étudier systématiquement comment formuler les prompts pour de meilleurs jeux. Avant de demander si l'IA peut faire des jeux, il nous manque une règle pour savoir si elle l'a fait. C'est le problème que cet article prend en charge.

Les auteurs ont donc choisi PuzzleScript comme petit monde expérimental — à la manière des biologistes qui étudient E. coli ou la mouche du vinaigre comme « organismes modèles ». Trois raisons. D'abord, tout un jeu tient dans un court texte, ce qui convient à la sortie d'un modèle de langage. Ensuite, le moteur est léger avec des entrées et sorties standardisées, si bien que les machines peuvent jouer des milliers de parties. Enfin, le corpus de jeux PuzzleScript publiés est assez petit pour qu'on le connaisse à peu près en entier — un cadre rare où l'on pourra un jour poser sérieusement la question « est-ce réellement nouveau ? ».

La méthode : une boucle de génération, d'inspection et de réparation

ScriptDoctor est, en une phrase, une boucle générer-inspecter-réparer. Un LLM (GPT-4o, o1 et o3-mini dans les expériences) écrit un programme PuzzleScript complet — définitions d'objets, règles, conditions de victoire, niveaux. Son prompt est étoffé de documentation PuzzleScript, d'exemples tirés d'une base de données de 610 jeux écrits par des humains, et d'idées de conception produites par un agent de « brainstorming » distinct.

L'inspection se fait en deux étapes. D'abord, la compilation : le code généré passe par le moteur PuzzleScript, et toute erreur ou avertissement est renvoyé directement au LLM. Un parseur bâti à partir d'une grammaire hors-contexte de PuzzleScript (écrit avec la bibliothèque Python Lark) signale aussi les erreurs de syntaxe.

Si le code compile, deuxième étape : la machine joue réellement. Une recherche en largeur (BFS) — une recherche méthodique, quasi exhaustive, qui vérifie d'abord les coups peu profonds — explore chaque niveau jusqu'à un million d'états uniques et rapporte trois nombres : s'il est soluble, la longueur de la solution, et combien d'états ont été examinés pour la trouver. Ces nombres sont renvoyés au LLM via un serveur.

Le LLM dispose de dix chances. Un essai réussit dès que chaque niveau admet une solution de plus de dix coups ; sinon, on montre au modèle son code précédent et les résultats de l'inspection, et on lui demande de réviser. La philosophie de conception : prendre le cycle bâtir-jouer-corriger du concepteur humain et le faire tourner, autant que possible, sur les seules machines.

Résultats : les exemples aident, les modèles de raisonnement l'emportent, et le « cassé mais intéressant »

Le résultat le plus clair d'abord. Sans exemples faits par des humains (zero-shot), seuls 30 % des jeux de GPT-4o compilaient, et 0 % avaient un niveau que l'agent de recherche pouvait résoudre. Mettez des exemples dans le prompt (few-shot), et la compilation bondit à 70–80 %, plus de la moitié des jeux gagnant des niveaux solubles. PuzzleScript n'est pas un langage majeur comme Python, alors les exemples travaillés comptent de façon décisive — les auteurs notent que cela ne les a même pas surpris.

La comparaison des modèles est tout aussi intéressante. Dans les mêmes conditions few-shot, 10k tokens, dix jeux chacun : GPT-4o compilait 67 % du temps, le modèle de raisonnement o1 87 %, o3-mini 93 %. Sur « tous les niveaux solubles », les 20 % d'o3-mini étaient le meilleur score. Les modèles qui réfléchissent avant d'écrire sont meilleurs pour assembler des règles et des niveaux cohérents. En revanche, bourrer le prompt de plus d'exemples a atteint un rendement décroissant autour de 30 000 tokens.

La pièce maîtresse de l'article est « Unconventional PushPull », généré par o1. Par-dessus le pousser-tirer familier, il ajoute une astuce — quand le chemin du joueur est bloqué, une caisse glisse d'une case supplémentaire — plus un interrupteur et une porte. La solution la plus courte fait 34 coups, et même la BFS méthodique a dû examiner 1 006 états pour la trouver. Le verdict des auteurs : retors mais sensé pour un joueur humain.

Tout n'est pas bonne nouvelle, cependant, et les auteurs sont francs : les jeux générés les plus complexes tendaient à être complexes « en dépit de, voire en raison de » mécaniques cassées. Dans un jeu généré où un sorcier peut se téléporter à travers les murs ou les détruire, des interactions vraisemblablement involontaires ont fini par produire les solutions les plus intéressantes. Et les sprites générés étaient abstraits — parfois littéralement invisibles — au point que les figures de l'article remplacent l'art par celui de jeux faits par des humains. Écrire des règles est une chose ; aligner l'apparence sur l'intention est encore loin.

Où on peut l'utiliser : enseignements pour les développeurs et les joueurs

Pour les développeurs indé, l'enseignement le plus transposable n'est pas l'IA elle-même mais l'habitude de conception qu'est la vérification automatisée par un solveur. Donnez vos niveaux à un algorithme de recherche et examinez la longueur de la solution et l'effort de recherche — un contrôle qualité que vous pouvez copier dès aujourd'hui, sans aucun LLM requis. Un niveau avec une solution en trois coups, ou un niveau que même la force brute ne peut craquer, apparaîtra dans les données avant qu'un testeur ne le voie jamais.

Si vous voulez bel et bien l'utiliser à la façon de ScriptDoctor, voyez-le comme une fabrique de brouillons. La boucle d'auto-réparation en dix tours est une automatisation grossière du bâtir-jouer-corriger. Au premier jour d'une game jam, faites-lui proposer dix variations de règles, jetez-en neuf, peaufinez-en une. Ce que suggère Unconventional PushPull, c'est que la bonne pourrait être étonnamment correcte.

Pour les joueurs, l'article se lit comme une règle pour la distance entre soluble et amusant. Les comptes de nœuds de la BFS mesurent la difficulté pour un ordinateur, ce qui n'est pas la même chose que le plaisir humain de l'illumination. Dit autrement : tout ce que possèdent les grands puzzles faits par des humains — l'intention communiquée, la diversion ingéniée, le déclic d'une solution qui a du sens — se détache en contour précisément parce que les instruments de cet article ne peuvent pas le voir.

Dans le contexte de la recherche, les auteurs proposent d'utiliser la sortie du pipeline — des jeux garantis de compiler et d'être solubles — comme un jeu de données pour affiner des modèles plus petits. Un générateur avec un vérificateur intégré fait aussi office de fabrique de matériel pédagogique.

Limites : ce que cet article ne mesure pas

Les formalités d'abord. C'est un article court de cinq pages, et au moment de sa publication sur arXiv il était au stade « soumis à CoG ». Chaque condition expérimentale ne couvre que 10 à 20 jeux générés, si bien que les tableaux se lisent mieux comme des tendances que comme des comparaisons rigoureuses.

Ensuite, la limite qui compte le plus. L'étude mesure si les jeux compilent, s'ils sont solubles, et si les solutions sont longues — pas s'ils sont amusants. Il n'y a aucune évaluation par des joueurs humains, et les auteurs eux-mêmes notent que beaucoup de jeux adorés faits par des humains ont des solutions courtes tout en restant intéressants. La longueur de la solution et l'effort de recherche ne sont que des indicateurs grossiers de l'amusement.

Les faiblesses techniques sont énoncées clairement aussi. Les LLM peinent avec le raisonnement spatial qu'exige la conception de niveaux, et laissés à eux-mêmes tendent à produire des niveaux aux solutions trop courtes. Quand on leur demande d'ajouter du défi, ils se contentent souvent d'étirer le niveau de quelques rangées ou d'éparpiller quelques obstacles. Le système ne peut pas non plus diagnostiquer tout seul qu'une mécanique est cassée au regard de l'intention ; comme travail futur, les auteurs suggèrent de montrer des séquences de jeu à un modèle vision-langage pour repérer de tels défauts.

Enfin, la question d'ouverture — n'est-ce qu'un remaniement des données d'entraînement ? — n'est pas non plus réellement tranchée ici. Mesurer la similarité par rapport aux 610 jeux existants est laissé comme travail futur, et le vrai bénéfice d'avoir choisi PuzzleScript, un monde dont l'intégralité du corpus publié est à peu près connaissable, n'arrivera que lorsque ce contrôle sera bâti.

Références

・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, posté le 6 juin 2025 ; CC BY 4.0)

・PuzzleScript (le langage de script pour jeux de puzzle de Stephen Lavelle, publié en 2013 ; source sur GitHub)

・Base de données de jeux PuzzleScript (source des 610 jeux écrits par des humains que l'article utilise comme exemples few-shot)

・Travaux connexes : GAVEL: Generating Games via Evolution and Language Models (Todd et al., 2024 — un système antérieur combinant recherche évolutionnaire et LLM dans le cadre Ludii)

Pour conclure

Les discours sur l'IA qui fait des jeux tendent à osciller entre l'emballement et l'effroi. Ce que j'aime dans cet article, c'est qu'il s'arrête en deçà des deux et bâtit d'abord l'instrument de mesure. Ce que l'instrument peut voir, jusqu'ici, n'est que « ça compile, et la force brute peut le résoudre » — la majeure partie de ce que nous apprécions réellement dans un puzzle n'apparaît pas. Mais le contour de ce qui ne peut pas être mesuré n'est devenu clair que parce que quelqu'un a tenté de le mesurer.

C'est tout pour le premier numéro du digest d'articles de Fukai. La prochaine fois, une autre étude sur la conception du jeu, lue à travers les cinq mêmes lentilles.