Comment fonctionne ManiaGAI

DanceGAI est l’équipe derrière ManiaGAI, un générateur de beatmaps osu! mania par IA. DanceGAI construit une infrastructure d’IA qui transforme la musique en expériences jouables, et ManiaGAI est son premier produit : vous envoyez une musique, et il génère un mapset osu! mania complet et jouable — timing, notes et un éventail de difficultés — dans un fichier .osz standard. La musique peut être un fichier audio envoyé ou la musique d’un beatmapset osu! dont vous donnez le lien ; dans les deux cas, seul l’audio est utilisé, jamais les maps existantes. La version 2 du système est en ligne sur ce site. osu! mania est le premier format de sortie : le système est conçu pour les jeux de rythme à défilement vertical (VSRG) en général.

Cette page explique comment il fonctionne et pourquoi il est conçu ainsi. Nous sommes transparents sur l’architecture et les choix d’ingénierie ; nous ne publions pas les détails qui permettraient de le reconstruire. Quand un chiffre n’est pas encore public, la page le dit plutôt que de deviner.

Résumé technique

Une beatmap n’est pas une transcription

La façon évidente de concevoir la génération automatique de beatmaps, c’est « audio en entrée, réseau de neurones, notes en sortie ». En pratique, cette approche produit des maps qui suivent techniquement la musique mais qui sont désagréables à jouer. Une bonne map osu! mania tient plus de l’arrangement que de la transcription : un mapper décide quels sons méritent des notes, quelle densité doit avoir une section, où placer un jack ou une long note, comment les patterns circulent entre les mains, et comment tout cela change entre une difficulté Easy et une Expert.

ManiaGAI traite donc la génération de beatmaps comme une suite de problèmes distincts — comprendre la musique, planifier le gameplay, placer les notes et vérifier le résultat :

1. Musique
2. Compréhension
3. Planification
4. Génération
5. Affinage
6. Beatmap

1. Compréhension musicale

Tout ce qui suit dépend d’une image précise de la musique. La première étape transforme l’audio brut en deux choses : une grille de timing, et une représentation musicale haute résolution de chaque instant de la musique.

Timing. Les activations de temps et de premiers temps de mesure proviennent de Beat This, un modèle open source de suivi de beat. Transformer ces activations en grille de timing osu! — BPM et offset, y compris pour les musiques dont le tempo change — relève de notre propre méthode d’ajustement de grille, qui produit la même famille de grilles que celle sur laquelle les modèles de génération ont été entraînés. Le timing est ce que les joueurs remarquent en premier : une map décalée de quelques millisecondes est injouable, aussi bons que soient ses patterns ; c’est donc traité comme un problème de premier plan, pas comme une étape de prétraitement.

Caractéristiques musicales. L’audio est encodé avec MERT-v1-95M, un modèle auto-supervisé de représentation musicale, puis aligné sur la grille de timing — les modèles voient donc la musique temps par temps : attaques, texture, intensité et leur évolution au fil de la musique. Les passages silencieux sont détectés séparément, pour qu’aucune note n’y soit placée.

2. Planification de la beatmap

Le choix de conception central de ManiaGAI est de séparer ce qui doit se passer de la façon dont les notes sont placées.

Un modèle de planification dédié lit la représentation musicale et décide de la structure de gameplay de toute la musique avant qu’aucune note n’existe : quelle densité pour chaque section, quels types de patterns à quel endroit, comment la difficulté doit monter et descendre, et comment tout cela s’accorde avec la difficulté et le style demandés. Sa sortie est un plan qui décrit la map section par section — difficulté locale et dosage des long notes, des jacks et des autres types de patterns — pas des notes.

Le planificateur est un modèle de diffusion gaussienne (environ 6 M de paramètres). Il génère le plan de toutes les sections de la musique conjointement, conditionné par la musique, le nombre de touches, ainsi que la difficulté et le style visés. La diffusion se prête bien à cette tâche : un plan est une description lisse et continue d’une musique, et le générer d’un bloc permet au planificateur d’équilibrer toute la musique en même temps.

Planifier à ce niveau donne au système ce qui manque à un modèle note par note : une vue d’ensemble de la musique. Un refrain peut être prévu pour frapper plus fort que le couplet qui le précède ; un breakdown peut être prévu pour respirer.

3. Génération des notes

