วิธีจัดการข้อมูลนักออกแบบที่เปลี่ยนแปลงไปพร้อมกับการเปลี่ยนข้อมูลผู้เล่น

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

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

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

ตัวอย่างที่ 1: ผู้เล่นสร้างไอเท็มชนิดใหม่และเกมกำหนด ID 123456 ให้กับมัน อินสแตนซ์ของไอเท็มนั้นอ้างอิงกลับไปที่ 123456 ตอนนี้ลองนึกภาพว่านักออกแบบเกมมีระบบที่คล้ายกันและผู้ออกแบบสร้างรายการใหม่ด้วยหมายเลข 123456 สิ่งนี้สามารถหลีกเลี่ยงได้อย่างไร

ตัวอย่างที่ 2: ใครบางคนสร้าง mod ที่เป็นที่นิยมซึ่งทำให้มังกรของคุณเน้นเสียงภาษาฝรั่งเศส มันมีสคริปต์ที่มีวัตถุใหม่ที่เรียกว่าassignFrenchAccentพวกเขาใช้ในการกำหนดสินทรัพย์เสียงใหม่ให้กับวัตถุมังกรแต่ละ แต่คุณกำลังจะปรับใช้ DLC "Napoleon vs Smaug" ของคุณซึ่งมีชื่อเดียวกัน - คุณจะทำสิ่งนี้ได้อย่างไรโดยไม่มีปัญหาการบริการลูกค้ามากมาย?

ฉันคิดถึงกลยุทธ์ต่อไปนี้:

• คุณสามารถใช้ไฟล์ / ไดเร็กตอรี่ / ฐานข้อมูลแยกกัน 2 ตัว แต่การอ่านของคุณนั้นซับซ้อนอย่างมาก "แสดงรายการทั้งหมด" จะต้องอ่านหนึ่งรายการในฐานข้อมูลผู้ออกแบบและอีกหนึ่งรายการที่อ่านบนฐานข้อมูลผู้เล่น (และยังคงต้องแยกความแตกต่างระหว่าง 2 อย่างใด)
• คุณสามารถใช้เนมสเปซได้ 2 แบบภายในร้านเดียวกันเช่น การใช้สตริงเป็นคีย์หลักและนำหน้าด้วย "DESIGN:" หรือ "PLAYER:" แต่การสร้างเนมสเปซเหล่านั้นอาจไม่ใช่เรื่องเล็กน้อยและการอ้างอิงไม่ชัดเจน (เช่นใน RDBMS คุณอาจไม่สามารถใช้สตริงเป็นคีย์หลักได้อย่างมีประสิทธิภาพคุณสามารถใช้จำนวนเต็มและจัดสรรคีย์หลักทั้งหมดที่อยู่ด้านล่างของจำนวนที่แน่นอนเช่น 1 ล้านเพื่อเป็นข้อมูลผู้ออกแบบและทุกอย่างที่อยู่เหนือจุดนั้น ข้อมูลผู้เล่น แต่ข้อมูลนั้นไม่สามารถมองเห็นได้ใน RDBMS และลิงค์สำคัญต่างประเทศจะข้าม 'หาร' ซึ่งหมายถึงเครื่องมือและสคริปต์ทั้งหมดต้องทำงานอย่างชัดเจน)
• คุณสามารถทำงานบนฐานข้อมูลที่ใช้ร่วมกันแบบเรียลไทม์ได้ แต่ประสิทธิภาพอาจไม่ดีและอาจเพิ่มความเสี่ยงต่อความเสียหายของข้อมูลผู้เล่น นอกจากนี้ยังไม่ขยายไปถึงเกมที่รันบนเซิร์ฟเวอร์มากกว่า 1 เครื่องที่มีข้อมูลโลกแตกต่างกัน
• ... ความคิดอื่น ๆ

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

ฉันยังติดแท็กสิ่งนี้เป็น "การควบคุมเวอร์ชัน" เพราะในระดับหนึ่งนั่นคือสิ่งนี้ - การพัฒนาข้อมูล 2 สาขาที่ต้องรวมเข้าด้วยกัน บางทีข้อมูลเชิงลึกบางอย่างอาจมาจากทิศทางนั้น

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

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

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

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

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

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

• ส่งเสริมให้มีการใช้พื้นที่ - ชื่ออย่างอิสระกับเนื้อหาของรั้วรั้วจากผู้แต่ง / mod / team ที่เฉพาะเจาะจง
• ในกรณีที่เนื้อหาต้องการโต้ตอบให้สร้างระเบียบการโทร / การใช้งานที่ชัดเจนการตั้งชื่อการประชุมและ 'กฎ' หลวม ๆ อื่น ๆ ที่เป็นแนวทางในการพัฒนาเพื่อให้ง่ายต่อการผสานกลับ จัดเตรียมเครื่องมือที่อนุญาตให้ผู้สร้างเนื้อหาทราบว่าพวกเขาปฏิบัติตามกฎเหล่านั้นหรือไม่รวมเข้ากับการสร้างเนื้อหาเอง
• จัดเตรียมเครื่องมือการรายงาน / การวิเคราะห์เพื่อตรวจสอบความล้มเหลวที่อาจเกิดขึ้นก่อนที่จะเกิดความผิดพลาด การแก้ไขโพสต์ผสานน่าจะเจ็บปวดมาก จัดทำขึ้นเพื่อให้สามารถตรวจสอบบิตเนื้อหาบางส่วนและกำหนดให้ชัดเจนว่าเป็นการผสานพร้อมเพื่อให้การผสานไม่เจ็บปวด
• ทำให้การผสาน / การรวมกลุ่มของคุณแข็งแกร่ง อนุญาตให้ย้อนกลับได้ง่าย ทำการทดสอบเนื้อหาที่ผสานอย่างเข้มงวด: หากการทดสอบล้มเหลวอย่ารวมเข้ากับเนื้อหา! วนซ้ำเนื้อหาของคุณหรือของคุณจนกว่าการผสานจะดำเนินต่อไปอย่างหมดจด
• หลีกเลี่ยงการใช้รหัสจำนวนเต็มเพิ่มเติมสำหรับสิ่งใด ๆ (คุณไม่มีวิธีที่เชื่อถือได้ในการสร้างรหัสเหล่านั้นให้กับผู้สร้าง) ใช้งานได้ในฐานข้อมูลเท่านั้นเพราะฐานข้อมูลนั้นเป็นผู้ให้บริการรหัสที่เป็นที่ยอมรับดังนั้นคุณจะไม่ได้รับซ้ำซ้อน อย่างไรก็ตามมันยังแนะนำจุดหนึ่งของความล้มเหลว / โหลดในระบบของคุณ
• ใช้ GUID แทน - มีค่าใช้จ่ายในการจัดเก็บมากขึ้น แต่เป็นเครื่องที่เฉพาะเจาะจงดังนั้นจะไม่ทำให้เกิดการชน อีกทางเลือกหนึ่งคือใช้ตัวระบุสตริงซึ่งจะง่ายต่อการดีบัก / แก้ไข แต่มีราคาแพงกว่าสำหรับการจัดเก็บและการเปรียบเทียบ

เก็บทุกอย่างไว้เป็นแอตทริบิวต์ (หรือมัณฑนากร) - พร้อมจุดยึด ลองนำบ้านที่ผู้เล่นออกแบบมาเป็นตัวอย่าง:

o House: { Type = 105 } // Simple square cottage.
 o Mount point: South Wall:
  o Doodad: Chair { Displacement = 10cm }
   o Mount point: Seat:
    o Doodad: Pot Plant { Displacement = 0cm, Flower = Posies } // Work with me here :)
 o Mount point: North Wall:
  o Doodad: Table { Displacement = 1m }
    o Mount point: Left Edge:
     o Doodad: Food Bowl { Displacement = 20cm, Food = Meatballs}

ดังนั้นแต่ละเอนทิตีสามารถมีจุดเมานต์หนึ่งจุดขึ้นไป - แต่ละจุดเมานต์สามารถยอมรับส่วนประกอบอื่น ๆ ได้มากกว่าศูนย์ ข้อมูลนี้จะถูกเก็บไว้กับรุ่นที่ถูกบันทึกไว้พร้อมกับคุณสมบัติที่เกี่ยวข้อง (เช่นการแทนที่ ฯลฯ ในตัวอย่างของฉัน) - NoSQL มีแนวโน้มที่จะทำให้เป็นแบบที่ดีมากที่นี่ (Key = Entity ID, Value = Serialized Serialized ข้อมูล).

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

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

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

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

คำถามของคุณดูเหมือนจะเป็นคำถามที่ไม่ซ้ำกัน 2 ข้อ:

1. วิธีรับประกันว่า ID วัตถุจะไม่ซ้ำกัน
2. วิธีการประกันว่าเนมสเปซสคริปต์ไม่ชนกัน

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

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

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

assignFrenchAccent

กลายเป็น

_Z11assignFrenchAccent

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

ฉันคิดว่าฐานข้อมูล / ระบบไฟล์ทำซ้ำในสภาพแวดล้อมที่มีขั้นตอน 'เช็คเอาท์' จะดีที่สุด

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

การแก้ไขของ Player จะทำงานในลักษณะเดียวกันยกเว้นบทบาทของฐานข้อมูล / ระบบไฟล์จะถูกย้อนกลับซึ่งจะทำงานในฐานข้อมูลการผลิตและการอัปเดตทั้งหมดจะถูกอัปโหลดไปยัง dev เมื่อเสร็จสิ้น

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

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

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

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

มันเป็นปัญหาที่ซับซ้อนอย่างมากโชคดี! อาจไม่มีคำตอบเดียวอยู่เลย

ฉันไม่คิดว่านี่จะเป็นปัญหาใหญ่ในขณะที่คุณกำลังทำมัน

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

เช่นเดียวกับเนื้อหาที่ผู้ใช้สร้างขึ้นเพียงแค่ทำการสำรองข้อมูลและเขียนทับ

ฉันไม่มีประสบการณ์จริงในเรื่องนี้เพียงแค่ให้คำแนะนำ