อนาคตของการเล่นเกมออนไลน์: 'คำมั่นสัญญาของเครื่องยนต์ MUD ECS'

กลางMar 18, 2024
บทความนี้จะให้คำอธิบายทางเทคนิคและวิธีแก้ปัญหาสำหรับปัญหาอุตสาหกรรมของเกมลูกโซ่ที่ใช้กลไก ECS
อนาคตของการเล่นเกมออนไลน์: 'คำมั่นสัญญาของเครื่องยนต์ MUD ECS'

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

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

บทเรียนจากอุตสาหกรรมเกมแบบดั้งเดิม

อาจกล่าวได้มากมายเกี่ยวกับความหลงใหลในการสร้างสรรค์สิ่งใหม่ๆ สร้างทุกสิ่งตั้งแต่ต้นจนจบ และสร้างสิ่งมีชีวิตใหม่ทั้งหมด แต่เกี่ยวกับการเล่นเกม มีบทเรียนหลายสิบปีเกี่ยวกับรูปแบบการออกแบบและการสร้างกลุ่มวิศวกรรมใหม่ๆ ที่ควรให้ความสำคัญอย่างจริงจัง การยกเลิกสิ่งเหล่านี้เทียบเท่ากับการพยายามสร้างเกม AAA ด้วยเทคโนโลยี Atari

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

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

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

มีปัญหาหลักบางประการที่เกี่ยวข้องกับเกมออนไลน์:

  1. ขาดกรอบการทำงาน: ทุกทีมพยายามสร้างทุกอย่างตั้งแต่เริ่มต้น ส่งผลให้มีประสิทธิภาพต่ำและขาดความรู้เชิงระบบตามประสบการณ์ที่รวบรวมไว้ของผู้สร้างในการแก้ไขปัญหาเดียวกันและปรับให้เหมาะสมเพื่อทางออกที่ดีที่สุด
  2. ขาดการนำโค้ดกลับมาใช้ใหม่ได้: นำเกมออนไลน์หลายเกมที่ได้รับการพัฒนาในปัจจุบัน สามารถคัดลอกได้สำเร็จกี่เกมเพื่อสร้างเกมที่แตกต่างกันเล็กน้อย มีกี่คนที่มีความแตกต่างที่ชัดเจนระหว่างเลเยอร์และส่วนประกอบต่างๆ ของเกมที่อนุญาตให้สร้างเจเนอเรชันใหม่ด้วยฐานโค้ดที่คล้ายกัน คำมั่นสัญญาในการสร้างโปรเจ็กต์โอเพ่นซอร์สที่สำคัญที่สุดและเชื่อมโยงถึงกันสำหรับเกมดูเหมือนจะอยู่ห่างไกล
  3. ขาดความสามารถในการประกอบข้อมูล: มันไม่ได้จบลงด้วยการนำโค้ดกลับมาใช้ซ้ำได้ นอกจากนี้ยังเกี่ยวกับความสามารถของเกมออนไลน์ในการใช้ประโยชน์จากสถานะบล็อกเชนที่ใช้ร่วมกันเพื่อสร้างทับซ้อนกันโดยใช้ข้อมูลของเกม A ในเกม B ในทางปฏิบัติ ต้องใช้การทำงานและทรัพยากรจำนวนมากเพื่อรวมข้อมูลและตรรกะของ เกมหนึ่งไปสู่อีกเกมหนึ่ง

วิธีแก้ปัญหาของโคลน:

Mud เป็นความพยายามครั้งแรกที่กล้าหาญในการสร้างเอนจิ้นและเฟรมเวิร์กสำหรับเกมออนไลน์โดยจัดเตรียมโครงสร้างสำหรับการบำรุงรักษา ความสามารถในการอัปเกรด และความสามารถในการขึ้นรูป รูปแบบ Entity Component System (ECS) ที่สนับสนุนโดยโคลนนั้นสมเหตุสมผลไม่เพียงในแง่ของการพัฒนาเกมทั่วไปเท่านั้น แต่ยังมีความหมายมากกว่านั้นสำหรับการพัฒนาเกมแบบออนไลน์อีกด้วย

ECS ในสัญญาอัจฉริยะ:

โครงสร้างพื้นฐานที่สุดใน MUD คือส่วนประกอบ เป็นสัญญาที่ใช้งานซึ่งทำหน้าที่เหมือนฐานข้อมูลที่เก็บข้อมูลเกี่ยวกับเอนทิตี ตัวอย่างเช่น ลองใช้เอนทิตี (ที่อยู่) เช่น กระเป๋าเงินของผู้เล่น เอนทิตีนี้ที่แสดงโดยที่อยู่สามารถมีคุณสมบัติที่แตกต่างกัน เช่น ค่าตำแหน่ง(x,y) ในองค์ประกอบตำแหน่ง ระดับ 10 ในองค์ประกอบระดับ และ 50 ในองค์ประกอบเหรียญ ส่วนประกอบประกอบด้วยการแมปและการกำหนดค่าพื้นฐานเท่านั้น ระบบมีความซับซ้อนมากขึ้นและใช้ตรรกะในการเปลี่ยนแปลงค่าในส่วนประกอบต่างๆ คุณสามารถคิดเกี่ยวกับเรื่องนี้ได้เนื่องจากระบบจะระบุเฉพาะ API สำหรับคำขอ POST บนฐานข้อมูล (ส่วนประกอบ) พวกเขาสามารถทำได้ก็ต่อเมื่อได้รับสิทธิ์ในการเขียนส่วนประกอบเฉพาะเท่านั้น ที่นี่มันเริ่มน่าสนใจ ระบบสามารถโต้ตอบกับส่วนประกอบต่างๆ เพื่อสร้างตรรกะที่มีรายละเอียด คุณสามารถมีระบบการเคลื่อนไหวที่ระบุการเคลื่อนไหวที่ถูกต้องที่ผู้เล่นสามารถทำได้ (เช่น สองก้าวในแต่ละครั้ง) และคุณสามารถมีระบบรางวัลที่ให้เหรียญแก่ผู้เล่นทุกครั้งที่พวกเขาเลเวลอัพ ทั้งหมดได้รับการลงทะเบียนที่ "World contact" ดังนั้นทุกการเปลี่ยนแปลงในข้อมูลส่วนประกอบจะตามมาด้วยเหตุการณ์ที่ปล่อยออกมา สัญญาโลกไม่ได้รับอนุญาต ใครๆ ก็สามารถเพิ่มระบบและส่วนประกอบใหม่ๆ ได้ ตามทฤษฎีแล้ว โลกที่แตกต่างกันสามารถโต้ตอบซึ่งกันและกันได้

การนำ ECS มาสู่เกมออนไลน์ส่งผลให้มีโครงสร้างที่หรูหรามาก โดยที่ OPcraft ประกอบด้วยส่วนประกอบเพียง 10 ชิ้นและประมาณ 15 ระบบ คุณสามารถตรวจสอบโพสต์บล็อกที่ยอดเยี่ยมนี้ได้ที่ MUD.dev

ความสามารถในการประกอบอย่างแท้จริง

ระบบ ECS ไม่เพียงแต่สมเหตุสมผลในการพัฒนาเกมแบบดั้งเดิมเท่านั้น แต่ยังมีความหมายมากกว่านั้นในเกมออนไลน์ด้วยการมอบคุณสมบัติที่สำคัญสองประการ

  1. ความสามารถในการอัปเกรดของเกมที่ปรับใช้
  2. ระดับสูงสุดของความสามารถในการประกอบ

ลองจินตนาการถึงสองเส้นทาง หนึ่งคือการรักษาการออกแบบฐานไว้ และอีกอย่างคือการเปลี่ยนแปลงตรรกะของเกมหลัก

ลองนึกถึงเกมกลยุทธ์ PVP มาตรฐานที่ผู้เล่นสามารถสร้างกองทัพเพื่อต่อสู้กันเองได้ เวอร์ชันพื้นฐานเป็นแบบ 2 มิติ แต่ตอนนี้ทีมงานตัดสินใจว่าพวกเขาต้องการสร้างการเรนเดอร์ 3 มิติโดยละเอียดของเกม สิ่งที่พวกเขาต้องทำคือนำระบบที่เกี่ยวข้องกับตำแหน่งทั้งหมดและสร้างเวอร์ชันที่อัปเกรดด้วยพิกัด (x,y,z) แทน (x,y) ระบบและส่วนประกอบอื่นๆ ทั้งหมด (เช่น ระบบโจมตี, HP และการสร้างกองทัพ) สามารถคงเหมือนเดิมได้ มันยังไปไกลกว่าทีมพัฒนาเริ่มแรกด้วยซ้ำ ชุมชนสามารถสร้างม็อดต่างๆ ของเกมได้โดยการปรับใช้ระบบและส่วนประกอบใหม่ หรือแม้แต่โต้ตอบกับส่วนประกอบเดียวกันโดยให้สิทธิ์การเขียนแก่ระบบใหม่ (หากเป็นเกมที่ชุมชนเป็นเจ้าของ โมเดลการกำกับดูแลที่หลากหลายสามารถ ใช้สำหรับการตัดสินใจประเภทนี้)

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

มุมมองด้านลูกค้าโดยรวม:

ประกาศ MUD เป็นโครงการที่กำลังดำเนินการ ส่วนต่อไปอาจไม่ทันสมัยและมีความไม่ถูกต้องและความแตกต่างคร่าวๆ อยู่บ้าง แต่คาดว่าสถาปัตยกรรมทั่วไปจะมีการเปลี่ยนแปลงอย่างมาก

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

  1. ความสามารถในการประกอบของลูกค้า
  2. ไคลเอนต์ซิงค์อย่างสมบูรณ์กับการเปลี่ยนแปลงสถานะบล็อคเชน (ข้อมูลเกม)
  3. PhaserX เป็นเลเยอร์การเรนเดอร์

มาเจาะลึกรายละเอียดทางเทคนิคเพื่อให้เป็นรูปธรรมมากขึ้น

เลเยอร์เครือข่าย:

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

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

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

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

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

เลเยอร์การเรนเดอร์ - เหตุการณ์จะเรนเดอร์เมื่อใดและอย่างไร

MUD มาพร้อมกับ PhaserX "การสร้างเครื่องยนต์ที่สามารถปรับขนาดได้สูงที่ด้านบนของ Phaser" PhaserX ไม่จำเป็น ใน OPcraft มีเอ็นจิ้น Noa voxel แทน PhaserX ตามทฤษฎี คุณสามารถใช้เครื่องยนต์ใดก็ได้ที่คุณต้องการตราบใดที่มันเป็นไปตามโครงสร้าง

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

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

ข้อสงวนสิทธิ์:

  1. บทความนี้พิมพ์ซ้ำจาก [มิเรอร์] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Matchbox DAO] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีม Gate Learn “Gate Learn”) และพวกเขาจะจัดการโดยทันที
  2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
  3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว

อนาคตของการเล่นเกมออนไลน์: 'คำมั่นสัญญาของเครื่องยนต์ MUD ECS'

กลางMar 18, 2024
บทความนี้จะให้คำอธิบายทางเทคนิคและวิธีแก้ปัญหาสำหรับปัญหาอุตสาหกรรมของเกมลูกโซ่ที่ใช้กลไก ECS
อนาคตของการเล่นเกมออนไลน์: 'คำมั่นสัญญาของเครื่องยนต์ MUD ECS'

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

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

บทเรียนจากอุตสาหกรรมเกมแบบดั้งเดิม

อาจกล่าวได้มากมายเกี่ยวกับความหลงใหลในการสร้างสรรค์สิ่งใหม่ๆ สร้างทุกสิ่งตั้งแต่ต้นจนจบ และสร้างสิ่งมีชีวิตใหม่ทั้งหมด แต่เกี่ยวกับการเล่นเกม มีบทเรียนหลายสิบปีเกี่ยวกับรูปแบบการออกแบบและการสร้างกลุ่มวิศวกรรมใหม่ๆ ที่ควรให้ความสำคัญอย่างจริงจัง การยกเลิกสิ่งเหล่านี้เทียบเท่ากับการพยายามสร้างเกม AAA ด้วยเทคโนโลยี Atari

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

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

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

