คู่มือเกมแลค › การออกแบบการซิงก์
rollback netcode คาดการณ์พลาด Rollback misprediction
ID สาเหตุ sy-rollback · ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
แสดงผลไปก่อนโดยคาดการณ์อินพุตของอีกฝ่าย ถ้าผิดจะย้อนกลับไปคำนวณใหม่ ยิ่งปิงสูง ช่วงที่ต้องย้อนยิ่งยาว
ทำไม อีกฝ่ายเปลี่ยนอินพุต (ไม่ตรงกับที่คาดการณ์) → ผลคือ อินพุตจริงมาถึงช้าไปครึ่งหนึ่งของปิง จึงต้องย้อนกลับไปคำนวณใหม่เท่ากับช่วงนั้น → บนหน้าจอ ท่าทางของอีกฝ่ายกระโดดข้ามไปหลายเฟรม หรือเปลี่ยนไปกะทันหัน
- อาการ
- วาร์ป
- ปัจจัย
- ความหน่วง, จิตเตอร์
- ใครเจอ
- เราคนเดียว
- เกิดเมื่อไร
- ตอนทำแอ็กชันบางอย่าง, สุ่มเป็นครั้งคราว
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- ผสม input delay 1–3 เฟรมเพื่อลดช่วงที่ต้องย้อน, ตั้งเพดานการย้อน
- ตัวเลขที่ควรรู้
- ปิง 100 ms (ทางเดียว 50 ms) ที่ 60 fps จะย้อนประมาณ 3 เฟรม ถ้าตั้ง input delay 2 เฟรม จะลดเหลือ 1 เฟรม
- บนกราฟ
- พุ่งแบบสุ่มเป็นครั้งคราว · จำนวนเฟรมที่ย้อน, RTT (ปิง)
- จุดที่ต้องดู
- ให้ไคลเอนต์บันทึกจำนวนเฟรมที่ย้อน, RTT ในตอนนั้น, ค่า input delay ที่ตั้งไว้ และเวลาที่ใช้ย้อนและคำนวณใหม่ ทุกครั้งที่ย้อน
- สัญญาณว่าใช่
- จังหวะที่แจ้งว่าท่าทางอีกฝ่ายกระโดด จำนวนเฟรมที่ย้อนสูง และช่วงย้อนเฉลี่ยประมาณ (ดีเลย์ทางเดียว − input delay) ÷ เวลาต่อเฟรม และยิ่งปิงสูงยิ่งมาก
- สัญญาณว่าไม่ใช่
- ช่วงย้อนสั้นแต่ยังกระตุก: น่าจะเป็นปัญหาประสิทธิภาพที่การคำนวณใหม่ใช้เวลาเกินหนึ่งเฟรม ถ้าย้อนแล้วผลบนสองจอยังต่างกันต่อไป คือผลการคำนวณไม่ตรงกัน (desync)
- วิธีตรวจ
- ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
แหล่งอ้างอิง
- GGPO Rollback Networking SDK GGPO
คาดการณ์อินพุตของอีกฝ่ายแล้วเดินเกมไปก่อน ถ้าอินพุตจริงต่างจากนั้น คำนวณใหม่ตั้งแต่จุดที่คลาดจนถึงปัจจุบัน - 8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2' GDC
ใช้ rollback ตัด local input delay ของ lockstep ออก และย้อนคำนวณใหม่ได้สูงสุด 8 เฟรมภายใน 16 ms
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: การออกแบบการซิงก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (วาร์ป)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง