Nasir et al. : faire évoluer les « règles mêmes » du jeu — Fukai lit MORTAR

Résumé en un paragraphe

Peut-on concevoir automatiquement les « mécaniques » d'un jeu — c'est-à-dire les règles fondamentales qui déterminent les actions du joueur et leurs conséquences ? Cette recherche affronte la question de front. La plupart des travaux de génération automatique se concentrent sur la génération de niveaux ou de terrains ; les tentatives de créer et d'évaluer les mécaniques elles-mêmes sont rares. MORTAR, le système proposé par les auteurs, traite chaque mécanique comme un fragment de code Python et dispose d'un mécanisme permettant à un grand modèle de langage (LLM — IA entraînée sur d'immenses corpus de textes et capable de générer des suites ou des réponses) de les réécrire progressivement, tout en collectant et diffusant les meilleurs résultats.

La clé réside dans l'idée que « la valeur d'une mécanique ne peut être jugée isolément ; elle n'a de sens qu'une fois mise à l'épreuve du jeu réel ». MORTAR intègre chaque nouvelle mécanique dans un jeu complet, le fait jouer par 5 agents IA de niveaux différents, et prend pour critère de qualité si « le joueur le plus fort gagne bien ». Prototype de recherche fonctionnant avec GPT-4o-mini pour un coût d'environ 30 à 50 dollars par exécution selon les auteurs. Le présent article décompose successivement « quoi », « comment » et « ce que l'on a appris », pour saisir l'essentiel sans avoir à ouvrir la publication.

Introduction

L'article présenté aujourd'hui s'intitule « MORTAR: Evolving Mechanics for Automatic Game Design ». Ses auteurs sont Muhammad U. Nasir, Yuchen Li, Steven James et Julian Togelius, affiliés à l'Université du Witwatersrand (Afrique du Sud) et à l'Université de New York. Julian Togelius est un chercheur qui guide depuis longtemps le domaine de la génération procédurale de contenu (PCG) et de l'IA pour les jeux ; son nom apparaît sans cesse lorsqu'on trace la carte de ce secteur. Le présent texte est un preprint publié sur arXiv en janvier 2026 (arXiv:2601.00105 ; faute de pouvoir confirmer qu'il a passé une révision par les pairs, je le traite ici comme preprint).

Si j'ai choisi cet article aujourd'hui, c'est parce qu'il représente un exemple où la discussion sur la génération automatique a finalement franchi le pas des « niveaux » pour s'aventurer dans « les règles elles-mêmes » — ce qui me semble porteur d'enseignements pour les créateurs de jeux. La génération de niveaux dispose d'une abondante littérature antérieure ; mais dès qu'il s'agit de créer des mécaniques — par exemple « ramasser une clé ouvre une porte », « toucher un ennemi vous repousse » — de toutes pièces par une machine, la difficulté d'évaluation s'accroît d'un coup. Les auteurs affrontent ce défi directement. On notera également que la publication indique que les jeux générés peuvent être joués sur une page web rendue publique par les auteurs.

Contexte

La PCG (Procedural Content Generation — génération procédurale de contenu) est un domaine de recherche de longue date, aux applications variées : génération en cours de partie dans les roguelikes, aide à l'idéation des concepteurs, automatisation des tâches répétitives. Cependant, l'attention s'est concentrée en grande partie sur la « structure » des terrains et des niveaux, dont les indicateurs « est-ce résolvable ? » et « est-ce nouveau ? » permettent une évaluation relativement aisée de la qualité.

En revanche, la génération automatique de mécaniques — les règles d'interaction du jeu — a reçu relativement peu d'attention. Ce que les auteurs soulignent, c'est que la valeur d'une mécanique ne se manifeste que dans « la dynamique de jeu qu'elle engendre ». Une mécanique visuellement novatrice et complexe peut s'avérer ennuyeuse si elle ne produit pas de jeu faisant ressortir les différences de niveau. C'est pourquoi, au-delà de la génération, la conception de l'« évaluation » constitue la difficulté fondamentale — tel est le point de départ.

