คุณออกแบบระบบบันทึก / เล่นซ้ำสำหรับเกมที่เปลี่ยนแปลงบ่อยได้อย่างไร?


10

ฉันทำงานใน MMORPG ฟรีและฉันมีปัญหา

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

ปัญหาคือ: เมื่อเราเปลี่ยนระหว่างเวอร์ชั่นของเกมมันยากที่จะรักษาความเข้ากันได้ย้อนหลังสำหรับวิดีโอ (คำสั่งเพิ่ม / ลบการเปลี่ยนฟังก์ชั่น ฯลฯ ) มีวิธีที่ดีในการจัดการปัญหานี้หรือไม่? แทนที่จะมีผู้เล่นที่แตกต่างกันและเลือกผู้เล่นที่ใช่สำหรับไฟล์วิดีโอแต่ละรุ่น?

มันจะช่วยได้มากหากรู้ว่าเกมอื่น ๆ จัดการกับสถานการณ์นี้อย่างไร

ขอบคุณสำหรับความช่วยเหลือขอโทษด้วยภาษาอังกฤษของฉัน


เช่นเดียวกับอาหารอื่น ๆ สำหรับ googling / การค้นคว้า: วิธีที่คุณทำมันคือวิธีที่ Quake Games บันทึกการสาธิตโดยการจับภาพแพคเกจเซิร์ฟเวอร์ เท่าที่ฉันทราบพวกเขาก็ไม่เคยแก้ไขปัญหาความเข้ากันได้
Michael Stum

ฉันได้เปลี่ยนชื่อของคำถามนี้ - มันไม่ได้เกี่ยวกับ MMO จริงๆยกเว้น MMO นั้นเป็นเกมที่เปลี่ยนแปลงบ่อยที่สุด

คำตอบ:


8

กฎพื้นฐานของเราคือไม่เปลี่ยนประเภทแพ็คเก็ตที่มีอยู่ ทุกอย่างจะถูกเพิ่มในตอนท้ายของคำสั่งที่มีอยู่หรือคำสั่งใหม่ สิ่งนี้ยังทำให้มีโอกาสน้อยที่คนสองคนจะเหยียบย่ำงานของกันและกัน


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

1
ใช่เลิกใช้แล้วทิ้งไว้ที่นั่น ในที่สุดสิ่งเก่าสามารถลบออกได้ แต่โดยปกติจะเป็นหลังจากหนึ่งหรือสองปี
coderanger

1
นอกจากนี้การวางแผนพิเศษบางอย่างก็ช่วยได้เช่นกัน ยิ่งคุณวางแผนแพ็กเก็ตได้ดีขึ้นเท่าไหร่การเปลี่ยนแปลงที่คุณต้องทำในอนาคตก็จะน้อยลง
Kylotan

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

3
การใช้ประเภทแพ็คเก็ตทั่วไปจะช่วยคุณได้มากขึ้นที่นี่ คุณไม่จำเป็นต้องเพิ่มข้อความใหม่สำหรับคุณสมบัติใหม่ทุกอย่างที่คุณใช้
Kylotan

5

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


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

ขอบคุณสำหรับคำตอบของคุณเกมนี้ให้บริการฟรี (ได้รับอนุญาตจาก GPL) ดังนั้นทุกคนสามารถเข้าถึงเกมรุ่นเก่าและแม้แต่คอมไพล์ไคลเอนต์ได้ นี้ใช้มากไม่เซิร์ฟเวอร์ทางเลือกทั้งหมดใช้ latests รุ่นมีเซิร์ฟเวอร์ที่ใช้รุ่นตั้งแต่ปี 2004 ..
Marco

@Marco: ฉันสงสัยว่าการทำงานของ SC2 นั้นคือการใส่รหัสเกือบทั้งหมดใน DLL เมื่อโหลดรีเพลย์จะทำการตรวจสอบเวอร์ชั่นและโหลด DLL สำหรับเวอร์ชั่นนั้นและรัน มันค่อนข้างซับซ้อนกว่าเล็กน้อย แต่ผู้ใช้ต้องการเพียงหนึ่งการติดตั้งเท่านั้นและ exe หนึ่งตัวสามารถเรียกใช้รีเพลย์เก่าทั้งหมดได้
Mooing Duck

1

วิธีการหนึ่งในการแก้ไขปัญหานี้เป็นไปตามเกมที่เรียกว่า "Heroes of Newerth" (ซึ่งเปลี่ยนทุก +/- 2 สัปดาห์) จากสิ่งที่ฉันบอกได้:

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

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

ไม่เช่นนั้นหรือพวกเขาเพิ่มแพตช์เอนทิตีเพื่อเล่นซ้ำ (เช่น spell X มีเอฟเฟกต์ Y แทนเอฟเฟกต์ Z) หากมีการจัดเก็บข้อมูลที่เกี่ยวข้องกับแพ็คเก็ตในการกำหนดค่าเอนทิตีนี้เอนทิตีฮอตแพ็ตช์นี้จะช่วยให้คุณเข้าใจแพ็คเก็ตที่เก่ากว่าเช่นกัน

แน่นอนว่าฉันจะไม่เก็บพฤติกรรมทางประวัติศาสตร์ไว้บนไคลเอนต์ โดยเฉพาะอย่างยิ่งเมื่อไคลเอนต์กำลังอัปเดตจากเช่น 10.1.0 เป็น 10.2.0 (เนื่องจากพวกเขาต้องการดาวน์โหลดแพทช์ทุกครั้งระหว่างสองเวอร์ชันแทนที่จะเป็นแพทช์สุดท้าย)

Google Protobuf เป็นความคิดที่ดีในฐานะเลเยอร์การทำให้เป็นอนุกรมเพราะมันสนับสนุนสิ่งนี้โดยการออกแบบ

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