Un second modèle transforme le plan en placement réel des notes — quelles colonnes, quelles notes sont des taps et lesquelles sont des long notes, comment les patterns s’enchaînent. La planification fixe la structure ; la génération des notes transforme cette structure en notes jouables qui suivent à la fois le plan et l’audio.

Le modèle de notes est un transformer non autorégressif de type MaskGIT (environ 51 M de paramètres). Les maps sont représentées sous forme de tokens de patterns discrets, et au lieu de les écrire un par un du début à la fin, le modèle remplit toute la map puis l’affine en plusieurs passes — en validant les notes dont il est sûr et en revenant sur les autres. Chaque passe voit le contexte des deux côtés de chaque section, et c’est ce qui garde les patterns cohérents sur toute une musique. La façon dont ces passes sont ordonnancées sur une musique relève de notre propre méthode d’affinage.

Pourquoi ManiaGAI utilise un Planner + Noter (en anglais) →

4. Génération contrôlable

ManiaGAI n’est pas un système où l’on « génère en croisant les doigts ». Une même musique peut être générée avec des réglages explicites, et ces réglages font partie de ce que les modèles ont appris à suivre :

• Nombre de touches — de 4K à 9K.
• Difficulté — n’importe quelle sélection de nombres d’étoiles de ★1 à ★10. Une musique produit un mapset complet, d’Easy à Expert, en une seule génération.
• Style — des caractéristiques de gameplay comme la proportion de long notes et la quantité de jacks, de LN inverse, de LN courtes et de delay que contient une map, chacune réglable dans le générateur.
• Densité — découle de la difficulté visée et du plan, plutôt que d’une règle fixe.

Chaque difficulté est générée à partir de la même compréhension de la musique, si bien qu’un mapset se lit comme une seule famille de maps plutôt que comme des maps sans lien entre elles. Prochaine étape : nous travaillons sur des représentations de style apprises — décrire un style de mapping par l’exemple plutôt que par une poignée de curseurs.

5. Validation et contrôle qualité

Avant qu’une map ne vous parvienne, le système la vérifie :

• Timing — les points de timing écrits sont comparés à la grille détectée.
• Notes invalides et injouables — les notes qui se chevauchent, les long notes cassées et les placements que le jeu ne peut pas représenter sont corrigés, et aucune note n’est placée sur un audio manifestement silencieux.
• Difficulté mesurée — le nombre d’étoiles de chaque map est mesuré avec le même algorithme de calcul d’étoiles qu’osu!, et la difficulté est nommée d’après la valeur mesurée, pas d’après celle demandée.
• Cohérence au sein du mapset — une map qui sort plus facile que celle censée se trouver en dessous, ou de difficulté quasi identique à sa voisine, est écartée plutôt que livrée. Dans le générateur, vous voyez quelles étoiles ont été écartées et pourquoi.
• Validité du résultat — le résultat est empaqueté dans un .osz standard avec audio, fond et hitsounds, qui s’importe directement dans osu!.

En chiffres

Musiques dans le jeu d’entraînement

86 255

Maps d’entraînement

150 622

Mappers

~14 500

Audio unique

4 227 h

Caractéristiques d’entraînement sur disque

~0,7 To

Calcul d’entraînement (enregistré, lignée de production)

~580 heures GPU

Dernier entraînement du modèle de notes

~4 jours

Paramètres des modèles

~57 M (51 M notes + 6 M planificateur)

Génération d’un mapset complet

~20 s

Modes de touches

4K–9K

Plage de difficulté

★1–★10

Difficultés par génération

jusqu’à 10 (moins pour les musiques longues)

Données d’entraînement

Les modèles de production apprennent à partir de 150 622 maps osu! mania faites par des humains, sur 86 255 musiques — 4 227 heures d’audio unique — réalisées par environ 14 500 mappers. Dans un système comme celui-ci, l’essentiel du travail n’est pas le modèle mais les données : décider ce qui constitue une map dont il vaut la peine d’apprendre, s’assurer que le timing de chaque exemple d’entraînement est juste, et représenter les maps sous une forme qui capture ce qui les rend jouables.

Explorer le dataset d'entraînement (en anglais) →

Évaluation : précision du timing