L'enjeu est important parce que les mécaniques déterminent le squelette de l'expérience du joueur. Elles conditionnent non seulement ce que l'on peut faire, mais aussi les stratégies et comportements émergents possibles. Automatiser ce maillon pourrait devenir un outil élargissant la créativité des concepteurs — les auteurs précisent toutefois clairement que l'objectif n'est pas de créer un jeu complet de toutes pièces, mais d'assister les concepteurs sans les remplacer.

Approche

MORTAR repose sur un algorithme de qualité-diversité (Quality-Diversity — cadre d'exploration qui ne cherche pas une seule meilleure solution, mais collecte uniformément de bonnes solutions aux propriétés variées), en l'occurrence la méthode MAP-Elites. Chaque mécanique est représentée comme une fonction Python et organisée selon deux « axes de classement » : le type de mécanique (9 catégories : déplacement, interaction, combat, progression, environnement, puzzle de réflexion, gestion de ressources, exploration, manipulation du temps) et la complexité du code (estimée par analyse de la structure du programme, à partir du nombre d'appels de fonctions et d'assignations). Dans chaque cellule de la grille formée par ces deux axes loge une mécanique de qualité.

Les nouvelles mécaniques sont créées en demandant au LLM de réécrire des mécaniques existantes. « Mutation » qui ajoute des fonctionnalités à une mécanique existante, « mutation de diversification » qui en montre trois et demande d'en créer une de style différent, « croisement » qui mélange deux mécaniques, « mutation de compatibilité » qui demande d'en créer une s'intégrant au jeu existant — ces opérations de calcul évolutif (méthode qui améliore les solutions en répétant mutations et sélection, à la manière de l'évolution biologique) sont toutes réalisées par le LLM sous forme d'édition de code réelle. Le code généré est d'abord vérifié pour les erreurs de syntaxe et d'exécution, puis soumis dans un environnement de test simple à une IA MCTS (recherche arborescente de Monte Carlo — technique de recherche qui sélectionne de bons coups en simulant massivement les coups futurs), afin de vérifier qu'il fonctionne et n'est pas trivial.

L'« évaluation » centrale se déroule ainsi : à partir d'une mécanique racine, on construit un jeu complet par recherche arborescente en y ajoutant d'autres mécaniques. On fait jouer ce jeu à 5 IA de niveaux différents — 3 MCTS avec respectivement 100 000, 10 000 et 1 000 simulations, un agent aléatoire et un agent passif — et on quantifie par corrélation de rang (indicateur mesurant la concordance entre deux classements) dans quelle mesure « le rang de force attendu » et « le rang de taux de victoire réel » coïncident. Plus cet ordre est respecté, plus le jeu est considéré « profond, où la maîtrise est récompensée ». Sans entrer dans les formules, l'essentiel est d'utiliser « est-ce que les résultats correspondent à la compétence ? » comme indicateur de qualité par substitution.

Les auteurs introduisent également l'indicateur CITS (Constrained Importance Through Search). Il s'agit d'une méthode pour estimer la contribution de chaque mécanique à la qualité du jeu final, inspirée de la « valeur de Shapley » (concept de la théorie des jeux coopératifs pour répartir équitablement les contributions) de la théorie des jeux. Ce calcul provoquerait normalement une explosion combinatoire, mais MORTAR la rend praticable en ne l'approximant qu'à l'intérieur de l'arbre d'exploration construit lors de la génération. C'est un dispositif permettant de désigner après coup quelle règle a engendré l'intérêt du jeu.

Résultats

Les auteurs ont comparé la construction par recherche arborescente — cœur de l'évaluation — à d'autres méthodes de sélection (aléatoire, par LLM, glouton sur les meilleures performances). D'après le tableau 1 de l'article, MORTAR s'avère le meilleur sur l'indicateur de diversité (score QD 31,18), la valeur maximale (Max CITS 0,59) et moyenne (Mean CITS 0,20) de contribution des mécaniques, ainsi que sur le nombre d'éléments remplissant les cellules (155). Seule la « proportion de jeux devenus jouables » est légèrement dépassée par la méthode glouton (18,24 contre 16,97 pour MORTAR), les auteurs notant une tendance selon laquelle les mécaniques aux meilleures performances donnent plus facilement des jeux jouables.

