Construindo o OsuGAI: beatmaps de osu! standard gerados por IA

O OsuGAI é o primeiro modelo do DanceGAI para osu! standard, o modo original do osu!: hit circles, sliders e spinners espalhados pelo campo de jogo. Ele estreou hoje como beta, ao lado do ManiaGAI para osu! mania. Este relatório explica como ele representa um mapa, com o que aprendeu, como foi treinado, o que medimos — e, com a mesma franqueza, o que ele ainda faz errado.

Por que osu! standard é mais difícil do que osu! mania

Um chart de osu! mania são notas em colunas: um gerador decide quando uma nota vem e em qual das 4 a 9 colunas ela cai. No osu! standard, cada objeto também tem um lugar em um campo de jogo de 512 × 384, e o jogador precisa se mover até ele. Isso traz três problemas que o mania não tem:

• Movimento bidimensional. Espaçamento, ângulos dos saltos e flow entre os objetos são a maior parte do que faz um mapa de standard ser bom ou ruim de jogar — e são contínuos, não uma escolha entre poucas colunas.
• Geometria dos sliders. Um slider é uma curva com comprimento, velocidade e, às vezes, repetições; ele precisa combinar com a música e com os objetos ao redor.
• Legibilidade. Os objetos aparecem antes de você acertá-los, se sobrepõem e se empilham. Um mapa pode ter um timing perfeito e ainda assim ser impossível de ler.

A representação: primeiro a jogabilidade, depois os objetos do editor

O jeito óbvio de ensinar osu! standard a um modelo é dar a ele os objetos do editor — “circle em (x, y)”, “slider com estes pontos de controle”. Tentamos essa família primeiro. O OsuGAI v1, em vez disso, descreve um mapa do jeito que ele é jogado e depois o transforma de volta em objetos. Cada beat são cinco tokens:

• Um token de interação: o estado do botão ao longo do beat, amostrado em 48 células por beat — pressionado ou solto, nada mais. Um toque é uma pressão curta; um slider ou spinner é uma longa. O token é um dos 4.096 padrões de 48 células mais frequentes nos charts de treino, que cobrem 99,87% dos beats de treino e 99,69% dos beats reservados.
• Quatro tokens espaciais: onde o cursor está em até quatro momentos do beat — cada pressão, cada soltura e, depois, as seguradas mais longas divididas igualmente. As posições ficam em uma grade de 4 pixels (128 × 96 células), então o maior erro de arredondamento é de 2,83 pixels; um slot não usado fica vazio.

São cinco slots por beat e um único vocabulário de 16.385 tokens (4.096 padrões de botão mais 12.289 posições). Os momentos que os tokens espaciais descrevem são derivados só do padrão de botão, então o modelo nunca precisa aprender tipos de objeto.

Por que separar a jogabilidade pretendida da representação do editor? Por dois motivos, ambos medidos em replays humanos antes de treinarmos qualquer coisa. Primeiro, as escolhas do editor são em grande parte invisíveis no jogo: só pelo cursor, um slider curto pôde ser distinguido de um circle apenas 43–45% das vezes — então os detalhes no nível dos objetos são decisões que o decodificador pode tomar, não algo que o modelo precise adivinhar. Segundo, a descrição da jogabilidade quase não perde nada que importe: mapas reconstruídos a partir de um estado de botão idealizado mais um caminho de cursor humano foram acertados pelos replays de outros jogadores com a mesma frequência que mapas reconstruídos a partir de uma descrição que conhece os objetos (97,9% vs 98,0%). Usar os estados de botão reais dos jogadores derrubou isso para 78,5% — as pressões reais são ruidosas demais para aprender com elas, e é por isso que o token de botão é idealizado.

Os dados de treino

O corpus são mapas de osu! standard ranked, approved e loved — 117.918 de 117.920 charts foram convertidos com sucesso. Validação e holdout são disjuntos por música: nenhuma música deles aparece no treino. Assim como no ManiaGAI, o timing de cada chart foi primeiro movido para a grade do nosso próprio detector de timing, para que o modelo treine no mesmo tipo de grade que recebe quando gera. Nenhum chart foi descartado por ser difícil.

De onde vêm as posições do cursor: o replay do Auto do osu!lazer

Um arquivo de mapa diz onde os objetos estão, não como o cursor se move entre eles. Derivamos os tokens espaciais do replay do Auto do osu!lazer — o jogador perfeito embutido no jogo. Portamos a lógica de cursor dele para Python e a comparamos com o jogo real em 20 mapas: 264.716 frames, as mesmas contagens de frames, zero divergências de botão ou de stacking, 0,014 pixel de diferença média. Mapas decodificados de volta a partir dos caminhos de cursor do Auto foram acertados pelos replays humanos de outros jogadores 99,7% das vezes em um benchmark de 91 mapas.

Uma ressalva honesta: o Auto não é um humano. Ele segue o caminho exato de cada slider, então o cursor dele fica próximo de “a geometria original do slider escrita como posições” — 72% dos caminhos de slider originais podem ser recuperados a partir do Auto com até 4 pixels de erro, contra 1% a partir de um único replay humano. Por isso o OsuGAI v1 aprende onde um mapper coloca as coisas, não como as pessoas realmente se movem.

