Özkan : entraîner ensemble l'IA qui génère les niveaux et l'IA qui les résout — lu par Fukai

L'essentiel d'abord (TL;DR)

Que se passe-t-il si, au lieu de préparer séparément un mécanisme de génération automatique des niveaux de jeu et une IA chargée de les jouer réellement, on les « fait grandir ensemble » ? Cet article de Miraç Buğra Özkan, de l'Istanbul Technical University (soumis à arXiv en octobre 2025 comme preprint ; le texte ne mentionne aucune évaluation par les pairs), tente l'expérience dans un monde 3D sous Unity. Le dispositif fait apprendre simultanément deux agents qui observent chacun les résultats de l'autre : un colibri qui butine du nectar (le rôle du joueur) et une île flottante qui décide où semer les fleurs (le rôle de générateur de niveaux).

Résultat : le colibri finalement entraîné parvient à collecter toutes les fleurs dans environ 90,2 % de 100 configurations jamais vues auparavant (Table III de l'article). Du côté de l'île qui place les fleurs, les agencements n'étaient au départ que pentes abruptes et chevauchements désastreux, mais à mesure que l'apprentissage progresse, ils convergent vers des agencements « faciles à jouer ». Mettre dans une même boucle celui qui génère et celui qui résout fait que la difficulté s'ajuste d'elle-même — l'intérêt de cet article tient tout entier dans ce seul point.

Introduction — qui l'a écrit, et où

L'auteur est Miraç Buğra Özkan, du département Intelligence artificielle et ingénierie des données de l'Istanbul Technical University. C'est un article en auteur unique. Le document est mis en page à la manière d'un gabarit de conférence de type IEEE, mais le corps du texte ne précise ni le nom d'une conférence de présentation, ni le fait d'avoir été évalué par les pairs. Je le traite donc comme un « preprint arXiv (arXiv:2510.15120, soumis en octobre 2025, peut-être pas encore passé par une évaluation par les pairs) ».

Pour être honnête, si j'ai choisi cet article aujourd'hui, ce n'est pas pour sa nouveauté. Il a été soumis il y a environ neuf mois, ce qui sort de la fenêtre des « 60 derniers jours » que je vise habituellement. Je le retiens tout de même parce que le texte est intégralement lisible, et surtout parce qu'il est explicitement précisé que la base du système est une modification du cours officiel Unity « ML-Agents: Hummingbirds ». Autrement dit, un développeur individuel suffisamment habile peut raisonnablement le reproduire chez lui. Cela correspond aussi à ma politique habituelle de privilégier les articles proches de l'implémentation.

Une précaution d'abord : il ne s'agit pas, à proprement parler, d'un article sur les « puzzles ». C'est une tâche plutôt d'exploration et de collecte, où un colibri vole dans un terrain 3D pour récolter du nectar de fleurs. Néanmoins, l'idée de placer dans la même boucle d'apprentissage celui qui génère le niveau et celui qui le résout mérite amplement d'être rapportée par quiconque conçoit des puzzles ou des niveaux. C'est ce que je suis venu y lire.

Contexte — les limites respectives du PCG et de l'apprentissage par renforcement

Commençons par mettre les termes à plat. Le PCG (Procedural Content Generation, génération de contenu procédurale) désigne la technique consistant à créer automatiquement, par algorithme, des niveaux, des terrains, des placements d'objets, etc. Autrefois, on créait les terrains par des systèmes à base de règles ou des fonctions de bruit (des mécanismes qui transforment le hasard en motifs d'apparence naturelle), mais l'auteur les caractérise comme « peu adaptables et peinant à garantir la jouabilité ou l'équilibrage ».

Vient ensuite l'apprentissage par renforcement (reinforcement learning ; un cadre où un agent agit dans un environnement et apprend par essais et erreurs à maximiser la récompense qu'il reçoit). Ces dernières années, de plus en plus de méthodes s'en servent pour apprendre, à partir du dialogue avec l'environnement, une politique (comment agir dans telle situation). Mais, selon l'auteur, la plupart des PCG utilisant l'apprentissage automatique (calcul évolutionnaire ou méthodes à base de recherche) séparent l'étape de génération de l'agent qui joue réellement, ce qui rend l'articulation en temps réel difficile.

C'est cette faille que l'article cherche à combler. Il ne sépare pas « créer » et « jouer » en deux étapes distinctes, mais les enferme dans une seule boucle de rétroaction. L'île (génération) observe les résultats du colibri (résolution) et ajuste ses agencements ; le colibri, de son côté, réapprend à voler en fonction de ces changements. Les deux évoluent simultanément — l'auteur situe cela dans le courant de recherche récent où l'environnement et la politique se développent conjointement.

Approche — deux agents et un soin particulier porté aux « observations »

