งานวิจัย
Building OsuGAI: beatmap osu! standard ที่สร้างด้วย AI
OsuGAI v1 เปลี่ยนเพลงเป็นแมพ osu! standard อย่างไร: การแทนเกมเพลย์ด้วยการกดปุ่มและตำแหน่งเคอร์เซอร์ แมพฝึก 118,000 แมพพร้อม replay ของ Auto ใน osu!lazer การฝึกสี่รอบ ผลลัพธ์ และข้อจำกัดตามจริงของเบต้า
OsuGAI คือโมเดลแรกของ DanceGAI สำหรับ osu! standard โหมดดั้งเดิมของ osu!: hit circle, slider และ spinner ที่กระจายอยู่ทั่ว playfield วันนี้มันเปิดตัวในช่วงเบต้า เคียงข้าง ManiaGAI สำหรับ osu! mania รายงานนี้อธิบายว่ามันแทนแมพด้วยอะไร เรียนรู้จากอะไร ฝึกอย่างไร เราวัดอะไรได้บ้าง — และพูดตรง ๆ เช่นกันว่ามันยังทำอะไรผิดอยู่
ทำไม osu! standard ถึงยากกว่า osu! mania
ชาร์ต osu! mania คือโน้ตในคอลัมน์: ตัวสร้างแมพตัดสินว่าโน้ตจะมาเมื่อไร และตกลงในคอลัมน์ไหนจาก 4 ถึง 9 คอลัมน์ ส่วนใน osu! standard ทุกออบเจกต์ยังมีตำแหน่งบน playfield ขนาด 512 × 384 และผู้เล่นต้องเคลื่อนไปหามัน ซึ่งเพิ่มปัญหาสามข้อที่ mania ไม่มี:
- การเคลื่อนที่สองมิติ ระยะห่าง มุมของ jump และ flow ระหว่างออบเจกต์ คือส่วนใหญ่ของสิ่งที่ทำให้แมพ standard รู้สึกดีหรือแย่ — และทั้งหมดเป็นค่าต่อเนื่อง ไม่ใช่การเลือกจากไม่กี่คอลัมน์
- รูปทรงของ slider slider คือเส้นโค้งที่มีความยาว ความเร็ว และบางครั้งก็มีการวนกลับ มันต้องเข้ากับเพลงและออบเจกต์รอบ ๆ
- ความอ่านง่าย ออบเจกต์ปรากฏขึ้นก่อนที่คุณจะกด ซ้อนทับกัน และ stack กัน แมพอาจตั้งไทมมิ่งได้สมบูรณ์แบบ แต่ก็ยังอ่านไม่ออกเลยก็ได้
วิธีแทนแมพ: เกมเพลย์มาก่อน ออบเจกต์ของ editor มาทีหลัง
วิธีที่เห็นได้ชัดในการสอน osu! standard ให้โมเดลคือให้ออบเจกต์ของ editor ไปตรง ๆ — “circle ที่ (x, y)”, “slider ที่มีจุดควบคุมเหล่านี้” เราลองแนวทางกลุ่มนั้นก่อน แต่ OsuGAI v1 อธิบายแมพตามแบบที่มันถูกเล่น แล้วค่อยแปลงกลับเป็นออบเจกต์ภายหลัง ทุกบีตประกอบด้วยห้าโทเคน:
- โทเคนการกดหนึ่งโทเคน: สถานะของปุ่มตลอดบีต สุ่มตัวอย่างที่ 48 ช่องต่อบีต — กดหรือปล่อย ไม่มีอย่างอื่น การแตะคือการกดสั้น ๆ ส่วน slider หรือ spinner คือการกดยาว โทเคนนี้คือหนึ่งใน 4,096 แพทเทิร์น 48 ช่องที่พบบ่อยที่สุดในชาร์ตที่ใช้ฝึก ซึ่งครอบคลุม 99.87% ของบีตที่ใช้ฝึก และ 99.69% ของบีตที่กันไว้ทดสอบ
- โทเคนตำแหน่งสี่โทเคน: เคอร์เซอร์อยู่ที่ไหนในช่วงเวลาสูงสุดสี่จุดในบีต — ทุกครั้งที่กด ทุกครั้งที่ปล่อย แล้วจึงแบ่งช่วงกดค้างที่ยาวที่สุดเท่า ๆ กัน ตำแหน่งอยู่บนกริด 4 พิกเซล (128 × 96 ช่อง) ความคลาดเคลื่อนจากการปัดเศษสูงสุดจึงเป็น 2.83 พิกเซล ช่องที่ไม่ได้ใช้จะว่างไว้
นั่นคือ ห้าช่องต่อบีต และคลังคำศัพท์ชุดเดียว 16,385 โทเคน (แพทเทิร์นปุ่ม 4,096 แบบ บวกตำแหน่ง 12,289 ตำแหน่ง) ช่วงเวลาที่โทเคนตำแหน่งอธิบายนั้นได้มาจากแพทเทิร์นปุ่มเพียงอย่างเดียว โมเดลจึงไม่ต้องเรียนรู้ประเภทของออบเจกต์เลย
ทำไมต้องแยกเกมเพลย์ที่ตั้งใจออกจากวิธีแทนแมพของ editor? มีสองเหตุผล ซึ่งทั้งสองข้อวัดจาก replay ของคนก่อนที่เราจะฝึกอะไรเลย ข้อแรก สิ่งที่ editor เลือกส่วนใหญ่มองไม่เห็นตอนเล่น: จากเคอร์เซอร์อย่างเดียว แยก slider สั้น ๆ ออกจาก circle ได้เพียง 43–45% ของครั้ง — รายละเอียดระดับออบเจกต์จึงเป็นสิ่งที่ Decoder ตัดสินใจเองได้ ไม่ใช่สิ่งที่โมเดลต้องเดา ข้อสอง คำอธิบายแบบเกมเพลย์แทบไม่สูญเสียอะไรที่สำคัญ: แมพที่สร้างกลับจากสถานะปุ่มแบบอุดมคติบวกเส้นทางเคอร์เซอร์ของคน ถูก replay ของผู้เล่นคนอื่นกดโดนบ่อยพอ ๆ กับแมพที่สร้างกลับจากคำอธิบายที่รู้จักออบเจกต์ (97.9% เทียบกับ 98.0%) ถ้าใช้สถานะปุ่มจริงของผู้เล่นแทน ตัวเลขนั้นลดลงเหลือ 78.5% — การกดจริงมีสัญญาณรบกวนมากเกินกว่าจะเรียนรู้ได้ นี่คือเหตุผลที่โทเคนปุ่มเป็นแบบอุดมคติ
ข้อมูลที่ใช้ฝึก
| ค่า | |
|---|---|
| ชาร์ตที่ประมวลผล | 117,918 |
| เพลง | 25,928 |
| หน้าต่างสำหรับฝึก | 11.85 ล้าน |
| ชาร์ต train / validation / holdout | 117,474 / 362 / 82 |
| ค่าดาว เปอร์เซ็นไทล์ที่ 10 / 50 / 90 | 1.98 / 3.69 / 5.86 |
คลังข้อมูลคือแมพ osu! standard ที่เป็น ranked, approved และ loved — แปลงสำเร็จ 117,918 จาก 117,920 ชาร์ต ชุด validation และ holdoutไม่มีเพลงซ้ำกับชุดฝึก: ไม่มีเพลงใดในสองชุดนี้ปรากฏในข้อมูลฝึก เช่นเดียวกับ ManiaGAI ไทมมิ่งของทุกชาร์ตถูกย้ายมาอยู่บนกริดของตัวตรวจจับไทมมิ่งของเราเองก่อน โมเดลจึงฝึกบนกริดแบบเดียวกับที่มันได้รับตอนสร้างแมพ ไม่มีชาร์ตใดถูกตัดออกเพราะยากเกินไป
ตำแหน่งเคอร์เซอร์มาจากไหน: replay ของ Auto ใน osu!lazer
ไฟล์แมพบอกว่าออบเจกต์อยู่ที่ไหน แต่ไม่ได้บอกว่าเคอร์เซอร์เคลื่อนที่ระหว่างออบเจกต์อย่างไร เราได้โทเคนตำแหน่งมาจาก replay ของAuto ใน osu!lazer — ผู้เล่นสมบูรณ์แบบที่มีมาในเกม เราพอร์ตตรรกะเคอร์เซอร์ของมันมาเป็น Python และตรวจเทียบกับเกมจริงบน 20 แมพ: 264,716 เฟรม จำนวนเฟรมตรงกัน ไม่มีความไม่ตรงกันของปุ่มหรือการ stack เลย และต่างกันเฉลี่ย 0.014 พิกเซล แมพที่ถอดรหัสกลับจากเส้นทางเคอร์เซอร์ของ Auto ถูก replay ของผู้เล่นคนอื่นกดโดน 99.7% ของครั้ง ในเบนช์มาร์ก 91 แมพ
ข้อควรระวังตามจริงหนึ่งข้อ: Auto ไม่ใช่คน มันเดินตามเส้นทางที่แน่นอนของแต่ละ slider เคอร์เซอร์ของมันจึงใกล้เคียงกับ “รูปทรง slider ดั้งเดิมที่เขียนเป็นตำแหน่ง” — 72% ของเส้นทาง slider ดั้งเดิมอ่านกลับจาก Auto ได้ภายใน 4 พิกเซล เทียบกับ 1% จาก replay ของคนเพียงหนึ่งอัน ดังนั้น OsuGAI v1 จึงเรียนรู้ว่า mapper วางสิ่งต่าง ๆ ไว้ที่ไหน ไม่ใช่ว่าคนเคลื่อนไหวจริงอย่างไร
สถาปัตยกรรม
- เพลง
- กริดไทมมิ่ง
- Planner
- Noter
- Decoder
- .osu / .osz
OsuGAI ทำงานบนเอนจินเดียวกับ ManiaGAI (อธิบายไว้ในPlanner และ Noter) โดยเปลี่ยนส่วนที่เฉพาะกับโหมด:
- Planner (ใช้ซ้ำ) โมเดล diffusion ขนาดเล็กที่ไม่ได้เปลี่ยนจากงาน osu! standard ก่อนหน้าของเรา วางแผนแต่ละช่วงของเพลง ก่อนที่จะมีออบเจกต์ใด ๆ: ระดับค่าดาว และคำอธิบายสไตล์ — สัดส่วน slider ลักษณะของมุม ความไม่สม่ำเสมอของระยะห่าง ระยะห่างของ stream และจังหวะ
- Noter (ใหม่) transformer แบบ MaskGIT ขนาดราว 64.1 ล้านพารามิเตอร์ เติมห้าโทเคนของทุกบีต โดยทำตามแผน เสียง และการตั้งค่าความยาก (circle size, approach rate, overall difficulty และ slider velocity) นอกจากความแม่นยำของตำแหน่งที่ตรงเป๊ะแล้ว การฝึกของมันยังให้คะแนนบางส่วนกับตำแหน่งที่ตกห่างจากเป้าหมายไม่เกิน 16 พิกเซล
- Decoder (อิงกฎ รองรับการวนกลับ) แปลงเกมเพลย์กลับเป็นออบเจกต์: การกดหนึ่งครั้งกลายเป็น hit circle การกดยาวกลายเป็น spinner เมื่อเคอร์เซอร์วนรอบจุดกึ่งกลางอย่างน้อย 1.5 บีต ไม่อย่างนั้นจะเป็น slider — เส้นตรง ส่วนโค้ง หรือเส้นโค้งที่เรียบง่ายที่สุดที่ทำให้ลูก slider อยู่ใกล้เส้นทางที่ทำนายไว้ การกลับทิศที่ชัดเจนและมีจังหวะสม่ำเสมอจะกลายเป็นrepeat slider ส่วน new combo เป็นไปตามกฎตายตัว
การฝึก: สี่รอบ
Noter เริ่มต้นจากโมเดล osu! standard ตัวก่อนหน้าของเรา และฝึกสี่รอบ รอบละสี่ epoch ที่จำกัดเวลา (epoch ละราว 46 นาที) — รวมประมาณ 14 ชั่วโมงบน RTX 4070 Ti SUPER (16 GB) ตัวเดียว ใช้หน่วยความจำ GPU สูงสุดราว 6 GB หลังทุกรอบเราสร้างชุดประเมินผล: 8 เพลงที่กันไว้ × 22 การตั้งค่า = 176 แมพ
| รอบ | Validation loss | แมพที่ถูกต้อง | ★ ที่วัดได้ สำหรับเป้าหมาย 2 / 4 / 6 |
|---|---|---|---|
| 1 | 3.1389 | 176/176 | 2.39 / 4.76 / 7.38 |
| 2 | 3.0175 | 176/176 | 2.24 / 4.64 / 7.28 |
| 3 | 2.9842 | 176/176 | 2.32 / 4.64 / 7.04 |
| 4 (เวอร์ชันที่เปิดตัว) | 2.9570 | 176/176 | 2.40 / 4.62 / 7.22 |
- Validation loss ลดลงจาก 3.1389 เป็น 2.9570 ตลอดสี่รอบ
- ความถูกต้องเชิงโครงสร้าง: แมพประเมินผลทั้ง 176 แมพเป็นแมพ osu! standard ที่ถูกต้องในทุกรอบ — ออบเจกต์ถูกกฎ ไม่มีการละเมิดช่อง
- ความยากและสไตล์ตอบสนอง: ค่าดาวที่วัดได้เพิ่มขึ้นตามเป้าหมายใน 8 จาก 8 เพลง และแกนสไตล์ทั้งสี่แกน ต่างก็ขยับแมพไปในทิศทางที่ถูกต้องใน 8 จาก 8 เพลง — แม้ว่าการทำตามแผนทีละช่วงยังอ่อนอยู่
- ผลลัพธ์แน่นอน (deterministic): เพลงเดียวกันกับ seed เดียวกันให้ไฟล์ .osu ที่เหมือนกันทุกไบต์
ความเร็ว บน GPU สำหรับพัฒนาตัวนั้น แปดระดับความยากของ Flower Dance (4:22) ใช้เวลาราว 16–18 วินาทีในขั้นตอนที่จับเวลา — การเตรียมเสียง ไทมมิ่ง ฟีเจอร์เสียง การวางแผน และการสร้างโน้ตราว 11–12 วินาที ส่วนการถอดรหัสและเขียนไฟล์ เพิ่มอีกเฉลี่ยราว 0.6 วินาทีต่อแมพ บน CPU นี่คือเบนช์มาร์กแบบในเครื่อง: ระบบจริงทำงานบน GPU บนคลาวด์ที่ต่างออกไป และเรายังไม่ได้วัด latency ของ OsuGAI บนระบบจริง
ข้อจำกัด
แมพที่ถูกต้องไม่ได้แปลว่าแมพที่สนุก และไม่มีตัวเลขใดข้างบนที่บอกว่าแมพของ OsuGAI เล่นแข่งขันได้ดี สิ่งที่เรารู้ว่ายังผิดอยู่:
- ความยากเกินเป้า แมพออกมายากกว่าเป้าหมาย และยากกว่ามากที่ระดับสูง: ใน Flower Dance เป้าหมาย 7.43, 8.71 และ 10 วัดได้ 9.28, 13.49 และ 13.99 ดาว เว็บไซต์จึงให้เลือกเป้าหมายได้แค่ ★1–★6 และแสดงค่าดาวที่วัดได้เสมอ
- slider ที่พาดทับตัวเอง 3.3% ของ slider ที่สร้างในรอบสุดท้ายตัดกับตัวเอง (2.4% หลังรอบแรก) เทียบกับ 0.1% ในแมพต้นฉบับ
- ความผิดเพี้ยนของรูปทรง slider slider บางอันชนเพดานจำกัดความเร็ว (2.8% ในรอบสุดท้าย) และ repeat slider พบน้อยกว่าในแมพที่คนทำ (6.1% ของ slider เทียบกับ 21%)
- การเรียนรู้จาก Auto เส้นทางเคอร์เซอร์เป็นของ Auto ไม่ใช่ของคน: โมเดลเรียนรู้การวางออบเจกต์ ไม่ใช่การเคลื่อนไหวของคน
- ตำแหน่งล้นและการใช้แพทเทิร์นใกล้เคียงแทน 0.58% ของบีตที่ใช้ฝึกต้องการตำแหน่งมากกว่าสี่ตำแหน่ง ซึ่งเก็บไว้เพียงสี่ตำแหน่งแรก 0.13% ของบีตอยู่นอกแพทเทิร์นปุ่ม 4,096 แบบ และใช้แพทเทิร์นที่ใกล้ที่สุดแทน แมพที่หนาแน่นมากได้รับผลกระทบมากที่สุด
- ยังไม่มีการทดลองเล่นโดยคนอย่างกว้างขวาง การตรวจสอบทุกอย่างจนถึงตอนนี้เป็นแบบอัตโนมัติ หรืออิงจาก replay ที่บันทึกไว้ ช่วงเบต้าคือจุดเริ่มต้นของสิ่งนั้น
ขั้นต่อไป
- ปรับเทียบความยากให้ดีขึ้น — เป้าหมายที่เชื่อถือได้ และนำช่วงค่าดาวเต็มกลับมา
- รูปทรง slider ที่เรียบร้อยขึ้น — การพาดทับตัวเองและความเร็วที่ชนเพดานน้อยลง การวนกลับที่เป็นธรรมชาติมากขึ้น
- ข้อมูลเกมเพลย์ของคน — เรียนรู้ว่าคนเคลื่อนไหวอย่างไร ไม่ใช่แค่ว่าออบเจกต์อยู่ที่ไหน
- การควบคุมสไตล์ที่แม่นยำขึ้น — แถบที่แมพทำตามทีละช่วง ไม่ใช่แค่โดยเฉลี่ย
- โหมด osu! เพิ่มเติม — osu! taiko และ osu! catch คือลำดับถัดไปในแผนงาน
เพิ่งรู้จักโหมดนี้? osu! standard คืออะไร? อธิบายตัวเกม ส่วนหน้าเทคโนโลยีครอบคลุมเอนจินที่ OsuGAI ใช้ร่วมกับ ManiaGAI