การสร้างขั้นตอนการอัปเดตเกมและเอฟเฟกต์ผีเสื้อ

หมายเหตุ: ฉันถามสิ่งนี้ใน Stack Overflow เมื่อสองสามวันก่อน แต่มีมุมมองน้อยมากและไม่มีการตอบสนอง คิดว่าฉันควรถาม gamdev.stackexchange แทน

นี่เป็นคำถาม / คำขอทั่วไปสำหรับคำแนะนำเกี่ยวกับการบำรุงรักษาระบบการผลิตตามขั้นตอนผ่านการอัพเดทหลังการเผยแพร่หลายครั้งโดยไม่ทำลายเนื้อหาที่สร้างขึ้นก่อนหน้านี้

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

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

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

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

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

ฉันกำลังทำงานใน Unity3D / C # ถึงแม้ว่านี่จะเป็นคำถามที่ไม่เชื่อเรื่องภาษา

UPDATE:

ขอบคุณสำหรับคำตอบ

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

ฉันพบแนวคิดของ Stormwind เกี่ยวกับ "กรง" เพื่อเป็นวิธีที่มีประโยชน์อย่างยิ่งในการคิดเกี่ยวกับสิ่งต่าง ๆ กรงนั้นเป็นจุด reseed ซึ่งป้องกันผลกระทบจากการเปลี่ยนแปลงเล็กน้อยเช่นการยกกรงผีเสื้อ

ฉันคิดว่าคุณครอบคลุมฐานที่นี่:

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

• การติดตามเวอร์ชันตัวสร้างที่ใช้ในไฟล์บันทึกและตอบสนองอย่างเหมาะสม "เหมาะสม" หมายถึงอะไรอาจเป็น ...

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

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

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

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

หมายเลข: ลำดับงวด / สล็อตสมมติว่าคุณมีตัวสร้างหมายเลขหนึ่งที่ให้บริการสำหรับทุกสิ่ง ไม่ได้กำหนดความหมายมันแยกตัวเลขออกมาตามลำดับเช่น PRNG ใด ๆ เมื่อให้เมล็ดเดียวกันกับการวิ่งสองครั้งเราจะได้ลำดับเหมือนกันใช่ไหม ตอนนี้คุณให้ความคิดบางอย่างและตัดสินใจว่าจะมี 30 ด้านของเกมของคุณที่จะต้องให้ค่าสุ่ม ที่นี่เรากำหนดลำดับการวนรอบ 30 สล็อตเช่นทุก ๆ หมายเลขแรกในลำดับคือเลย์เอาต์ภูมิประเทศที่ขรุขระทุกหมายเลขที่สองคือการรบกวนภูมิประเทศ ... ฯลฯ ... ทุก ๆ 10 หมายเลขเพิ่มข้อผิดพลาดบางอย่างให้กับสถานะ AI เพื่อความสมจริง ดังนั้นช่วงเวลาของคุณคือ 30

หลังจาก 10 คุณมีช่องฟรี 20 ช่องที่คุณสามารถใช้สำหรับด้านอื่น ๆ ขณะที่การออกแบบเกมดำเนินต่อไป ค่าใช้จ่ายที่นี่แน่นอนว่าคุณต้องสร้างตัวเลขสำหรับช่อง 11-30 ถึงแม้ว่าพวกเขาจะไม่ได้ใช้งานอยู่ในขณะนี้เช่นเสร็จสิ้นระยะเวลาเพื่อกลับสู่ลำดับถัดไปที่ 1-10 ที่มีค่าใช้จ่าย CPU ถึงแม้ว่ามันควรจะน้อย (ขึ้นอยู่กับจำนวนของช่องว่าง) ข้อเสียอีกอย่างคือคุณต้องแน่ใจว่าการออกแบบขั้นสุดท้ายของคุณสามารถรองรับจำนวนช่องที่คุณเปิดให้ใช้ตั้งแต่เริ่มต้นกระบวนการพัฒนาของคุณ ... และยิ่งคุณกำหนดมากขึ้นเมื่อเริ่มต้นช่องยิ่งว่างเปล่า คุณอาจต้องผ่านแต่ละสิ่งเพื่อให้งานสำเร็จ

ผลกระทบของสิ่งนี้คือ:

• คุณมีเครื่องกำเนิดไฟฟ้าผลิตตัวเลขสำหรับทุกสิ่ง
• การเปลี่ยนจำนวนด้านที่คุณต้องสร้างตัวเลขสำหรับจะไม่ส่งผลต่อการกำหนด (หากระยะเวลาของคุณมีขนาดใหญ่พอที่จะรองรับทุกด้าน)

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

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

แน่นอนวิธีการที่นิยมที่สุดคือการแปลงข้อมูลที่สร้างเป็นข้อมูลแบบคงที่ตามที่คุณได้กล่าวถึง

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

ฉันรักษาพื้นที่ ca 30000 ตารางกิโลเมตรถือ ca 1 ล้านอาคารและวัตถุอื่น ๆ นอกเหนือจากการสุ่มตำแหน่งของสิ่งต่าง ๆ การจำลองกลางแจ้งของค ข้อมูลที่เก็บไว้คือ ca 4 GB ฉันโชคดีที่มีพื้นที่เก็บข้อมูล แต่ก็ไม่ จำกัด

Random เป็นแบบสุ่มไม่มีการควบคุม แต่เราสามารถขังมันได้เล็กน้อย:

• ควบคุมมันเริ่มต้นที่สิ้นสุด (ตามที่กล่าวไว้ในโพสต์อื่น ๆ จำนวนเมล็ดและจำนวนที่สร้างขึ้นจำนวน)
• จำกัด พื้นที่ที่เป็นตัวเลขเช่น สร้างจำนวนเต็มตั้งแต่ 0 ถึง 100 เท่านั้น
• Offset พื้นที่เป็นตัวเลขโดยเพิ่มค่า (เช่น 100 + [ตัวเลขที่สร้างระหว่าง 0 และ 100] สร้างตัวเลขสุ่มระหว่าง 100 และ 200)
• ปรับขนาด (เช่นคูณด้วย 0.1)
• และใช้กรงต่าง ๆ รอบตัวมัน นี่คือการลดทอนส่วนที่เหลือของรุ่น เช่น. ถ้าสร้างในพื้นที่สองมิติหนึ่งสามารถวางรูปสี่เหลี่ยมผืนผ้าด้านบนของคู่หมายเลขและเศษสิ่งที่อยู่ข้างนอก หรือวงกลมหรือรูปหลายเหลี่ยม หากในพื้นที่สามมิติเราสามารถยอมรับได้เพียงสามเท่าที่อยู่ในทรงกลมหรือรูปร่างอื่น ๆ (ตอนนี้กำลังคิดด้วยสายตา แต่สิ่งนี้ไม่จำเป็นต้องเกี่ยวข้องกับการสร้างภาพหรือการวางตำแหน่งจริง)

เกี่ยวกับมัน. กรงยังใช้ข้อมูลโชคไม่ดี

มีการพูดภาษาฟินแลนด์ Hajota ja hallitse แปลเป็นแบ่งและพิชิต

ฉันละทิ้งแนวคิดในการให้รายละเอียดที่เล็กที่สุดอย่างแม่นยำ Random ต้องการอิสระดังนั้นมันจึงมีอิสระ ปล่อยให้ผีเสื้อบินไป - อยู่ในกรงของมัน แต่ฉันมุ่งเน้นไปที่การมีวิธีมากมายในการกำหนด (และครอบครอง !!) กรง มันไม่สำคัญว่าพวกเขาจะเป็นรถยนต์อะไรตราบใดที่พวกเขาเป็นสีน้ำเงินหรือน้ำเงินเข้ม (นายจ้างที่น่าเบื่อพูดหนึ่งครั้ง :-)) "Blue or darkblue" เป็นกรง (เล็กมาก) ที่นี่พร้อมมิติสี

การจัดการและการจัดการช่องว่างเชิงตัวเลขคืออะไร

• ตารางบูลีนคือ (บิตมีขนาดเล็ก!)
• แต้มมุมคือ
• ในฐานะที่เป็นโครงสร้างต้นไม้ (= เพื่อตาม "กรงถือกรง")

การบำรุงรักษาที่ชาญฉลาดและรุ่น intercompatbility-wise ... เรามี
: ถ้า version = n ดังนั้น
: elseif รุ่น = m ดังนั้น ...
Yep ฐานรหัสจะขยายใหญ่ขึ้น :-)

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

ไม่เข้ากันโดยสิ้นเชิงกับ "nuke it fom orbit" ตลกที่เสนอโดย DMGregory แต่อาจใช้ nukes ขนาดเล็กและแม่นยำใช่ไหม :-)