วิธีการจัดโครงสร้างเซิร์ฟเวอร์เกมอย่างง่ายสำหรับเกมที่มีผู้เล่นหลายคน


9

ฉันต้องการสร้างเซิร์ฟเวอร์เกมที่เล่นง่ายสำหรับผู้เล่นหลายคนสำหรับเกมง่ายๆ:

เกมดังกล่าวจะคล้ายกับ Command & Conquer คุณมีรถถังและทหารไม่กี่คน คุณสามารถเลือกทหารหนึ่งคนและคลิกกว่าแผนที่เพื่อไปยังที่ที่ทหารควรไป หากทหารมาถึงพื้นที่ที่เขาไม่สามารถไปได้เขาจะเดินไปรอบ ๆ และทหารสามารถยิงศัตรูได้

ฉันควรจัดโครงสร้างเซิร์ฟเวอร์เกมอย่างไรและควรทำอะไรที่ไคลเอนต์

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

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

คำตอบ:


12

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

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

ฉันไม่สามารถบอกวิธีแก้ปัญหาสำหรับ RTS ได้อย่างแน่นอน สิ่งที่เราทำเพื่อการยิง FPS ของเราคือให้เซิร์ฟเวอร์บันทึกสถานะโลกที่สมบูรณ์ในขณะที่กลับมาและปล่อยให้ลูกค้าบันทึกทุกนัด เมื่อข้อความเครือข่ายสำหรับ "ฉันยิง!" มาถึงเซิร์ฟเวอร์เซิร์ฟเวอร์สามารถย้อนกลับไปทั่วโลกและทำการทดสอบการชนกัน ฯลฯ บนโลก "เพราะมองหาไคลเอนต์เมื่อถูกยิง"

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

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

ข้อเสนอแนะที่ดีที่สุดของฉันคือการตัดสินใจเบื้องต้นและเริ่มทำงานเพื่อทดสอบมันขึ้นอยู่กับความซับซ้อนของโครงการนี้และความพยายามที่คุณยินดีใช้จ่าย


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

2
โอ้และคุณสามารถแก้ปัญหาอันดับที่ 2 ได้โดยการแนะนำความล่าช้าแบบประดิษฐ์ซึ่งเท่ากับค่าเฉลี่ยของความล่าช้าของผู้เล่นคนอื่น ถ้าคุณเรียกว่า "ทำให้ไม่ดีต่อทุกคน" ทางออกก็คือ
Bart van Heukelom

@Bart: จริง ๆ แล้วบางส่วน แต่แน่นอนว่าควรมีการจำกัดความล่าช้าที่คุณแนะนำไว้หรือการเชื่อมต่อที่ช้าลงอาจบังคับให้การเชื่อมต่อที่ช้ากว่ามากเกินไปซึ่งเป็นสิ่งที่คุณต้องการอย่างแน่นอน
o0 '

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

2

โดยทั่วไปมีสองวิธี:

  1. ลูกค้าที่เชื่อถือได้
  2. ลูกค้าที่ไม่ไว้วางใจ

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

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

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


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

1
"ฉันจะไม่มีผู้เล่นมากมาย ... " ฉันไม่สามารถนับจำนวนนักพัฒนาที่ให้สายนั้นและกลับมาอีกหกสัปดาห์ต่อมาด้วย: "ฉันมีผู้เล่น 5,000 คนที่ต้องการจ่ายเพื่อเล่นเกมของฉัน แต่ฉันไม่สามารถปรับขนาดได้ :( ". โปรดจำไว้!
Andreas

9
"ลูกค้าที่เชื่อถือได้" ไม่ใช่วิธีการ แต่เป็นความผิดพลาด
o0 '
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.