ใช้การจำลองทางฟิสิกส์บนทั้งไคลเอนต์และเซิร์ฟเวอร์หรือไม่?

ฉันใช้ดาวเคราะห์น้อยแบบผู้เล่นหลายคนเพื่อเรียนรู้เกี่ยวกับสถาปัตยกรรมเครือข่ายไคลเอ็นต์ / เซิร์ฟเวอร์ในเกม ฉันใช้เวลาในการอ่านสิ่งพิมพ์ของ GafferOnGames และ Valve บนเทคโนโลยีไคลเอ็นต์ / เซิร์ฟเวอร์ของพวกเขา ฉันมีปัญหากับสองแนวคิด

1. ขณะนี้ฉันมีเซิร์ฟเวอร์เกมจำลองสถานการณ์จริงที่มี box2d และส่งสถานะของโลกให้กับลูกค้าประมาณ 20 ครั้งต่อวินาที ลูกค้าแต่ละรายติดตามสแน็ปช็อตสองสามครั้งสุดท้ายที่ได้รับและ lerps ระหว่างสองสถานะเพื่อให้การเคลื่อนไหวของสไปรต์ราบรื่นขึ้น อย่างไรก็ตามมันไม่ราบรื่น มันอาจจะราบรื่นสักพักหนึ่งแล้วก็กระตุกนิดหน่อยจากนั้นก็กลับมาราบรื่น ฯลฯ ฉันลองทั้ง TCP และ UDP แล้วทั้งคู่ก็เหมือนกัน ความคิดใดที่ปัญหาของฉันอาจเป็นอย่างไร (หมายเหตุ: ฉันใช้สิ่งนี้กับผู้เล่นคนแรกก่อนและการเคลื่อนไหวของสไปรต์นั้นราบรื่นที่ 60fps เมื่ออัปเดตโลกฟิสิกส์เพียง 20 ครั้งต่อวินาที)

2. เพื่อที่จะแก้ปัญหาแรกฉันคิดว่าบางทีไคลเอนต์ควรรันการจำลอง box2d ด้วยเช่นกันและเพียงแค่อัปเดตตำแหน่งของสไปรต์เพื่อให้ตรงกับสแนปชอตของเซิร์ฟเวอร์เมื่อพวกเขาไม่ตรงกัน ฉันคิดว่านี่อาจราบรื่นกว่าเนื่องจากการใช้ผู้เล่นคนเดียวของฉันราบรื่น นี่เป็นความคิดที่ดีหรือไม่?

   แม้ว่ามันจะไม่สามารถแก้ไขปัญหาข้างต้นได้มันจำเป็นสำหรับการทำนายลูกค้าหรือไม่? ตัวอย่างเช่นหากผู้เล่นพยายามเคลื่อนย้ายเรือของพวกเขาพวกเขาจะรู้ได้อย่างไรว่าพวกเขายิงยานอวกาศดาวเคราะห์ผนังหรือศัตรูโดยไม่มีการจำลองทางฟิสิกส์? ดูเหมือนว่าเรือของพวกเขาจะปรากฏขึ้นเพื่อผ่านวัตถุที่มันควรจะชนกันก่อนที่พวกเขาจะได้รับสแนปชอตจากเซิร์ฟเวอร์ที่ระบุว่าพวกเขาชนกับวัตถุ

ขอบคุณ!