Le dispositif se compose de deux agents créés sous Unity. L'un est le colibri (le rôle de résolution), l'autre l'île flottante (le rôle de génération). Tous deux apprennent par PPO (Proximal Policy Optimization ; une méthode d'apprentissage par renforcement qui « écrête » les mises à jour de la politique pour éviter qu'elles ne varient trop d'un coup, ce qui stabilise l'entraînement). J'omets les formules mathématiques ; retenez simplement qu'il s'agit d'une méthode qui corrige la politique « dans la direction qui semble meilleure, mais par pas jamais trop grands ».

Les observations (entrées de capteurs) reçues par le colibri sont travaillées avec soin. Elles comprennent des rayons lancés vers l'avant, le haut et le bas (raycasts, un mécanisme qui détecte fleurs, obstacles et terrain en projetant des rayons), le vecteur relatif vers la fleur la plus proche, sa propre vitesse et son orientation, la normale du terrain juste en dessous (la direction de la pente), et même le rayon de dispersion r et la densité c des fleurs fixés par l'île. L'auteur indique que ces indices auxiliaires (auxiliary inputs) stabilisent l'apprentissage. La récompense suit une logique simple : des points en plus pour la collecte de nectar, des points en moins pour les collisions, un agencement trop clairsemé ou un temps trop long.

