คู่มือเกมแลค › การออกแบบการซิงก์
แสดงผลล่วงหน้าแล้วเซิร์ฟเวอร์ปฏิเสธ Client-side feedback rejected by server
ID สาเหตุ sy-optimistic-reject · ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าการโจมตีหรือสกิลที่จอเราแสดงไปก่อนแล้วถูกเซิร์ฟเวอร์ปฏิเสธทีหลัง ผลที่เห็นกับตาจะกลายเป็นเหมือนไม่เคยเกิดขึ้น
ทำไม เล่นเอฟเฟกต์การโจมตีและท่าสกิลก่อนเซิร์ฟเวอร์ยืนยัน (การแสดงผลล่วงหน้า) → ผลคือ เซิร์ฟเวอร์ตรวจระยะ, ตำแหน่งเป้า, คูลดาวน์ และทรัพยากรอีกครั้งแล้วปฏิเสธ → บนหน้าจอ เลือดกระเด็นแต่ไม่มีดาเมจ, ท่าสกิลออกแต่ไม่มีผล, มีแต่คูลดาวน์ที่เดิน
- อาการ
- กดไม่ติด/โรลแบ็ค, ดีดกลับ
- ปัจจัย
- ความหน่วง
- ใครเจอ
- เราคนเดียว, เฉพาะบางฟีเจอร์
- เกิดเมื่อไร
- ตอนทำแอ็กชันบางอย่าง
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- ไคลเอนต์: แสดงผลจากเซิร์ฟเวอร์เฉพาะส่วนที่ต้องยืนยัน เช่น ตัวเลขดาเมจ, การตาย และของรางวัล, ตรวจสาเหตุการปฏิเสธที่พบบ่อยไว้ก่อน, ถ้าถูกปฏิเสธให้คืนคูลดาวน์และทรัพยากรแล้วแสดงเหตุผล เซิร์ฟเวอร์: เผื่อระยะในการตรวจระยะและตำแหน่งเป้าไว้เท่ากับปิง, ใส่สาเหตุในคำตอบปฏิเสธ, เก็บอัตราการปฏิเสธแยกตามสกิลเป็นเมตริก
- ตัวเลขที่ควรรู้
- คำตอบปฏิเสธมาถึงหลังกดช้าไปเท่ากับปิง + เวลารอทิก ถ้าปิง 150 ms จะ “นึกว่าโดนแล้ว” อยู่ประมาณ 0.2 วินาที
- บนกราฟ
- สูงเฉพาะบางกลุ่ม · อัตราที่เซิร์ฟเวอร์ปฏิเสธแยกตามสกิล (แยกตามช่วงปิง)
- จุดที่ต้องดู
- เก็บอัตราการปฏิเสธและสาเหตุ (ระยะ, ตำแหน่งเป้า, คูลดาวน์, ทรัพยากร) แยกตามสกิลที่เซิร์ฟเวอร์ แล้วแบ่งตามช่วง RTT ของผู้เล่น ฝั่งไคลเอนต์ให้บันทึกจำนวนครั้งที่การกระทำที่แสดงผลล่วงหน้าถูกปฏิเสธ
- สัญญาณว่าใช่
- การปฏิเสธกระจุกที่บางสกิลและสาเหตุเรื่องระยะหรือตำแหน่งเป้า และยิ่งปิงสูง อัตราการปฏิเสธยิ่งสูง
- สัญญาณว่าไม่ใช่
- สาเหตุการปฏิเสธเป็นคูลดาวน์หรือทรัพยากรและไม่เกี่ยวกับปิง: ให้ดูว่าค่าข้อมูล (คูลดาวน์, ค่าใช้จ่าย) ของไคลเอนต์กับเซิร์ฟเวอร์ต่างกันหรือไม่ ถ้าไม่มีการปฏิเสธแต่การแสดงผลเริ่มหลังเซิร์ฟเวอร์ตอบเท่านั้น น่าจะเป็น “แสดงผลหลังเซิร์ฟเวอร์ตอบเท่านั้น (แบบ request-response)”
- วิธีตรวจ
- ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
- รายละเอียดเพิ่มเติม
- การแสดงผลล่วงหน้าเป็นวิธีที่ดีที่สุดในการกลบปิง แต่ยิ่งข้อมูลที่ไคลเอนต์กับเซิร์ฟเวอร์ใช้ตัดสิน (ตำแหน่งอีกฝ่าย, ทรัพยากรที่เหลือ) ต่างกันมาก ก็ยิ่งถูกปฏิเสธบ่อย ถ้าเก็บอัตราการปฏิเสธแยกตามสกิลเป็นเมตริกไว้ จะหาจุดที่การตัดสินคลาดกันได้ง่าย
แหล่งอ้างอิง
- Using Gameplay Abilities in Unreal Engine Epic Games
ability แบบ Local Predicted ทำงานทันทีบนไคลเอนต์ แต่เซิร์ฟเวอร์เป็นผู้ตัดสินขั้นสุดท้ายและกลับผลได้ - Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
คาดการณ์การยิงอาวุธบนไคลเอนต์แล้วเล่นเอฟเฟกต์ไปก่อน จากนั้นแก้ความคลาดเคลื่อนของการคาดการณ์ด้วยผลจากเซิร์ฟเวอร์
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: การออกแบบการซิงก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กดไม่ติด/โรลแบ็ค)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง