Construire OsuGAI : des beatmaps osu! standard générées par IA

OsuGAI est le premier modèle de DanceGAI pour osu! standard, le mode d’origine d’osu! : des cercles, des sliders et des spinners répartis sur tout le playfield. Il est sorti aujourd’hui en bêta, aux côtés de ManiaGAI pour osu! mania. Ce rapport explique comment il représente une map, sur quoi il a appris, comment il a été entraîné, ce que nous avons mesuré — et, tout aussi franchement, ce qu’il rate encore.

Pourquoi osu! standard est plus difficile qu’osu! mania

Une chart osu! mania, ce sont des notes dans des colonnes : un générateur décide quand arrive une note et dans laquelle des 4 à 9 colonnes elle tombe. En osu! standard, chaque objet a aussi une position sur un playfield de 512 × 384, et le joueur doit s’y déplacer. Cela ajoute trois problèmes que mania n’a pas :

• Un mouvement en deux dimensions. L’espacement, les angles des jumps et le flow entre les objets font l’essentiel de ce qui rend une map standard agréable ou non — et ce sont des grandeurs continues, pas un choix entre quelques colonnes.
• La géométrie des sliders. Un slider est une courbe avec une longueur, une vitesse et parfois des répétitions ; il doit coller à la musique et aux objets qui l’entourent.
• La lisibilité. Les objets apparaissent avant qu’on les frappe, se chevauchent et s’empilent. Une map peut avoir un timing parfait et rester impossible à lire.

La représentation : le gameplay d’abord, les objets de l’éditeur ensuite

La façon évidente d’apprendre osu! standard à un modèle est de lui donner les objets de l’éditeur — « cercle en (x, y) », « slider avec ces points de contrôle ». C’est la famille d’approches que nous avons essayée en premier. OsuGAI v1 décrit au contraire une map telle qu’elle se joue, puis la retransforme en objets. Chaque temps tient en cinq tokens :

• Un token d’interaction : l’état du bouton sur la durée du temps, échantillonné à 48 cases par temps — appuyé ou relâché, rien d’autre. Un tap est un appui court ; un slider ou un spinner, un appui long. Le token est l’un des 4 096 motifs de 48 cases les plus fréquents dans les charts d’entraînement, qui couvrent 99,87 % des temps d’entraînement et 99,69 % des temps mis de côté.
• Quatre tokens spatiaux : la position du curseur à quatre moments au plus dans le temps — chaque appui, chaque relâchement, puis les appuis les plus longs découpés à intervalles égaux. Les positions sont sur une grille de 4 pixels (128 × 96 cases), donc l’erreur d’arrondi maximale est de 2,83 pixels ; un emplacement inutilisé reste vide.

Cela donne cinq emplacements par temps et un vocabulaire unique de 16 385 tokens (4 096 motifs de bouton plus 12 289 positions). Les moments que décrivent les tokens spatiaux se déduisent du seul motif de bouton, si bien que le modèle n’a jamais à apprendre les types d’objets.

Pourquoi séparer le gameplay voulu de la représentation de l’éditeur ? Pour deux raisons, toutes deux mesurées sur des replays humains avant d’entraîner quoi que ce soit. D’abord, les choix de l’éditeur sont en grande partie invisibles en jeu : à partir du seul curseur, on ne distinguait un slider court d’un cercle que dans 43–45 % des cas — les détails au niveau des objets sont donc des décisions que le décodeur peut prendre, pas quelque chose que le modèle doit deviner. Ensuite, la description du gameplay ne perd presque rien d’important : les maps reconstruites à partir d’un état de bouton idéalisé et d’une trajectoire de curseur humaine ont été touchées par les replays d’autres joueurs aussi souvent que les maps reconstruites à partir d’une description qui connaît les objets (97,9 % contre 98,0 %). Utiliser à la place les vrais états de bouton des joueurs faisait tomber ce chiffre à 78,5 % — les vrais appuis sont trop bruités pour qu’on apprenne dessus, c’est pourquoi le token de bouton est idéalisé.

Les données d’entraînement

Le corpus est composé de maps osu! standard ranked, approved et loved — 117 918 charts sur 117 920 ont été converties avec succès. Les ensembles de validation et de holdout sont disjoints par musique : aucune de leurs musiques n’apparaît dans l’entraînement. Comme pour ManiaGAI, le timing de chaque chart a d’abord été recalé sur la grille de notre propre détecteur de timing, si bien que le modèle s’entraîne sur le même type de grille que celle qu’il reçoit en génération. Aucune chart n’a été écartée pour cause de difficulté.

D’où viennent les positions du curseur : le replay Auto d’osu!lazer

Un fichier de map indique où sont les objets, pas comment le curseur se déplace entre eux. Nous tirons les tokens spatiaux du replay Auto d’osu!lazer — le joueur parfait intégré au jeu. Nous avons porté sa logique de curseur en Python et l’avons comparée au vrai jeu sur 20 maps : 264 716 frames, le même nombre de frames, zéro écart de bouton ou de stacking, 0,014 pixel d’écart moyen. Les maps décodées à partir des trajectoires de curseur d’Auto ont été touchées par les replays humains d’autres joueurs dans 99,7 % des cas, sur un benchmark de 91 maps.

Une réserve honnête : Auto n’est pas un humain. Il suit le tracé exact de chaque slider, donc son curseur est proche de « la géométrie d’origine du slider écrite sous forme de positions » — 72 % des tracés de sliders d’origine peuvent être retrouvés à partir d’Auto à 4 pixels près, contre 1 % à partir d’un seul replay humain. OsuGAI v1 apprend donc où un mapper place les choses, pas comment les gens se déplacent réellement.

L’architecture

1. Musique
2. Grille de timing
3. Planner
4. Noter
5. Décodeur
6. .osu / .osz

OsuGAI repose sur le même moteur que ManiaGAI (décrit dans Planner et Noter), avec les parties propres au mode remplacées :

• Planner (réutilisé). Un petit modèle de diffusion, inchangé depuis nos premiers travaux sur osu! standard, planifie chaque passage de la musique avant qu’aucun objet n’existe : son niveau d’étoiles et une description du style — part de sliders, caractère des angles, irrégularité de l’espacement, espacement des streams et rythme.
• Noter (nouveau). Un transformer de type MaskGIT d’environ 64,1 millions de paramètres remplit les cinq tokens de chaque temps, en suivant le plan, l’audio et les réglages de difficulté (circle size, approach rate, overall difficulty et slider velocity). En plus de la précision sur la position exacte, son entraînement accorde un crédit partiel à une position qui tombe à moins de 16 pixels de la cible.
• Décodeur (à base de règles, gère les répétitions). Retransforme le gameplay en objets : un appui devient un cercle ; un appui long devient un spinner quand le curseur tourne autour du centre pendant au moins 1,5 temps, sinon un slider — la ligne, l’arc ou la courbe la plus simple qui garde la bille du slider près de la trajectoire prédite. Des allers-retours nets et régulièrement espacés deviennent un slider à répétition. Les new combos suivent une règle fixe.

L’entraînement : quatre rounds

Le Noter a été initialisé à partir de notre précédent modèle osu! standard et entraîné en quatre rounds de quatre epochs limitées dans le temps (environ 46 minutes chacune) — en tout, environ 14 heures sur une seule RTX 4070 Ti SUPER (16 Go), avec un pic d’environ 6 Go de mémoire GPU. Après chaque round, nous avons généré un ensemble d’évaluation : 8 musiques mises de côté × 22 réglages = 176 maps.

• La perte de validation est passée de 3,1389 à 2,9570 au fil des quatre rounds.
• Validité structurelle : les 176 maps d’évaluation étaient des maps osu! standard valides à chaque round — objets conformes, aucune violation d’emplacement.
• La difficulté et le style réagissent : le nombre d’étoiles mesuré a augmenté avec la cible sur 8 musiques sur 8, et chacun des quatre axes de style a fait évoluer la map dans le bon sens sur 8 musiques sur 8 — même si le suivi du plan section par section reste faible.
• Déterministe : la même musique avec la même seed donne des fichiers .osu identiques à l’octet près.

Vitesse. Sur ce GPU de développement, huit difficultés de Flower Dance (4:22) ont pris environ 16–18 secondes pour les étapes chronométrées — préparation de l’audio, timing, caractéristiques audio, planification et environ 11–12 secondes de génération des notes ; le décodage et l’écriture des fichiers ajoutent en moyenne environ 0,6 seconde par map, sur le CPU. C’est un benchmark local : la production tourne sur un autre GPU, dans le cloud, et nous n’avons pas encore mesuré la latence d’OsuGAI en production.

Limites

Une map valide n’est pas forcément une map amusante, et aucun des chiffres ci-dessus ne dit que les maps d’OsuGAI sont bonnes à jouer en compétition. Ce que nous savons ne pas aller :

• Difficulté trop élevée. Les maps sortent plus difficiles que la cible, et beaucoup plus en haut de l’échelle : sur Flower Dance, des cibles de 7,43 ; 8,71 et 10 ont mesuré 9,28 ; 13,49 et 13,99 étoiles. Le site ne propose donc que des cibles de ★1 à ★6 et affiche toujours le nombre d’étoiles mesuré.
• Des sliders qui se croisent. 3,3 % des sliders générés au dernier round se recoupent eux-mêmes (2,4 % après le premier round), contre 0,1 % dans les maps d’origine.
• Artefacts de géométrie des sliders. Certains sliders atteignent la limite de vitesse (2,8 % au dernier round), et les sliders à répétition sont plus rares que dans les maps humaines (6,1 % des sliders contre 21 %).
• Supervision par Auto. Les trajectoires du curseur sont celles d’Auto, pas celles de joueurs : le modèle apprend le placement des objets, pas le mouvement humain.
• Débordement et repli du vocabulaire. 0,58 % des temps d’entraînement nécessitent plus de quatre positions ; seules les quatre premières sont conservées. 0,13 % des temps sortent des 4 096 motifs de bouton et utilisent le plus proche. Ce sont les maps très denses qui sont le plus touchées.
• Pas encore de tests de jeu à grande échelle par des humains. Toutes les vérifications jusqu’ici sont automatiques ou basées sur des replays enregistrés. C’est avec la bêta que cela commence.

La suite

• Un meilleur calibrage de la difficulté — des cibles fiables, et le retour de toute la gamme d’étoiles.
• Une géométrie des sliders plus propre — moins de sliders qui se croisent et de vitesses plafonnées, des répétitions plus naturelles.
• Des données de gameplay humain — apprendre comment les gens se déplacent, pas seulement où sont les objets.
• Un contrôle du style plus fort — des barres que la map suit section par section, pas seulement en moyenne.
• Plus de modes d’osu! — osu! taiko et osu! catch sont les prochains sur la feuille de route.

Vous découvrez ce mode ? Qu’est-ce qu’osu! standard ? explique le jeu lui-même ; la page technologie présente le moteur qu’OsuGAI partage avec ManiaGAI.