เหตุใดเกมเครือข่ายบางเกมจึงใช้การแก้ไขและบางเกมใช้การกำหนดเส้นทางสำหรับการเคลื่อนที่ระยะไกล

นี่เป็นคำถามเปิดเล็กน้อย แต่ฉันต้องการเห็นใครบางคนให้เหตุผลที่ดีสำหรับทั้งคู่

สำหรับตัวอย่างรวดเร็วของทั้งสอง:

แบบจำลองการแก้ไข

คิดว่ารูปแบบ Valve ที่ลูกค้าได้รับการอัปเดตตำแหน่งบ่อยครั้งและรีโมตอัพเดตตำแหน่งโดยใช้การแก้ไขข้อมูลนี้

เส้นทางการค้นพบ

ในรูปแบบนี้คิดว่าผู้ใช้ส่งปลายทางและทุกคนหาเส้นทางไป

เกมประเภทใดที่เหมาะสมกับแต่ละเกมและเมื่อใดควรใช้เกมแต่ละเกม

ฉันทำงานกับรหัสเครือข่ายสำหรับเกมเครือข่าย AAA แบบเรียลไทม์สองเกมเกมหนึ่งสำหรับสมาร์ทโฟนและเกมคอนโซลมือถือ

หากต้องการตอบคำถามของคุณโดยตรงว่า "ทำไม" เกมบางเกมใช้เกมหนึ่งหรือเกมอื่นเพราะมันเหมาะกับเกมมากกว่าเกมอื่น ไม่เพียงขึ้นอยู่กับประเภทของเกมเท่านั้น แต่ยังขึ้นอยู่กับประเภทของเครือข่ายที่เรากำลังพูดถึงด้วย (ตู้อาเขตเชื่อมโยงมีเงื่อนไขที่แตกต่างเมื่อเทียบกับเกมที่ตั้งใจเล่นผ่าน 3G) บางเกมใช้จริงหรือทั้งคู่ วิธีการที่แตกต่างกันในการประสานข้อมูล!

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

แทนที่จะเป็นไปได้สองทางฉันขอเสนอสเปคตรัมระหว่างการอัพเดตแบบแข็งและแบบนุ่ม

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

  ด้วยวิธีนี้ความล่าช้าของเครือข่ายจะแสดงอย่างสม่ำเสมอว่าเป็นการอัปเดตที่ล่าช้าและรายการในขณะที่ตัวละครกระโดดไปมา

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

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

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

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

  การวางแผนการอัพเดทข้อมูลด้วยตนเองนั้นอาจเป็นเรื่องยาก / นุ่มนวลตามที่คุณต้องการแน่นอน

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

  อีกตัวอย่างที่ไม่ใช่เครือข่ายนี้จะอยู่ใน Civilization 4 ที่เปิดใช้งานภาพเคลื่อนไหวการต่อสู้ เมื่อคุณโจมตีใครบางคนผลของการต่อสู้จะถูกคำนวณทันที แต่คุณจะได้เห็นภาพเคลื่อนไหวของการเล่น ฉันรับรองได้เลยว่าการต่อสู้ไม่ได้ถูกคำนวณเนื่องจากมันมีชีวิตชีวา

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

ฉันไม่เข้าใจกระบวนการพัฒนาของ Valve ดังนั้นนี่เป็นความเห็นของฉันอย่างหมดจด แต่:

การแก้ไข : ฉันจะบอกว่ามันจะดีกว่าสำหรับเกมที่รวดเร็วเช่น FPSs ซึ่งการมีตำแหน่งที่สอดคล้องกันสำหรับศัตรูตรงเวลาข้ามผู้เล่นเป็นสิ่งสำคัญ การแก้ไขหมายถึงแม้ว่าบางแพ็กเก็ตจะถูกทิ้ง (AFAIK ผู้เล่นหลายคนส่วนใหญ่ใช้ FPSs UDP แทน TCP / IP ซึ่งรับประกันความสมบูรณ์หรือลำดับที่แพ็กเก็ตมาถึง) คุณจะมีการเคลื่อนไหวที่ราบรื่นบนหน้าจอ

การค้นหาเส้นทาง : หากเวลาไม่ใช่องค์ประกอบที่สำคัญของการเล่นเกมของคุณและอัลกอริธึมของคุณค้นหาเส้นทางที่สอดคล้องกันเมื่อวิ่งอีกครั้งการหาเส้นทางอาจน่าสนใจเพราะมันไม่ต้องการให้คุณส่งบ่อยๆ เอกลักษณ์ ฉันว่านี่ดูเหมือนว่าเหมาะสำหรับระบบที่ใช้ระบบเลี้ยวตัวอย่างเช่นที่คุณสามารถ จำกัด จำนวนการร้องขอเครือข่าย (หนึ่งที่จุดเริ่มต้นของเทิร์นหนึ่งเมื่อหันไปเพื่อให้แน่ใจว่าลูกค้าทั้งหมดอยู่ใน "สติ " สถานะ.

อีกครั้งฉันไม่เคยทำงานในเกมเครือข่ายหรือสตูดิโอเกมใหญ่ แต่จากสิ่งที่ฉันอ่านบางครั้งนั่นเป็นวิธีที่ฉันจะทำ :)

คำตอบของ Panda Pajama ค่อนข้างดี

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

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

อย่างไรก็ตามเขาไม่ได้พูดถึงวิธีใดวิธีหนึ่ง ผลการบังคับ

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

ตัวอย่างในโลกแห่งความจริงคือสิ่งอื่น ๆ ทั้งหมดในรูปแบบการถือครองเพื่อให้แน่ใจว่าการจ่ายค่าชดเชยที่เหมาะสมนั้นถูกส่งมาให้ฉัน