L'île (rôle de génération) observe le placement des obstacles, la position de départ du colibri et les résultats de l'épisode précédent (récompense moyenne, nectar collecté, nombre de pas jusqu'à la première fleur, nombre de collisions), et produit en sortie deux valeurs continues : le « rayon de dispersion r » et la « densité c » des fleurs. Les mauvais agencements — fleurs qui se chevauchent, placées sur une pente abrupte, espacement irrégulier — sont pénalisés (malus). Le scénario est que cela guide progressivement le colibri vers des agencements faciles à jouer.

Résultats — la lecture des chiffres

L'auteur ne rapporte pas seulement les indicateurs finaux, mais aussi le déroulement chronologique des essais successifs. Dans la configuration initiale (version pauvre en observations), l'apprentissage était instable : même après 5 millions de pas, le colibri ne collectait en moyenne que 6,2 fleurs par épisode, et il fallait plus de 150 pas pour atteindre la première fleur. En y ajoutant la normale du terrain et l'orientation (deuxième essai), la collecte moyenne montait à 10,9 à 8 millions de pas, et les collisions diminuaient de 23 %. Comparé à l'état sans rien, on voit que les indices auxiliaires sont efficaces.

Dans le troisième essai, où une boucle de rétroaction a été ajoutée à l'île, le nombre de pas jusqu'à la première fleur s'est réduit à 44, et des comportements sont apparus spontanément : voler haut pour avoir une vue d'ensemble dans les agencements clairsemés, voler près du sol dans les agencements denses. Cependant, aux alentours de 12 millions de pas, de fortes oscillations des paramètres d'agencement (r, c) ont provoqué de l'instabilité. Dans le quatrième essai, où les mauvais agencements ont été pénalisés pour freiner les mises à jour des paramètres, la courbe de récompense s'est lissée, convergeant vers une récompense moyenne de 1,35 par pas sur les 5 derniers millions de pas, avec la totalité des fleurs collectées dans 92 % des épisodes.

Une étude d'ablation (une expérience qui retire les composants un par un pour vérifier laquelle des parties de la conception est efficace) a également été menée. Sans la normale du terrain, les collisions augmentent de 40 % ; sans les raycasts, atteindre la première fleur prend deux fois plus de temps ; sans les paramètres d'agencement de l'île, l'agent cesse de s'adapter et revient à un vol en zigzag. Dans la figure 8, le taux de réussite tombe à 92 % avec tout, 84 % sans la normale du terrain, 61 % sans les paramètres d'agencement, et jusqu'à 38 % sans les capteurs de rayons. Le résultat final sur 100 agencements inédits est un taux de réussite de 90,2 %, une collecte moyenne de 12,4, et 1,4 collision, les meilleurs résultats se situant autour d'une densité d'environ 0,5 et d'un rayon d'environ 7 (figure 9).

Applications — comment un créateur peut s'en servir

Voici quelques exemples concrets. Premièrement, si l'on construit un générateur de niveaux de type Sokoban-like — là où l'on procéderait normalement en deux temps, « générer, puis vérifier avec un solveur séparé » — on peut envisager d'entraîner générateur et solveur ensemble dans la même boucle. En remplaçant l'équivalent du « nombre de pas jusqu'à la première fleur » du colibri par, sur votre plateau, le « temps de recherche avant le premier coup », le « nombre de coups » ou le « taux de blocage », le générateur obtient un point d'appui pour ajuster lui-même la difficulté.

Deuxièmement, pour du PCG hyper-casual, le (rayon r, densité c) de l'île se relit directement comme des paramètres de génération tels que la « densité d'apparition des ennemis », l'« espacement des objets » ou la « taille des zones sûres ». Il est révélateur que la meilleure performance de cet article n'ait pas été obtenue à une valeur extrême, mais à une valeur médiane (densité d'environ 0,5). Une conception qui pénalise l'écart par rapport à une valeur cible peut être réutilisée comme mécanisme évitant automatiquement les deux extrêmes, trop facile et trop difficile.

Troisièmement, le playtest automatisé à grande échelle. Il s'agit de faire tourner un agent solveur entraîné par PPO comme « joueur substitut bon marché », pour estimer avant la sortie le niveau de difficulté à partir du taux de réussite et du nombre de collisions. En outre, le curriculum implicite (le passage progressif d'agencements faciles vers des agencements difficiles) que produit la boucle de rétroaction constitue un modèle pour concevoir des tutoriels et des courbes de difficulté de début de partie. Enfin, la leçon la plus discrète mais la plus efficace : donner aux robots les bonnes observations (position relative à l'objectif, inclinaison du sol sous les pieds) suffit à elle seule à stabiliser leur comportement — et cela fonctionne aussi sur le terrain.

Limites — ce que l'auteur reconnaît, et ce que j'ai remarqué

Commençons par les faiblesses que l'auteur reconnaît lui-même. En début d'apprentissage s'est produit un « détournement de récompense » (reward hacking) : le colibri survolait des zones denses sans réellement collecter de nectar, pour engranger seulement des points d'évitement de collision. Quand le rayon est trop grand, les fleurs deviennent extrêmement clairsemées et la recherche devient inefficace ; par ailleurs, l'ajustement heuristique de l'île peut faire osciller (r, c) et déstabiliser l'entraînement. En outre, il n'y a qu'un seul colibri ; l'extension à plusieurs agents coopérants ou en compétition est présentée comme un travail futur.

À partir d'ici, je précise clairement qu'il s'agit de points que j'ai remarqués moi-même à la lecture. D'abord, alors que le résumé et la section méthode indiquent que l'île, le rôle générateur, est « entraînée par PPO », la section résultats décrit, pour le troisième essai, un ajustement de (r, c) par une « heuristique de simple montée de colline (hill-climbing) », et la section des limites elle-même mentionne, comme travail futur, le fait de « faire apprendre la politique de génération de l'île par RL plutôt que par heuristique ». Ce qui pilotait réellement le côté générateur me semble, à la lecture, incohérent au sein même du texte. Je ne peux pas trancher, mais le lecteur ferait bien d'être prudent.

Autre point : la section implémentation indique un « espace d'observation à 53 dimensions », mais en additionnant le détail du Tableau I on n'arrive qu'à 24 dimensions. Les chiffres ne concordent pas. De plus, cet article est un preprint en auteur unique, sans conférence de présentation nommée, et sans comparaison de référence croisée avec d'autres jeux. Les résultats sont le compte-rendu des essais d'un seul système, et ne doivent pas être reçus comme une loi générale. Et, pour le répéter, il s'agit d'une tâche de collecte et de déplacement ; sa généralisation à de véritables puzzles n'est pas vérifiée dans cet article.

La lecture de Fukai

Je précise que ce qui suit est mon interprétation. Je voudrais situer cette recherche comme une tentative de faire redescendre la « conception d'environnement non supervisée » (unsupervised environment design) — cette lignée qui fait de l'environnement lui-même un objet d'apprentissage, à la manière de PAIRED ou POET — du calcul à grande échelle vers la portée d'un tutoriel Unity accessible à un particulier. La valeur de ce travail tient moins au chiffre de 90,2 % qu'au fait de montrer qu'un matériel pédagogique ordinaire de ML-Agents peut se transformer en une boucle où générateur et solveur coévoluent. Dans le vocabulaire de la critique de conception, je lis cela comme la démonstration tangible d'une automatisation à demi de la « molette de réglage de la difficulté », en faisant en sorte que le niveau lui-même réponde au joueur.

Conclusion

Pour qui veut approfondir, voici quelques articles qui peuvent servir de carte. Comme colonne vertébrale théorique de la coévolution de l'environnement et de la politique, on peut citer Dennis et al., « Emergent complexity and zero-shot transfer via unsupervised environment design » (NeurIPS 2020, PAIRED), et Ecoffet et al., « First return, then explore » (NeurIPS 2021). Pour la vue d'ensemble du PCG, la synthèse de Togelius et al. sur le PCG à base de recherche fait figure de classique. Pour suivre le fil qui relie la génération à l'expérience du joueur, les travaux sur le PCG piloté par l'expérience (EDRL) autour de Super Mario constituent un bon point d'entrée. Lire cet article comme « la parcelle où un développeur solo peut mettre la main » à l'intérieur de cette grande carte permet d'en saisir plus facilement la position.

Références

Articles et ressources connexes cités dans cet article :

・Procedural Game Level Design with Deep Reinforcement Learning (Miraç Buğra Özkan, 2025, preprint arXiv arXiv:2510.15120)

・Étude connexe : Emergent Complexity and Zero-shot Transfer via Unsupervised Environment Design (Dennis et al., 2020, NeurIPS)

・Étude connexe : First return, then explore (Ecoffet et al., 2021, Nature / NeurIPS)

・Outil : Unity ML-Agents Toolkit (la base d'implémentation de cet article)