คู่มือเกมแลค › ค้นหาตามอาการ

ดีดกลับ: 14 สาเหตุและทีมที่ต้องแก้

เรียกอีกอย่างว่า: โดนดึงกลับ, rubber banding, ตำแหน่งย้อนกลับ

เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →

ตัวละครของเรากำลังเดินหน้า แล้วโดนดึงกลับไปยังจุดที่เพิ่งผ่านมา

วิ่งอยู่ดี ๆ ก็โดนดึงถอยหลัง 1–5 เมตร บางครั้งต้องเดินผ่านช่วงเดิมซ้ำสองสามรอบ

ภาพบนจอเรา (prediction) กับผลตัดสินของเซิร์ฟเวอร์ไม่ตรงกัน อาจเพราะอินพุตของเราไปไม่ถึงเซิร์ฟเวอร์ (แพ็กเก็ตหาย), เซิร์ฟเวอร์ตรวจการเคลื่อนที่แล้วตัดทิ้ง หรือสองฝั่งคำนวณการเคลื่อนที่ไม่เหมือนกัน

สาเหตุที่ทำให้เกิดอาการนี้

L1 โปรเซสเกมฝั่งไคลเอนต์

• client-side prediction ไม่ตรงกับเซิร์ฟเวอร์: ไคลเอนต์ของเราแสดงการเคลื่อนที่ไปก่อน แต่ถ้าเซิร์ฟเวอร์คำนวณออกมาต่างกัน ตัวละครของเราจะโดนดึงกลับ (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))

L3 เครือข่ายในบ้าน

• Wi-Fi ถูกรบกวนหรือสัญญาณอ่อน: ถ้าสัญญาณอ่อนหรือถูกรบกวน ช่วงไร้สายต้องส่งซ้ำหลายรอบ แพ็กเก็ตจึงมาถึงไม่สม่ำเสมอ (ภายนอก (ภายนอก))

L4 เส้นทางอินเทอร์เน็ต

• จุด peering แออัดช่วงพีค: ช่วงหัวค่ำราว 21:00–23:00 ทราฟฟิกวิดีโอพุ่งขึ้นมาก จุดเชื่อมต่อระหว่าง ISP (peering) จึงมักแออัด (อินฟราเครือข่าย (ทีมอินฟรา))
• เส้นทาง ECMP เส้นหนึ่งเสีย: ISP และดาต้าเซ็นเตอร์มีหลายเส้นทางไปยังปลายทางเดียวกัน และกำหนดเส้นทางหนึ่งเส้นให้แต่ละการเชื่อมต่อ ถ้าเสียแค่เส้นเดียว คนที่ถูกจัดให้ใช้เส้นนั้นจะแลคอยู่ตลอด (อินฟราเครือข่าย (ทีมอินฟรา))

L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

• สายเสีย/พอร์ตมี error: ถ้าโมดูลออปติกหรือสายเสีย แพ็กเก็ตที่ผ่านเส้นทางนั้นจะเสียหายในสัดส่วนคงที่ (อินฟราเครือข่าย (ทีมอินฟรา))

L6 การ์ดเครือข่ายของเซิร์ฟเวอร์

• อินเทอร์รัปต์ของ NIC กระจุกที่คอร์เดียว: ถ้า NIC ส่งอินเทอร์รัปต์แจ้งว่าแพ็กเก็ตมาถึงไปที่คอร์ CPU เพียงคอร์เดียว คอร์นั้นจะกลายเป็นคอขวด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

• ย้ายโซน (ส่งต่อตัวละครข้ามเซิร์ฟเวอร์): เมื่อเข้าพื้นที่หรือดันเจี้ยนอื่น ขั้นตอนส่งข้อมูลตัวละครไปยังเซิร์ฟเวอร์อื่นทำให้เกิดดีเลย์และความล้มเหลว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• matchmaking/การจัดรีเจียนผิดพลาด: ถ้าถูกจัดไปเซิร์ฟเวอร์ในรีเจียนที่ไกลแทนรีเจียนที่ใกล้ ผู้เล่นคนนั้นจะปิงสูงตลอดแม้เน็ตจะปกติ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

การออกแบบการซิงก์

• เซิร์ฟเวอร์ตรวจสอบเข้มงวดเกินไป: ถ้าเซิร์ฟเวอร์ตรวจความเร็วการเคลื่อนที่, คูลดาวน์ และระยะเข้มงวดเกินไป จะปฏิเสธแม้อินพุตปกติที่มาถึงรวมกันเพราะจิตเตอร์ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แสดงผลล่วงหน้าแล้วเซิร์ฟเวอร์ปฏิเสธ: ถ้าการโจมตีหรือสกิลที่จอเราแสดงไปก่อนแล้วถูกเซิร์ฟเวอร์ปฏิเสธทีหลัง ผลที่เห็นกับตาจะกลายเป็นเหมือนไม่เคยเกิดขึ้น (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• การคำนวณเส้นทางไม่ตรงกันในการซิงก์คำสั่ง: ถ้ารับส่งแค่ “ให้ไปที่นี่” แล้วแต่ละฝั่งคำนวณเส้นทางเอง เมื่อการคำนวณต่างกันแม้เพียงเล็กน้อย ตัวละครหรือมอนสเตอร์จะเดินไปคนละเส้นทางแล้วถูกดึงกลับมาที่ตำแหน่งที่ถูกต้อง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ปัญหาที่เกิดกับบางคนเท่านั้น

• false positive ของการตรวจสอบที่กระจุกกับผู้ใช้บาง ISP: คนที่ใช้เน็ตที่จิตเตอร์สูง อินพุตจะไปถึงเป็นกลุ่ม จึงติดการตรวจความเร็วและคูลดาวน์ของเซิร์ฟเวอร์บ่อย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ต้นเหตุของการส่งซ้ำใน TCP

• คิวคอขวดล้น (แพ็กเก็ตหายจากความแออัด): จุดที่แคบที่สุดบนเส้นทาง เช่น เราเตอร์, ลิงก์เชื่อมระหว่าง ISP หรือลิงก์ของดาต้าเซ็นเตอร์ เมื่อคิวตรงนั้นเต็ม แพ็กเก็ตที่มาใหม่จะถูกทิ้ง (อินฟราเครือข่าย (ทีมอินฟรา))
• ACK มาช้าหรือหาย (อัปโหลดเต็ม): ข้อมูลมาถึงเรียบร้อย แต่ถ้า ACK ที่บอกว่า “ได้รับแล้ว” ไปติดอยู่ในคิวอัปโหลดที่เต็มจนช้าหรือหาย ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ (ภายนอก (ภายนอก))

ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