เรียกใช้การจำลองบนไคลเอนต์และเซิร์ฟเวอร์แน่นอน สิ่งอื่นใดมีเวลาแฝงนานเกินไป คุณควรตรวจสอบให้แน่ใจว่าแบบจำลองตรงกันโดยการแทรกวัตถุในลำดับเดียวกันโดยใช้ขั้นตอนเวลาที่แน่นอนและหลีกเลี่ยงการเปรียบเทียบตัวชี้ ฉันไม่ได้ลองกับ Box2D แต่โดยทั่วไปแล้วมันเป็นไปได้ที่จะบรรลุพฤติกรรมเดียวกันในทุกเครื่องในการจำลองทางฟิสิกส์ คณิตศาสตร์ทั้งหมดมักขึ้นอยู่กับ IEEE 754 binary32 ลอยและพฤติกรรมของพวกเขาจะถูกกำหนดอย่างเคร่งครัดสำหรับการดำเนินงานเช่น+-*/การตั้งชื่อไม่กี่ คุณจะต้องระมัดระวังเกี่ยวกับsin,cosและสิ่งที่ชอบยากเนื่องจากพวกเขาสามารถแตกต่างกันระหว่าง runtimes (นี้เป็นสิ่งสำคัญโดยเฉพาะอย่างยิ่งเมื่อการพัฒนาสำหรับหลายแพลตฟอร์ม) ตรวจสอบให้แน่ใจด้วยว่าคุณใช้การตั้งค่าที่เข้มงวดสำหรับการปรับให้เหมาะสมแบบลอยในคอมไพเลอร์ของคุณ คุณยังสามารถซิงโครไนซ์วัตถุได้โดยส่งสถานะของวัตถุออกจากเซิร์ฟเวอร์เป็นระยะ อย่าอัปเดตเว้นแต่ความแตกต่างใหญ่กว่าเกณฑ์เพื่อหลีกเลี่ยงการพูดติดอ่างที่ไม่จำเป็น

ปัญหาหนึ่งที่นึกถึงคือการสร้างวัตถุใหม่และวิธีที่จะเปลี่ยนการจำลองระหว่างไคลเอนต์ วิธีหนึ่งในการแก้ไขปัญหานี้คือการให้เซิร์ฟเวอร์สร้างวัตถุทั้งหมด หากขั้นตอนเวลาปัจจุบันเป็นเซิร์ฟเวอร์จะกำหนดวัตถุที่จะเพิ่มที่t t+dดังนั้นรายการวัตถุใหม่ที่มีวัตถุที่จะเพิ่มและเมื่อจะเพิ่มพวกเขาสามารถรักษาได้ที่ลูกค้าทั้งหมดและปรับปรุงโดยเซิร์ฟเวอร์ล่วงหน้า หากdมีขนาดใหญ่พอคุณลดความเสี่ยงของผลลัพธ์ที่แตกต่างกัน หากคุณไม่สามารถจัดการกับความแตกต่างได้คุณสามารถบังคับให้ลูกค้ารอข้อมูลเกี่ยวกับวัตถุใหม่ในช่วงเวลาหนึ่งก่อนที่จะจำลองขั้นตอนเวลานั้น

มันอาจดูไม่ดีนักเนื่องจากการแก้ไขระหว่างกันนั้นอาศัยการมีชุดข้อมูลถัดไปเพื่อทำการแทรกเสมอ ซึ่งหมายความว่าหากมีความล่าช้าเล็กน้อยทุกอย่างต้องรอให้ทัน

มีบทความเก่า ๆเกี่ยวกับGameDevเกี่ยวกับการใช้ลูกบาศก์ splines เพื่อทำนายตำแหน่งของวัตถุผ่านจุดที่คุณมีข้อมูลล่าสุด สิ่งที่คุณทำคือใช้ตำแหน่งนั้นและปรับเส้นโค้งเมื่อคุณได้รับข้อมูลใหม่เพื่อบัญชีสำหรับตำแหน่งใหม่ นอกจากนี้ยังอาจถูกกว่าการใช้การจำลองทางฟิสิกส์ครั้งที่สองมากและหมายความว่าคุณไม่จำเป็นต้องตัดสินใจเกี่ยวกับคนที่คุณไว้วางใจเนื่องจากคุณใช้งานไคลเอนต์อย่างชัดเจนเพื่อสร้างมันขึ้นมา :)

ฉันได้ทำสิ่งที่คล้ายกันตัวเองและฉันวิ่ง Box2D เฉพาะลูกค้า วิธีที่ฉันทำก็คือให้ลูกค้าเรียกใช้การจำลองของตัวเองด้วยตัวเองโดยส่งความเร็วปัจจุบัน (และการหมุน) บนทุก ๆ แพ็คเก็ตซิงค์ไปยังเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะส่งข้อมูลนี้ไปยังผู้เล่นอื่นซึ่งตั้งค่าความเร็วที่ได้รับใหม่ไปยังเอนทิตีที่จำลองแบบ มันราบรื่นมากโดยไม่มีความแตกต่างที่เห็นได้ชัดเจนระหว่างลูกค้า

แน่นอนปัญหาที่นี่คือไม่มีการควบคุมจากส่วนกลางสำหรับเอนทิตี แต่ฉันคิดว่าสามารถทำได้บนฝั่งเซิร์ฟเวอร์ด้วยโดยทำการจำลองฝั่งเซิร์ฟเวอร์ของฟิสิกส์เช่นกัน

โดยส่วนตัวฉันชอบที่จะเรียกใช้การจำลองบนเซิร์ฟเวอร์เท่านั้นและให้ถ่ายทอดการเปลี่ยนแปลงใด ๆ เกี่ยวกับความเร็วเชิงเส้น / เชิงมุม / การเร่งความเร็วของวัตถุที่เกี่ยวข้องทุกครั้งที่เกิดขึ้น เมื่อวัตถุบางอย่างเปลี่ยนคุณสมบัติทางกายภาพใด ๆ (เช่นความเร็วและการเร่งความเร็วดังกล่าว) การเปลี่ยนแปลงเฉพาะนี้จะถูกส่งจากเซิร์ฟเวอร์ไปยังไคลเอนต์และลูกค้าจะเปลี่ยนด้านข้างของ ข้อมูลของวัตถุตาม

ข้อได้เปรียบของมันในการใช้งานในปัจจุบันของคุณคือมันจะเป็นโมฆะความจำเป็นของการแก้ไขลูกค้าและจะสร้างพฤติกรรมที่ซื่อสัตย์มากในวัตถุ ปัญหาคือว่าวิธีนี้ค่อนข้างเสี่ยงต่อความล่าช้าซึ่งเป็นปัญหาใหญ่มากเมื่อผู้เล่นอยู่ห่างจากกันมากเกินไป

สำหรับคำถามที่ 1 ฉันบอกว่าปัญหาน่าจะเกิดจากความล่าช้าในการตอบสนองเนื่องจากไม่มีการรับประกันที่แน่นอนว่าจะมีช่วงเวลาที่สมบูรณ์แบบ 20 วินาทีที่สมบูรณ์แบบระหว่างการรับสแนปชอตแต่ละครั้ง ให้ฉันอธิบาย (เป็น "t" เวลาที่วัดในหน่วยมิลลิวินาที):

1) ที่ t = 20 ตั้งแต่เริ่มเกมลูกค้าได้รับสแนปชอตและทำการแก้ไขสำเร็จและราบรื่น

2) ที่ t = 40 มีความล่าช้าระหว่างเซิร์ฟเวอร์และไคลเอนต์และสแน็ปช็อตเกิดขึ้นที่ t = 41 เท่านั้น

3) ที่ t = 60 เซิร์ฟเวอร์ส่งสแน็ปช็อตอีกครั้ง แต่หนึ่งวินาทีของการจำลองนั้นเสียลูกค้าไปเนื่องจากความล่าช้า หากสแน็ปช็อตมาถึงที่ t = 60 ไคลเอนต์จะไม่ทำการแก้ไขของ 40 และ 60 instants แต่จริง ๆ แล้วจาก instants 41 ถึง 60 สร้างลักษณะการทำงานที่แตกต่างกัน ความไม่แน่นอนนี้อาจเป็นสาเหตุของ "กระตุก" ในที่สุด

สำหรับคำถามที่ 2 ความคิดของคุณอาจใช้งานได้หากคุณใช้สิ่งที่จะติดตามได้อย่างมีประสิทธิภาพว่าแต่ละออบเจ็กต์นั้นทำข้อมูลลูกค้ากับเซิร์ฟเวอร์โดยไม่ต้องส่งแพคเกจแต่ละเฟรมเพื่อแจ้งตำแหน่งของวัตถุ แม้ว่าคุณจะทำตามช่วงเวลาที่ไม่ต่อเนื่องคุณจะไม่เพียง แต่ทำงานในปัญหาเดียวกันของคำถามที่ 1 เท่านั้น แต่ยังมีข้อมูลจำนวนมากเกินไปที่จะถ่ายโอนไปมา (ซึ่งเป็นสิ่งที่ไม่ดี)