งานวิจัย

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% — การกดจริงมีสัญญาณรบกวนมากเกินกว่าจะเรียนรู้ได้ นี่คือเหตุผลที่โทเคนปุ่มเป็นแบบอุดมคติ

ข้อมูลที่ใช้ฝึก

ข้อมูลที่ใช้ฝึก OsuGAI v1
ค่า
ชาร์ตที่ประมวลผล117,918
เพลง25,928
หน้าต่างสำหรับฝึก11.85 ล้าน
ชาร์ต train / validation / holdout117,474 / 362 / 82
ค่าดาว เปอร์เซ็นไทล์ที่ 10 / 50 / 901.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 วางสิ่งต่าง ๆ ไว้ที่ไหน ไม่ใช่ว่าคนเคลื่อนไหวจริงอย่างไร

สถาปัตยกรรม

  1. เพลง
  2. กริดไทมมิ่ง
  3. Planner
  4. Noter
  5. Decoder
  6. .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 แมพ

รอบการฝึกของ OsuGAI v1
รอบValidation lossแมพที่ถูกต้อง★ ที่วัดได้ สำหรับเป้าหมาย 2 / 4 / 6
13.1389176/1762.39 / 4.76 / 7.38
23.0175176/1762.24 / 4.64 / 7.28
32.9842176/1762.32 / 4.64 / 7.04
4 (เวอร์ชันที่เปิดตัว)2.9570176/1762.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