Nous avons comparé notre timing au timing humain sur tous les mapsets osu! mania ranked à tempo unique et constant que nous pouvions évaluer — 2 501 musiques — aux côtés du mode timing de l’outil open source Mapperatorinator et de ManiaGAI v1, notre détecteur précédent. Une musique est considérée comme correcte quand le BPM correspond à celui du mapper (à la moitié ou au double près) et que la phase du beat est dans la tolérance indiquée.

Musiques ranked à tempo constant uniquement ; « une seule ligne de timing » = la musique a été timée avec une seule ligne, comme l’a fait le mapper (une ligne en trop sur une musique à tempo constant est un faux changement de tempo). Mesuré sur une configuration proche de celle en production, mais pas identique.

Lire le benchmark de timing complet (en anglais) →

Entraînement

Le planificateur et le modèle de notes sont entraînés séparément, chacun sur la représentation qu’il manipule — le planificateur comme un modèle de diffusion gaussienne sur une description gaussianisée du gameplay de chaque section, le modèle de notes par prédiction de tokens masqués sur des tokens de patterns. Les échantillons d’entraînement sont équilibrés entre nombres de touches et niveaux de difficulté pour que les maps 8K et ★10 ne soient pas noyées sous les 4K et ★4, et le modèle de notes s’entraîne en précision mixte.

Chaque changement est jugé sur les maps générées elles-mêmes — précision du timing, difficulté mesurée par rapport à la cible, jouabilité — et pas uniquement sur la loss d’entraînement.

Inférence et performances

Un système d’IA utile ne se résume pas à la qualité du modèle ; il doit aussi être assez rapide pour être utilisé. Une requête ManiaGAI se déroule ainsi :

1. Dans votre navigateur : la musique est décodée, son volume est normalisé et elle est réencodée dès que vous choisissez le fichier, pendant que vous réglez encore les paramètres — le GPU n’attend donc jamais le traitement audio.
2. Compréhension musicale sur le GPU : Beat This et MERT, avec l’ajustement de grille qui tourne sur le CPU en parallèle de MERT.
3. Planification et génération des notes pour toutes les difficultés demandées en une seule passe groupée.
4. Validation — mesure du nombre d’étoiles, vérifications de cohérence.
5. Empaquetage en .osz, puis le téléchargement.

Les workers GPU démarrent depuis un snapshot préchargé, si bien que même un worker à froid est prêt en quelques secondes au lieu de passer ce temps à charger les modèles. Un mapset complet prend environ 20 secondes de calcul GPU pour une musique typique — sans compter l’envoi, la file d’attente et le téléchargement ; une musique de 2:50 mesurée avec cinq difficultés a pris 12,7 secondes sur une NVIDIA T4 — timing et caractéristiques musicales 3,8 s (en parallèle), planification 1,0 s, génération des notes pour les cinq difficultés 6,1 s.

Comment nous avons rendu la génération rapide (en anglais) →

Ce que nous ne publions pas

Nous publions les principes d’architecture, les choix d’ingénierie qui les sous-tendent, et ce que le système fait et ne fait pas — y compris les modèles ouverts sur lesquels nous nous appuyons (Beat This, MERT) et les familles auxquelles appartiennent nos propres modèles (diffusion gaussienne, MaskGIT). Nous ne publions pas les méthodes que nous avons développées nous-mêmes, ni les détails qui permettraient de reproduire le système : comment la grille de timing est ajustée et ses segments de tempo fusionnés, comment les passes d’affinage du modèle de notes sont ordonnancées sur une musique, comment les modèles sont conditionnés, les architectures exactes, les fonctions de perte et les hyperparamètres, et comment les données d’entraînement sont collectées, filtrées et construites. C’est la limite entre être transparents sur ce que nous avons construit et donner la recette. Quand nous affirmons quelque chose sur la qualité, nous comptons l’étayer par des benchmarks publiés — pas par des adjectifs.

La suite

Au-delà d’osu! mania. ManiaGAI repose sur une représentation du gameplay qui n’est pas propre à osu! mania : des notes et des long notes en colonnes, placées sur une grille de timing et conditionnées par une difficulté cible. osu! mania est le premier format de sortie, pas la limite du système.

• #osumania
• #osu
• #VSRG
• #RhythmGames
• #AIBeatmapGenerator
• #BeatmapGeneration
• #RhythmGameAI
• #AIMusicToGame
• #MaskGIT
• #DiffusionModels
• #MERT
• #BeatThis
• #ManiaGAI
• #DanceGAI