打造 OsuGAI：AI 生成的 osu! standard beatmap

OsuGAI 是 DanceGAI 第一個為 osu! standard 打造的模型——osu! 最原始的模式：圓圈、滑條和轉盤散布在整個遊玩區上。它今天以測試版推出，和 osu! mania 的 ManiaGAI 並列。這份報告說明它如何表示一張譜面、從什麼資料學習、如何訓練、我們測量到什麼——也同樣直白地說明它還有哪些地方做錯。

為什麼 osu! standard 比 osu! mania 更難

osu! mania 的譜面是落在各軌上的音符：生成器決定音符什麼時候出現，以及落在 4 到 9 軌中的哪一軌。在 osu! standard 裡，每個物件還有一個在 512 × 384 遊玩區上的位置，玩家必須移動過去。這帶來了 mania 沒有的三個問題：

• 二維移動。物件之間的間距、跳躍角度和流暢度，大致決定了一張 standard 譜面玩起來是好是壞——而且它們是連續的，不是在少數幾軌之間做選擇。
• 滑條幾何。滑條是一條有長度、有速度、有時還會折返的曲線；它必須配合音樂，也要和周圍的物件搭得起來。
• 可讀性。物件會在你打擊之前出現，也會彼此重疊、堆疊。一張譜面可以 timing 完美，卻仍然完全讀不出來。

表示方式：先描述玩法，再轉成編輯器物件

教模型學 osu! standard，最直覺的做法是給它編輯器裡的物件——「位於 (x, y) 的圓圈」、「有這些控制點的滑條」。我們一開始試的就是這一類做法。OsuGAI v1 則改成以譜面被遊玩的方式來描述它，之後再轉回物件。每一拍由五個 token 組成：

• 一個互動 token：整拍的按鍵狀態，以每拍 48 格取樣——只有按下或放開，沒有其他資訊。點擊是短按；滑條或轉盤則是長按。這個 token 是訓練譜面中最常見的 4,096 種 48 格模式之一，涵蓋 99.87% 的訓練拍與 99.69% 的保留拍。
• 四個空間 token：游標在這一拍中最多四個時刻的位置——每次按下、每次放開，再把最長的按住時段平均切分。位置落在 4 像素的格線上（128 × 96 格），所以最大的捨入誤差是 2.83 像素；沒用到的格位則留空。

也就是每拍五個格位，以及一套共 16,385 個 token 的詞彙表（4,096 種按鍵模式加上 12,289 個位置）。空間 token 描述的是哪些時刻，完全由按鍵模式推導而來，所以模型從來不需要學物件類型。

為什麼要把預期的玩法和編輯器的表示分開？有兩個理由，都是在我們訓練任何東西之前，用真人回放測量出來的。第一，編輯器上的選擇在遊玩中大多看不出來：只看游標的話，短滑條和圓圈只有 43–45% 的時候能被分辨出來——所以物件層級的細節是解碼器可以自行決定的事，不是模型必須猜的東西。第二，玩法描述幾乎沒有丟失任何重要的資訊：用理想化的按鍵狀態加上真人游標路徑重建的譜面，被其他玩家回放打中的比例，和用考慮物件的描述重建的譜面幾乎一樣（97.9% 對 98.0%）。改用玩家實際的按鍵狀態，這個比例就掉到 78.5%——真實的按鍵太雜亂，無法從中學習，這也是按鍵 token 採用理想化狀態的原因。

訓練資料

語料庫是 ranked、approved 和 loved 的 osu! standard 譜面——117,920 張譜面中有 117,918 張成功轉換。驗證集和保留集與訓練集的歌曲不重疊：其中的歌曲都沒有出現在訓練資料裡。和 ManiaGAI 一樣，每張譜面的 timing 都先移到我們自己的 timing 偵測器格線上，讓模型訓練時用的格線，和它生成時拿到的是同一種。沒有任何譜面因為太難而被剔除。

游標位置從哪裡來：osu!lazer 的 Auto 回放

譜面檔案記錄的是物件在哪裡，而不是游標如何在物件之間移動。我們從 osu!lazer 的 Auto 回放推導出空間 token——也就是遊戲內建的完美玩家。我們把它的游標邏輯移植到 Python，並在 20 張譜面上和真正的遊戲比對：264,716 個影格、影格數完全相同、按鍵和堆疊零誤差，平均差距 0.014 像素。在一套 91 張譜面的基準測試中，從 Auto 游標路徑解碼回來的譜面，被其他玩家的真人回放打中的比例是 99.7%。

一個必須坦白的但書：Auto 不是人類。它會沿著每條滑條的精確路徑走，所以它的游標很接近「以位置寫下的原始滑條幾何」——72% 的原始滑條路徑可以從 Auto 讀回、誤差在 4 像素以內，而從單一份真人回放只有 1%。因此，OsuGAI v1 學到的是 mapper 把東西放在哪裡，而不是人實際上怎麼移動。