Les exemples individuels de jeux sont également intéressants. AllyCraft, un jeu généré, présente une corrélation de rang élevée de 0,8, avec une stratégie multi-ligne pour invoquer des alliés et contrôler plusieurs unités, ce qui préserve la profondeur. TreasureHunt en revanche ne dépasse pas 0,4 : les auteurs expliquent que « trouver une fois le chemin optimal réduit la valeur du jeu ». Les jeux à corrélation de rang élevée voient coexister plusieurs stratégies efficaces et se lassent moins — contraste saisissant.

Une évaluation humaine a également été conduite. 10 participants ont joué 6 jeux répartis en 3 paires, en les comparant selon « amusant, nouveau, plaisant, clair, frustrant ». La note globale et la corrélation de rang ont globalement convergé, mais la 3e paire a montré une tendance inverse, et les auteurs eux-mêmes reconnaissent la difficulté d'aligner l'indicateur automatique et les préférences humaines. Dans la 2e paire, les votes « indifférent » étaient nombreux (7 votes) ; les auteurs y voient le signe d'une « complexité excessive rendant le sens difficile à percevoir », et concluent que les mini-jeux requièrent une complexité modérée plutôt que maximale.

Applications pratiques

Comment les créateurs de jeux et de puzzles peuvent-ils utiliser ces travaux ? Voici quelques exemples concrets. Premièrement, la « génération d'idées » de mécaniques. Si je suis en train de créer une petite œuvre de puzzle et que je suis bloqué, on peut envisager de confier les règles existantes comme germe à un dispositif de type MORTAR, puis d'utiliser la mutation de compatibilité pour en faire sortir en masse des « candidats à de nouvelles règles s'intégrant au système existant ». Non comme produit fini, mais comme ébauches parmi lesquelles choisir.

Deuxièmement, la vérification automatique que « la maîtrise est bien récompensée ». La méthode d'évaluation de cet article — faire jouer des IA de niveaux différents et vérifier que le classement tient — peut être réutilisée indépendamment de la génération de mécaniques. Si l'on fabrique un Sokoban-like, on peut préparer plusieurs solveurs à des niveaux de concession différents et les faire tourner comme « mesure de profondeur » simplifiée : les niveaux dont le classement s'effondre peuvent être soupçonnés d'être solubles par chance ou par force brute.

Troisièmement, identifier « quelle règle fonctionne ». L'idée de CITS — décomposer l'intérêt du jeu final en contributions individuelles de chaque règle — est utile pour affiner un jeu où plusieurs mécanismes s'entrecroisent. Si l'on mélange plusieurs gadgets dans un jeu hyper-casual procédural, on peut, à l'instar d'une ablation (expérience consistant à retirer les composants un à un pour déterminer quels éléments de la conception fonctionnent), retirer les gadgets un par un et observer les variations d'indicateurs, pour décider d'éliminer ceux dont la contribution est faible.

Quatrièmement, pour les chercheurs en apprentissage par renforcement (reinforcement learning — cadre d'apprentissage d'actions maximisant la récompense par essais et erreurs), un corpus varié de jeux où les différences de compétence sont mesurables constitue en lui-même un terrain d'entraînement pour tester la généralisation des agents (leur capacité à gérer des situations inconnues), estiment les auteurs. L'utilité dépasse le côté créateur et s'étend au côté entraîneur d'IA — dualité qui fait l'originalité de cette recherche.

Limites

Les limites sont exposées sans détour. Ce que les auteurs reconnaissent eux-mêmes en premier, c'est la pauvreté visuelle. Le rendu est réduit au strict minimum, sans animation et avec peu de sprites (images des personnages). Les participants à l'évaluation utilisateur ont eux aussi répété que la maigreur visuelle leur posait problème, ainsi que le mentionne l'article. Ensuite, le LLM utilisé est le GPT-4o-mini, relativement modeste — un modèle plus puissant pourrait produire des mécaniques et un code plus raffinés. De plus, le cadrage en vue de dessus 2D restreint l'espace d'exploration, l'initialisation du classement et le nombre d'itérations de la recherche arborescente créent un équilibre entre qualité et coût de calcul, et — point le plus important — il n'existe actuellement aucun mécanisme permettant au concepteur de guider l'exploration.

