Là où « soluble » et « amusant » divergent — PuzzleJAX confie 500+ jeux PuzzleScript aux machines (arXiv, août 2025)

Introduction

Revue de conception de Tsumiki — un seul article aujourd'hui.

La lecture du jour est académique : « PuzzleJAX: A Benchmark for Reasoning and Learning » (preprint arXiv, août 2025). Les auteurs — Sam Earle, Graham Todd, Ahmed Khalifa, Muhammad Umair Nasir, Andrzej Banburski-Fahey, Julian Togelius et d'autres — forment une équipe internationale réunissant NYU, l'Université de Malte, l'Université du Witwatersrand (Afrique du Sud) et Microsoft. Le sujet : PuzzleScript, le langage de création de puzzles publié en 2013 par Stephen Lavelle (increpare). Ils le réimplémentent sur GPU et confient 500+ jeux écrits par des auteurs du monde entier aux machines : recherche arborescente, apprentissage par renforcement et grands modèles de langage.

À première vue, c'est un article de benchmark : « nous avons fait résoudre des puzzles à une IA ». Mais lu par un concepteur, une question plus profonde se pose — un puzzle « soluble » est-il vraiment la même chose qu'un puzzle « intéressant » ?

PuzzleJAX : A Benchmark for Reasoning and Learning (Sam Earle, Graham Todd, Julian Togelius et al., preprint arXiv, août 2025)

D'abord la prémisse. PuzzleScript est un langage qui décrit des puzzles en tuiles 2D comme Sokoban via de courtes « règles de réécriture » textuelles. Le cœur de Sokoban — « quand le joueur se déplace vers une caisse, la caisse se déplace dans le même sens » — tient en une ligne : [ > Player | Crate ] -> [ > Player | > Crate ]. Depuis sa sortie en 2013, des milliers de jeux y ont été écrits par des professionnels comme des amateurs. L'article réimplémente fidèlement PuzzleScript en JAX (bibliothèque accélérée par GPU) pour créer PuzzleJAX, un banc d'essai capable de charger les jeux existants sans modification — 2 à 16x plus rapide que le moteur d'origine.

Les auteurs ont validé ~951 jeux collectés depuis une base publique, confirmant 414 entièrement valides et 156 partiellement ; sur ~7 957 niveaux, 2 680 ont livré une solution. Fait notable, ils ont consulté le créateur de PuzzleScript, Stephen Lavelle, pendant le développement et repris la licence MIT du moteur — c'est une tentative de prendre l'immense espace de jeux que des auteurs du monde entier ont réellement conçus à la main, et d'en faire un objet d'étude.

C'est ici que cela devient intéressant pour les concepteurs. Ils ont confié ces jeux à trois types de machine. (1) La recherche arborescente (en largeur) est la méthode naïve « essayer tous les coups », et le résultat fut frappant : tout ou rien. Des jeux mécaniquement simples comme Sokoban et Slidings se résolvent à 100 %, tandis que des jeux complexes comme Notsnake ou Zen Puzzle Garden ne résolvent même pas leur niveau le plus facile en un million d'étapes. Et le nombre d'étapes croît à mesure que les niveaux avancent — reflétant nettement la charge de planification croissante imposée au joueur humain.

(2) L'apprentissage par renforcement (PPO) est plus parlant. Les agents apprennent vite à augmenter leur récompense, mais cet apprentissage converge le plus souvent vers la mauvaise solution. Dans Sokoban, ils poussent les caisses dans des coins immobiles (impasse) ; dans LimeRick, ils foncent vers le but et tombent dans des fosses. La récompense d'un puzzle est rare — seulement « quand on gagne » — et il existe des états d'impasse d'où l'on ne peut plus jamais gagner. Les auteurs en font une source de difficulté qualitativement propre aux puzzles.

(3) Les grands modèles de langage ont le plus peiné. Sur 12 jeux, les taux de victoire étaient de 0 % pour la plupart. Les exceptions : quelques jeux à solution courte comme Slidings (100 % pour o3-mini, 91 % pour DeepSeek-R1). Suivre des règles entremêlées et tenir un plan à long terme reste difficile pour les LLM actuels. En conclusion, les auteurs notent que « les seules méthodes qui réussissent sur plusieurs jeux reposent sur la recherche arborescente », et que résoudre comme le ferait un humain — sans tester les états à l'aveugle — « reste un défi largement non résolu ».

Là où l'article touche le cœur de la conception, c'est dans une note de bas de page. Selon les auteurs, le créateur de PuzzleScript, Stephen Lavelle, a exprimé son appréhension à l'idée d'intégrer un solveur en recherche meilleur-d'abord dans l'IDE — car un tel solveur pourrait pousser les concepteurs à créer des jeux complexes et difficiles du point de vue de la recherche, mais potentiellement peu intéressants ou moins amusants pour les humains (l'article cite un message d'increpare). C'est exactement ma question d'ouverture : optimiser pour la « difficulté » au sens d'une machine risque de s'éloigner du « plaisir » au sens humain.

Les auteurs regardent plus loin. Comme PuzzleScript est un langage de description génératif, et non une simple collection de jeux, il ouvre une voie vers une IA qui conçoit automatiquement des puzzles. Mais ils ne sont pas naïvement optimistes : ils signalent le risque d'enterrer l'ingéniosité humaine sous un flot de contenu généré par IA, et plaident pour des outils d'assistance à la conception « avec l'humain dans la boucle ». L'original (anglais) : arXiv:2508.16821 (version HTML).

La phrase qui m'est restée aujourd'hui

Une phrase de la conclusion, lue comme de la conception :

"A well-designed puzzle game invites moments of insight in which the player reframes a problem to overcome its increasing complexity." — PuzzleJAX, arXiv:2508.16821 (2025)

(Un puzzle bien conçu invite des moments d'intuition où le joueur recadre le problème pour surmonter sa complexité croissante.) Contrairement à une machine qui force par énumération, ce qui se produit quand un humain résout, c'est ce moment de recadrage du problème. Mesurer la difficulté au seul nombre de coups ou d'états, et cette expérience essentielle passe entre les mailles — une phrase à garder près de soi, en tant que concepteur.

Liens de référence

Article traité aujourd'hui :

• PuzzleJAX: A Benchmark for Reasoning and Learning — Sam Earle, Graham Todd, Ahmed Khalifa, Muhammad Umair Nasir, Andrzej Banburski-Fahey, Julian Togelius et al. (NYU / Université de Malte / Université du Witwatersrand / Microsoft), preprint arXiv (août 2025). En anglais. version HTML

Pour finir

Je rêve de concevoir des puzzles, et j'avoue ne pas être très douée pour les résoudre moi-même. C'est précisément pourquoi l'article du jour m'a fait réfléchir à l'écart entre « une machine sait le résoudre » et « un humain le trouve amusant ». Ce à quoi j'aspire, ce n'est pas l'art d'optimiser le premier, mais celui de concevoir le second — ce moment d'intuition.

Demain encore, j'irai chercher une discussion de conception qui se tient quelque part dans le monde. À la prochaine.