A arquitetura

1. Música
2. Grade de timing
3. Planner
4. Noter
5. Decodificador
6. .osu / .osz

O OsuGAI roda no mesmo motor do ManiaGAI (descrito em Planner e Noter), com as partes específicas do modo trocadas:

• Planner (reaproveitado). Um pequeno modelo de difusão, sem mudanças em relação ao nosso trabalho anterior com osu! standard, planeja cada parte da música antes de existir qualquer objeto: o nível de estrelas e uma descrição de estilo — proporção de sliders, caráter dos ângulos, irregularidade do espaçamento, espaçamento de streams e ritmo.
• Noter (novo). Um transformer no estilo MaskGIT com cerca de 64,1 milhões de parâmetros preenche os cinco tokens de cada beat, seguindo o plano, o áudio e as configurações de dificuldade (circle size, approach rate, overall difficulty e slider velocity). Além da precisão de posição exata, o treino dele dá crédito parcial a uma posição que cai a até 16 pixels do alvo.
• Decodificador (baseado em regras, com suporte a repeats). Transforma a jogabilidade de volta em objetos: uma pressão vira um hit circle; uma pressão longa vira um spinner quando o cursor circula o centro por pelo menos 1,5 beat, senão um slider — a linha, o arco ou a curva mais simples que mantém a bola do slider perto do caminho previsto. Inversões claras e com timing regular viram um repeat slider. Os new combos seguem uma regra fixa.

Treino: quatro rodadas

O Noter partiu do nosso modelo anterior de osu! standard (warm start) e foi treinado em quatro rodadas de quatro épocas com tempo limitado (cerca de 46 minutos cada) — umas 14 horas no total em uma única RTX 4070 Ti SUPER (16 GB), com pico de cerca de 6 GB de memória de GPU. Depois de cada rodada, geramos um conjunto de avaliação: 8 músicas reservadas × 22 configurações = 176 mapas.

• A loss de validação caiu de 3,1389 para 2,9570 ao longo das quatro rodadas.
• Validade estrutural: todos os 176 mapas de avaliação foram mapas de osu! standard válidos em todas as rodadas — objetos permitidos, nenhuma violação de slot.
• Dificuldade e estilo respondem: a star rating medida subiu junto com o alvo em 8 de 8 músicas, e cada um dos quatro eixos de estilo moveu o mapa na direção certa em 8 de 8 músicas — embora seguir o plano seção por seção ainda seja fraco.
• Determinístico: a mesma música com a mesma seed gera arquivos .osu idênticos byte a byte.

Velocidade. Nessa GPU de desenvolvimento, oito dificuldades de Flower Dance (4:22) levaram cerca de 16–18 segundos nas etapas cronometradas — preparação do áudio, timing, features de áudio, planejamento e cerca de 11–12 segundos de geração de notas; decodificar e gravar os arquivos acrescenta em média cerca de 0,6 segundo por mapa, na CPU. Este é um benchmark local: a produção roda em outra GPU, na nuvem, e ainda não medimos a latência do OsuGAI em produção.

Limitações

Um mapa válido não é o mesmo que um mapa divertido, e nenhum dos números acima diz que os mapas do OsuGAI são bons de jogar competitivamente. O que sabemos que está errado:

• Dificuldade acima do alvo. Os mapas saem mais difíceis do que o alvo, e muito mais difíceis no topo: em Flower Dance, alvos de 7,43, 8,71 e 10 mediram 9,28, 13,49 e 13,99 estrelas. Por isso o site oferece só alvos de ★1 a ★6 e sempre mostra a star rating medida.
• Sliders que cruzam a si mesmos. 3,3% dos sliders gerados na rodada final se autointersectam (2,4% depois da primeira rodada), contra 0,1% nos mapas originais.
• Artefatos na geometria dos sliders. Alguns sliders batem no limite de velocidade (2,8% na rodada final), e os repeat sliders são mais raros do que em mapas humanos (6,1% dos sliders contra 21%).
• Supervisão pelo Auto. Os caminhos de cursor são do Auto, não de pessoas: o modelo aprende o posicionamento dos objetos, não o movimento humano.
• Overflow e fallback de vocabulário. 0,58% dos beats de treino precisam de mais de quatro posições; só as quatro primeiras são mantidas. 0,13% dos beats ficam fora dos 4.096 padrões de botão e usam o mais próximo. Os mapas muito densos são os mais afetados.
• Ainda sem playtesting amplo por pessoas. Todas as verificações até agora são automáticas ou baseadas em replays gravados. É no beta que isso começa.

O que vem a seguir

• Melhor calibração de dificuldade — alvos em que você pode confiar, e a faixa completa de estrelas de volta.
• Geometria de sliders mais limpa — menos autocruzamentos e velocidades no limite, repeats mais naturais.
• Dados de jogabilidade humana — aprender como as pessoas se movem, não só onde os objetos estão.
• Controle de estilo mais forte — barras que o mapa segue seção por seção, não só na média.
• Mais modos do osu! — osu! taiko e osu! catch são os próximos no roadmap.

Novo no modo? O que é osu! standard? explica o jogo em si; a página de tecnologia cobre o motor que o OsuGAI compartilha com o ManiaGAI.