Ce que Fukai signale ici, c'est le biais de l'indicateur d'évaluation lui-même. L'idée d'utiliser « l'IA la plus forte gagne-t-elle bien ? » comme indicateur de substitution est claire, mais c'est aussi une mesure favorisant les jeux compétitifs où les différences de niveau ressortent. Les jeux fondés sur l'expérience narrative ou l'atmosphère, ou encore les expériences du type « peu importe qui joue, même fin », risquent de mal scorer. D'ailleurs, le fait que l'indicateur automatique et les préférences divergent dans la 3e paire de l'évaluation humaine pourrait signaler cette frontière.

Un autre point qui m'interpelle est la modestie de l'échelle. L'évaluation humaine porte sur 10 personnes et 6 jeux — les auteurs le qualifient eux-mêmes de « small ». Même avec une moyenne sur 5 exécutions, la généralisation des conclusions nécessite une validation supplémentaire. De plus, il s'agit d'un preprint arXiv, et je n'ai pu trouver de traces d'une large discussion à la date de rédaction — il convient de l'accueillir comme une proposition nouvelle dont l'évaluation n'est pas encore fixée.

Lecture par Fukai

Ce qui suit relève de mon interprétation — avertissement préalable. Je souhaite positionner cette recherche dans le mouvement où le centre de gravité de la génération automatique se déplace des « réalisations visibles (niveaux, terrains) » vers les « structures invisibles (relations entre règles) ». Dans le vocabulaire de la critique de conception, ce que MORTAR entreprend s'apparente à « rendre l'intérêt opérationnel, en le définissant comme le degré auquel la compétence se reflète dans les résultats ». Traduire cet intérêt flou d'abord par « le classement de compétence se préserve-t-il ? », puis décomposer cette contribution à l'échelle de chaque règle — cette double traduction est, à mon sens, le cœur de la publication. La mesure n'est pas parfaite, mais rendre les mécaniques « dicibles » constitue en soi une valeur.

Pour aller plus loin

Pour ceux qui souhaitent approfondir, je trace quelques pistes susceptibles de servir de carte. Dans l'entourage de Togelius, commun avec cet article, on trouve ScriptDoctor (Earle et al., 2025), qui génère des puzzles PuzzleScript par LLM et recherche arborescente — présenté sur ce site précédemment. GAVEL (Todd et al., 2024), qui fait évoluer des jeux de plateau par qualité-diversité, et Pixie (Cook, 2025), qui fait évoluer des mécaniques au niveau du code, révèlent, placés à côté de MORTAR, les différences de conception entre « ce que l'on génère » et « comment on l'évalue ». Les lire ensemble devrait permettre de saisir les contours du domaine de la conception automatique de jeux.

Pour ma part, j'attends avec intérêt la prochaine étape que les auteurs eux-mêmes mentionnent parmi les limites : une version où le concepteur peut guider l'exploration. Un outil d'idéation ne devient un vrai partenaire de terrain que lorsqu'il peut « générer selon nos intentions ». Une tasse de café bien serré à la main, toucher soi-même les jeux générés est peut-être la meilleure façon d'aborder cet article.

Références

Articles et ressources consultés pour cet article :

・MORTAR: Evolving Mechanics for Automatic Game Design (Nasir, Li, James, Togelius, 2026, preprint arXiv)

・Étude connexe : ScriptDoctor: Automatic Generation of PuzzleScript Games via LLMs and Tree Search (Earle et al., 2025)

・Étude connexe : GAVEL: Generating Games via Evolution and Language Models (Todd et al., 2024)

・Étude connexe : Pixie: Code-level Mechanic Generation for Game Designers (Cook, 2025, AIIDE)