架構

1. 音樂
2. Timing 格線
3. Planner
4. Noter
5. 解碼器
6. .osu / .osz

OsuGAI 和 ManiaGAI 使用同一套引擎（說明見Planner 與 Noter），只換掉各模式專屬的部分：

• Planner（沿用）。一個小型擴散模型，和我們先前的 osu! standard 研究中使用的完全相同，會在任何物件出現之前規劃歌曲的每個部分：它的星數等級，以及一份風格描述——滑條比例、角度特性、間距不規則度、stream 間距和節奏。
• Noter（全新）。一個約 6,410 萬參數的 MaskGIT 式 transformer，依照規劃、音訊和難度設定（圓圈大小、縮圈速度、整體難度和滑條速度），填入每一拍的五個 token。除了位置完全正確的準確度之外，訓練時對落在目標 16 像素以內的位置也會給予部分分數。
• 解碼器（規則式，能辨識折返）。把玩法轉回物件：一次按下變成圓圈；一次長按，如果游標繞著中心轉了至少 1.5 拍就變成轉盤，否則變成滑條——選用能讓滑球貼近預測路徑的最簡單直線、圓弧或曲線。明確、時間間隔平均的來回會變成折返滑條。new combo 依照固定規則設定。

訓練：四輪

Noter 從我們先前的 osu! standard 模型熱啟動，訓練了四輪，每輪四個有時間上限的 epoch（每個約 46 分鐘）——在單張 RTX 4070 Ti SUPER（16 GB）上總共約 14 小時，GPU 記憶體峰值約 6 GB。每一輪結束後，我們都會生成一套評估集：8 首保留歌曲 × 22 種設定 = 176 張譜面。

• 驗證損失在四輪中從 3.1389 降到 2.9570。
• 結構有效性：每一輪的 176 張評估譜面全都是有效的 osu! standard 譜面——物件合法，沒有違反格位規則。
• 難度和風格有反應：8 首歌中有 8 首的實測星數會隨目標上升，四個風格軸也都在 8 首歌中的 8 首把譜面往正確的方向推——不過逐段遵循規劃的能力仍然很弱。
• 確定性：同一首歌搭配同一個 seed，會產生逐位元組完全相同的 .osu 檔。

速度。在那張開發用 GPU 上，Flower Dance（4:22）的八個難度跑完計時的各階段約需 16–18 秒——音訊準備、timing、音訊特徵、規劃，以及約 11–12 秒的音符生成；解碼和寫入檔案在 CPU 上平均每張譜面再多約 0.6 秒。這是本機的基準測試：正式環境跑在另一種雲端 GPU 上，而我們還沒有測量 OsuGAI 在正式環境的延遲。

限制

有效的譜面不等於好玩的譜面，上面的數字也沒有任何一個代表 OsuGAI 的譜面適合拿來認真競技。我們已知的問題如下：

• 難度超標。譜面會比目標更難，在高星數更是難上許多：在 Flower Dance 上，目標 7.43、8.71 和 10 的實測星數分別是 9.28、13.49 和 13.99。因此網站只提供 ★1–★6 的目標，並且一律顯示實測星數。
• 和自己交叉的滑條。最後一輪生成的滑條中有 3.3% 會自我交叉（第一輪後是 2.4%），原始譜面則是 0.1%。
• 滑條幾何瑕疵。有些滑條會碰到速度上限（最後一輪為 2.8%），而折返滑條比人類譜面少（佔滑條的 6.1%，人類譜面為 21%）。
• 以 Auto 作為監督。游標路徑來自 Auto，不是真人：模型學到的是物件擺放，而不是人類的移動方式。
• 溢位與詞彙表退回。0.58% 的訓練拍需要超過四個位置；只保留前四個。0.13% 的拍不在 4,096 種按鍵模式之內，會改用最接近的一種。非常密集的譜面受到的影響最大。
• 還沒有大規模的真人試玩。到目前為止的每項檢查都是自動的，或是根據錄下來的回放。測試版就是這件事的起點。

接下來

• 更好的難度校準——值得信賴的目標，並恢復完整的星數範圍。
• 更乾淨的滑條幾何——更少的自我交叉和被限速的滑條，更自然的折返。
• 真人遊玩資料——學習人們怎麼移動，而不只是物件在哪裡。
• 更強的風格控制——讓譜面逐段遵循滑桿，而不只是平均而言。
• 更多 osu! 模式——osu! taiko 和 osu! catch 是開發藍圖上的下一步。

第一次接觸這個模式？osu! standard 是什麼？介紹了遊戲本身；技術頁面則說明 OsuGAI 與 ManiaGAI 共用的引擎。