มีปัญหาหลักบางประการที่เกี่ยวข้องกับเกมออนไลน์:

  1. ขาดกรอบการทำงาน: ทุกทีมพยายามสร้างทุกอย่างตั้งแต่เริ่มต้น ส่งผลให้มีประสิทธิภาพต่ำและขาดความรู้เชิงระบบตามประสบการณ์ที่รวบรวมไว้ของผู้สร้างในการแก้ไขปัญหาเดียวกันและปรับให้เหมาะสมเพื่อทางออกที่ดีที่สุด
  2. ขาดการนำโค้ดกลับมาใช้ใหม่ได้: นำเกมออนไลน์หลายเกมที่ได้รับการพัฒนาในปัจจุบัน สามารถคัดลอกได้สำเร็จกี่เกมเพื่อสร้างเกมที่แตกต่างกันเล็กน้อย มีกี่คนที่มีความแตกต่างที่ชัดเจนระหว่างเลเยอร์และส่วนประกอบต่างๆ ของเกมที่อนุญาตให้สร้างเจเนอเรชันใหม่ด้วยฐานโค้ดที่คล้ายกัน คำมั่นสัญญาในการสร้างโปรเจ็กต์โอเพ่นซอร์สที่สำคัญที่สุดและเชื่อมโยงถึงกันสำหรับเกมดูเหมือนจะอยู่ห่างไกล
  3. ขาดความสามารถในการประกอบข้อมูล: มันไม่ได้จบลงด้วยการนำโค้ดกลับมาใช้ซ้ำได้ นอกจากนี้ยังเกี่ยวกับความสามารถของเกมออนไลน์ในการใช้ประโยชน์จากสถานะบล็อกเชนที่ใช้ร่วมกันเพื่อสร้างทับซ้อนกันโดยใช้ข้อมูลของเกม A ในเกม B ในทางปฏิบัติ ต้องใช้การทำงานและทรัพยากรจำนวนมากเพื่อรวมข้อมูลและตรรกะของ เกมหนึ่งไปสู่อีกเกมหนึ่ง

วิธีแก้ปัญหาของโคลน:

Mud เป็นความพยายามครั้งแรกที่กล้าหาญในการสร้างเอนจิ้นและเฟรมเวิร์กสำหรับเกมออนไลน์โดยจัดเตรียมโครงสร้างสำหรับการบำรุงรักษา ความสามารถในการอัปเกรด และความสามารถในการขึ้นรูป รูปแบบ Entity Component System (ECS) ที่สนับสนุนโดยโคลนนั้นสมเหตุสมผลไม่เพียงในแง่ของการพัฒนาเกมทั่วไปเท่านั้น แต่ยังมีความหมายมากกว่านั้นสำหรับการพัฒนาเกมแบบออนไลน์อีกด้วย

ECS ในสัญญาอัจฉริยะ:

โครงสร้างพื้นฐานที่สุดใน MUD คือส่วนประกอบ เป็นสัญญาที่ใช้งานซึ่งทำหน้าที่เหมือนฐานข้อมูลที่เก็บข้อมูลเกี่ยวกับเอนทิตี ตัวอย่างเช่น ลองใช้เอนทิตี (ที่อยู่) เช่น กระเป๋าเงินของผู้เล่น เอนทิตีนี้ที่แสดงโดยที่อยู่สามารถมีคุณสมบัติที่แตกต่างกัน เช่น ค่าตำแหน่ง(x,y) ในองค์ประกอบตำแหน่ง ระดับ 10 ในองค์ประกอบระดับ และ 50 ในองค์ประกอบเหรียญ ส่วนประกอบประกอบด้วยการแมปและการกำหนดค่าพื้นฐานเท่านั้น ระบบมีความซับซ้อนมากขึ้นและใช้ตรรกะในการเปลี่ยนแปลงค่าในส่วนประกอบต่างๆ คุณสามารถคิดเกี่ยวกับเรื่องนี้ได้เนื่องจากระบบจะระบุเฉพาะ API สำหรับคำขอ POST บนฐานข้อมูล (ส่วนประกอบ) พวกเขาสามารถทำได้ก็ต่อเมื่อได้รับสิทธิ์ในการเขียนส่วนประกอบเฉพาะเท่านั้น ที่นี่มันเริ่มน่าสนใจ ระบบสามารถโต้ตอบกับส่วนประกอบต่างๆ เพื่อสร้างตรรกะที่มีรายละเอียด คุณสามารถมีระบบการเคลื่อนไหวที่ระบุการเคลื่อนไหวที่ถูกต้องที่ผู้เล่นสามารถทำได้ (เช่น สองก้าวในแต่ละครั้ง) และคุณสามารถมีระบบรางวัลที่ให้เหรียญแก่ผู้เล่นทุกครั้งที่พวกเขาเลเวลอัพ ทั้งหมดได้รับการลงทะเบียนที่ "World contact" ดังนั้นทุกการเปลี่ยนแปลงในข้อมูลส่วนประกอบจะตามมาด้วยเหตุการณ์ที่ปล่อยออกมา สัญญาโลกไม่ได้รับอนุญาต ใครๆ ก็สามารถเพิ่มระบบและส่วนประกอบใหม่ๆ ได้ ตามทฤษฎีแล้ว โลกที่แตกต่างกันสามารถโต้ตอบซึ่งกันและกันได้

การนำ ECS มาสู่เกมออนไลน์ส่งผลให้มีโครงสร้างที่หรูหรามาก โดยที่ OPcraft ประกอบด้วยส่วนประกอบเพียง 10 ชิ้นและประมาณ 15 ระบบ คุณสามารถตรวจสอบโพสต์บล็อกที่ยอดเยี่ยมนี้ได้ที่ MUD.dev

ความสามารถในการประกอบอย่างแท้จริง

ระบบ ECS ไม่เพียงแต่สมเหตุสมผลในการพัฒนาเกมแบบดั้งเดิมเท่านั้น แต่ยังมีความหมายมากกว่านั้นในเกมออนไลน์ด้วยการมอบคุณสมบัติที่สำคัญสองประการ

  1. ความสามารถในการอัปเกรดของเกมที่ปรับใช้
  2. ระดับสูงสุดของความสามารถในการประกอบ

ลองจินตนาการถึงสองเส้นทาง หนึ่งคือการรักษาการออกแบบฐานไว้ และอีกอย่างคือการเปลี่ยนแปลงตรรกะของเกมหลัก

ลองนึกถึงเกมกลยุทธ์ PVP มาตรฐานที่ผู้เล่นสามารถสร้างกองทัพเพื่อต่อสู้กันเองได้ เวอร์ชันพื้นฐานเป็นแบบ 2 มิติ แต่ตอนนี้ทีมงานตัดสินใจว่าพวกเขาต้องการสร้างการเรนเดอร์ 3 มิติโดยละเอียดของเกม สิ่งที่พวกเขาต้องทำคือนำระบบที่เกี่ยวข้องกับตำแหน่งทั้งหมดและสร้างเวอร์ชันที่อัปเกรดด้วยพิกัด (x,y,z) แทน (x,y) ระบบและส่วนประกอบอื่นๆ ทั้งหมด (เช่น ระบบโจมตี, HP และการสร้างกองทัพ) สามารถคงเหมือนเดิมได้ มันยังไปไกลกว่าทีมพัฒนาเริ่มแรกด้วยซ้ำ ชุมชนสามารถสร้างม็อดต่างๆ ของเกมได้โดยการปรับใช้ระบบและส่วนประกอบใหม่ หรือแม้แต่โต้ตอบกับส่วนประกอบเดียวกันโดยให้สิทธิ์การเขียนแก่ระบบใหม่ (หากเป็นเกมที่ชุมชนเป็นเจ้าของ โมเดลการกำกับดูแลที่หลากหลายสามารถ ใช้สำหรับการตัดสินใจประเภทนี้)

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

มุมมองด้านลูกค้าโดยรวม:

ประกาศ MUD เป็นโครงการที่กำลังดำเนินการ ส่วนต่อไปอาจไม่ทันสมัยและมีความไม่ถูกต้องและความแตกต่างคร่าวๆ อยู่บ้าง แต่คาดว่าสถาปัตยกรรมทั่วไปจะมีการเปลี่ยนแปลงอย่างมาก

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

  1. ความสามารถในการประกอบของลูกค้า
  2. ไคลเอนต์ซิงค์อย่างสมบูรณ์กับการเปลี่ยนแปลงสถานะบล็อคเชน (ข้อมูลเกม)
  3. PhaserX เป็นเลเยอร์การเรนเดอร์

มาเจาะลึกรายละเอียดทางเทคนิคเพื่อให้เป็นรูปธรรมมากขึ้น

เลเยอร์เครือข่าย:

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

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

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

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

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

เลเยอร์การเรนเดอร์ - เหตุการณ์จะเรนเดอร์เมื่อใดและอย่างไร

MUD มาพร้อมกับ PhaserX "การสร้างเครื่องยนต์ที่สามารถปรับขนาดได้สูงที่ด้านบนของ Phaser" PhaserX ไม่จำเป็น ใน OPcraft มีเอ็นจิ้น Noa voxel แทน PhaserX ตามทฤษฎี คุณสามารถใช้เครื่องยนต์ใดก็ได้ที่คุณต้องการตราบใดที่มันเป็นไปตามโครงสร้าง

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

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

ข้อสงวนสิทธิ์:

  1. บทความนี้พิมพ์ซ้ำจาก [มิเรอร์] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Matchbox DAO] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีม Gate Learn “Gate Learn”) และพวกเขาจะจัดการโดยทันที
  2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
  3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว
เริ่มตอนนี้
สมัครและรับรางวัล
$100