คู่มือเกมแลค › การออกแบบการซิงก์
แสดงผลหลังเซิร์ฟเวอร์ตอบเท่านั้น (แบบ request-response) Request-response (no client-side feedback)
ID สาเหตุ sy-request-response · ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
กดปุ่มแล้วไม่มีทั้งแอนิเมชันและเสียงจนกว่าคำตอบจากเซิร์ฟเวอร์จะมาถึง ปิงจึงกลายเป็นความเร็วในการตอบสนองโดยตรง
ทำไม แสดงผลสกิล, การเดิน และการเก็บของ หลังจากเซิร์ฟเวอร์ยืนยันแล้ว → ผลคือ ตั้งแต่วินาทีที่กดจะไม่มีปฏิกิริยาใด ๆ เป็นเวลาเท่ากับเวลาไปกลับ + เวลารอทิก → บนหน้าจอ ถ้าปิง 150 ms ทุกการกระทำจะตอบสนองช้าไปครั้งละ 0.2 วินาที
อาการ อินพุตดีเลย์ ปัจจัย ความหน่วง
ใครเจอ เราคนเดียว
เกิดเมื่อไร ตลอดเวลา, ตอนทำแอ็กชันบางอย่าง
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม ไคลเอนต์: เริ่มแอนิเมชัน, เสียง และเอฟเฟกต์ทันทีที่กด (การแสดงผลล่วงหน้า), แสดงเฉพาะผลลัพธ์ (ดาเมจ, ของรางวัล) หลังเซิร์ฟเวอร์ยืนยัน, การเดินและการโจมตีปกติให้ใช้ prediction แสดงผลทันที, เมื่อได้รับตำแหน่งที่เซิร์ฟเวอร์แก้มา ให้ใช้อินพุตที่ยังไม่ได้รับการยืนยันซ้ำจากตำแหน่งนั้น เซิร์ฟเวอร์: คำนวณการเคลื่อนที่เองจากอินพุตที่ได้รับ และส่งค่าแก้กลับไปเฉพาะเมื่อตำแหน่งต่างจากที่ไคลเอนต์คาดการณ์เกินเกณฑ์
ตัวเลขที่ควรรู้ เวลาตอบสนอง ≈ ปิง + ครึ่งหนึ่งของช่วงห่างระหว่างทิก + หนึ่งเฟรม ที่ 20 ทิกและปิง 150 ms จะได้ประมาณ 190 ms
บนกราฟ จุดที่ต้องดู บันทึกเวลาที่กดปุ่ม, เวลาที่แอนิเมชันหรือเสียงแรกเริ่ม และเวลาที่คำตอบจากเซิร์ฟเวอร์มาถึง ลงใน log ไคลเอนต์ของ dev build แล้วดูคู่กับ RTT ในเกม วัดโดยเปลี่ยนปิงไปเรื่อย ๆ ด้วยการใส่ดีเลย์ผ่าน network emulation ของเอนจิน (Unreal NetEmulation.PktLag) หรือ tc netem ของ Linux บนเซิร์ฟเวอร์ทดสอบ สัญญาณว่าใช่ การแสดงผลเริ่มพร้อมกับที่คำตอบจากเซิร์ฟเวอร์มาถึงทุกครั้ง เวลาตั้งแต่อินพุตจนแสดงผลเท่ากับ RTT + เวลารอทิก และเพิ่มขึ้นตามดีเลย์ที่ใส่เข้าไปพอดี สัญญาณว่าไม่ใช่ การแสดงผลเริ่มทันทีที่กดและมีแค่ผลลัพธ์อย่างตัวเลขดาเมจที่ช้า: เป็นการออกแบบปกติ ถ้าช้าเกินช่วงห่างระหว่างทิกแม้ในที่ที่ปิงต่ำ น่าจะเป็นการรอทิกซ้อนสองชั้นหรือปัญหาเฟรมฝั่งไคลเอนต์ วิธีตรวจ ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
รายละเอียดเพิ่มเติม เกมที่ไม่ต้องการการตอบสนองเร็ว เช่น เกมเทิร์นเบส, เกมการ์ด และเกม idle วิธีนี้ง่ายและปลอดภัยที่สุด ปัญหาเกิดเมื่อเกมที่มีการควบคุมแบบเรียลไทม์ทำแม้แต่การเดินหรือการโจมตีปกติด้วยวิธีนี้
แหล่งอ้างอิง Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve ไคลเอนต์ที่รอแต่ผลจากเซิร์ฟเวอร์ ถ้าดีเลย์ 500 ms ทุกการกระทำจะเห็นผลหลังผ่านไป 500 ms แก้ด้วย client-side prediction และ reconciliation Using Gameplay Abilities in Unreal Engine Epic Games Local Predicted ทำงานทันทีที่กดและให้เซิร์ฟเวอร์ตัดสินขั้นสุดท้าย ส่วน Server Initiated ไม่มี prediction ผู้ใช้สกิลจึงเห็นดีเลย์ Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games ไคลเอนต์คาดการณ์และเก็บการเคลื่อนที่ไว้ และแก้ตำแหน่งเฉพาะเมื่อความคลาดเคลื่อนจากเซิร์ฟเวอร์เกินค่าที่ยอมรับได้ (MAXPOSITIONERRORSQUARED) แล้วใช้การเคลื่อนที่ที่เก็บไว้ซ้ำหลังแก้ Using Network Emulation in Unreal Engine Epic Games ทดสอบโดยใส่ดีเลย์ต่ำสุด/สูงสุดและอัตราแพ็กเก็ตหายให้เซิร์ฟเวอร์และไคลเอนต์, ในคอนโซลตั้งค่าแบบ NetEmulation.PktLag tc-netem(8) — Linux manual page iproute2 เครื่องมือทดสอบที่ใส่ดีเลย์/จิตเตอร์ (delay TIME JITTER) และการหาย (loss random PERCENT) ให้แพ็กเก็ตขาออก เพื่อจำลองเครือข่ายจริง สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: การออกแบบการซิงก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง