TL; DR

• การออกแบบของเครื่อง MUD นำไปสู่ "ฐานข้อมูล"
• ช่วงเวลา AMM สำหรับเกมเต็มลูกโซ่ยังไม่ถึง
• Crypto-native เป็นค่า

ก่อนที่จะเริ่ม

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

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

นี่อาจเป็นความพยายามที่ง่ายที่สุดในการพัฒนาเกมแบบ Fully On-chain ก่อนหน้านี้เราพยายามใช้ Chrome Offline Dinosaur Game (Chrome Dino Game) เวอร์ชันเต็มเชน แต่ต่อมาพบว่ามันไม่ได้มีต้นกําเนิดมาจากบล็อกเชน ด้วยการสนับสนุนของกลไก Tick ของเกมจึงเป็นเรื่องยากที่จะทําซ้ําเวอร์ชันเต็มเชนที่ใกล้เคียงกับประสบการณ์เกมดั้งเดิม

เวอร์ชันออนไลน์ของเกม Chrome Dino ที่: https://dinorunner.com/

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

โดยส่วนใหญ่เป็น RTS (เกมกลยุทธ์แบบเรียลไทม์) เช่น: Loot Survivor, Primodium, Sky Strife, Cellula, ฯลฯ รวมถึง Meta Rules (เกมกฎระเบียบทางเมต้า/เกมล่องเบน) เช่น: PixeLAW, Briq, OpCraft, ฯลฯ ทั้งสองประเภทของเกมหลีกเลี่ยงข้อเสียที่เกิดจากเวลายืนยันที่ยาวนานของธุรกรรมบล็อกเชนในเชิงรูปแบบของเกม

รูปภาพแสดงอินเทอร์เฟซเริ่มต้นของ Sky Strife, URL:https://playtest.skystrife.xyz/

ทำไมถึงเลือก MUD engine?

MUD เป็นเครื่องมือสำหรับพัฒนาเกมแบบเต็มระบบแรกในนิเวศ EVM (และเป็นกรอบการพัฒนาแอปพลิเคชันแรกในนิเวศ EVM) กระเป๋าเงิน Session ที่ซึ่งมีอยู่ในเครื่องมือ และทางกายภาพเสมือนที่สามารถเรียกใช้ผ่าน API สามารถลดอุปสรรคในการเข้าสู่ระบบสำหรับผู้เล่นได้

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

บทนำสู่ MUDs แหล่งที่มา:https://github.com/latticexyz/mud

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

วิศวกรรม

MUD engine คืออะไรในทั่วไป?

MUD engine = on-chain relational database + on-chain application development framework.

คุณสมบัติ MUD แห่งมูลด์: source:https://github.com/latticexyz/mud

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

ไม่ว่าเป็น “ฐานข้อมูลความสัมพันธ์บนโซน” หรือ “กรอบการพัฒนาแอปพลิเคชันบนโซน” ทั้งสองนี้มีความสำคัญต่อการพัฒนา Ethereum, “คอมพิวเตอร์โลก”

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

ดังนั้นเรามาดูว่าการออกแบบของเครื่องยนต์ MUD ก็ตามไอเดีย "database-based" อีกดี จากมุมมองการออกแบบของเครื่องยนต์ MUD มันแก้ปัญหาหลักสามประการ

1. วิธีทำให้ข้อมูลบนเชนง่ายต่อการอ่าน เขียน และเก็บรักษาอย่างประหยัด

2. การซิงโครไนซ์ข้อมูลอัตโนมัติระหว่าง on-chain/clients,

3. การบริหารจัดการความ复杂ของการพัฒนาแอปพลิเคชันทั่วไป

Let’s look at the first question first: “How data on the chain can be easily read, written and stored economically”。

ปัญหานี้สามารถแยกออกเป็นสององค์ประกอบ:

1> ง่ายต่อการอ่านและเขียน

2> การจัดเก็บเศรษฐกิจ

หลังจากทศวรรษที่ผ่านมาในวงการอินเทอร์เน็ต "ความสะดวกในการอ่านและเขียน", "ฐานข้อมูลที่เกี่ยวข้อง" ถือว่าเป็น sol ลัลธิมัม. อย่างไรก็ตาม, บล็อกเชนเป็นแบบจัดเก็บโซ่ที่แตกต่างมากจากแบบจัดเก็บข้อมูลฐานข้อมูลเดิม (ดูรูปด้านล่าง) แบบจัดเก็บข้อมูลนี้ไม่ใช่เพื่อนบอกจึงอย่างง่ายแม้กระทั่งสำหรับกระบวนการที่เรียบง่ายในสถานการณ์เดียว (เช่น การรวม / การเฉลี่ยจำนวนธุรกรรมของคอลเลกชัน NFT บางอย่าง) / การค้นหาค่าสูงสุดและต่ำสุด, ฯลฯ.), ยกเว้นจากสถานการณ์ที่ซับซ้อนมากขึ้น

Image Source:https://mempool.space/mining

ดังนั้นทางออกสําหรับ MUD คือการใช้ "ฐานข้อมูลเชิงสัมพันธ์" ที่ด้านบนของที่เก็บข้อมูลแบบลูกโซ่ (สอดคล้องกับตารางภายใต้ Store ในเอ็นจิ้น MUD) สําหรับนักพัฒนาประสบการณ์การใช้งานจะเหมือนกับการใช้งานฐานข้อมูลเชิงสัมพันธ์ทั่วไป (เช่น MySQL, SQL Server, PostgreSQL, SQLite เป็นต้น) สิ่งนี้เป็นมิตรกับนักพัฒนาอินเทอร์เน็ตส่วนใหญ่มากกว่า รูปด้านล่างแสดงโครงสร้างตารางที่สอดคล้องกันเมื่อเราพัฒนาเวอร์ชันเต็มเชน 2048 โดยใช้เอ็นจิ้น MUD

Source:https://github.com/themetacat/MUD2048/blob/main/packages/contracts/mud.config.ts

เราสามารถวิเคราะห์จุด “การเก็บรักษาทางเศรษฐกิจ” จากมุมมองของ Ethereum คอมพิวเตอร์โลก

คอมพิวเตอร์สมัยใหม่ทั้งหมดสอดคล้องกับ "โครงสร้าง Von Neumann" ซึ่งแบ่งออกเป็นห้าส่วน: อินพุตเอาต์พุตการทํางานการควบคุมและการจัดเก็บ (ดูรูปด้านล่าง)

รูปภาพมาจากอินเทอร์เน็ต

จากมุมมองของเอ็นจิ้นเกมแบบ full-chain นั้นสามารถเพิ่มประสิทธิภาพ "การจัดเก็บ" ได้เท่านั้นเนื่องจาก "อินพุต" และ "เอาต์พุต" อยู่ที่ชั้นบนสุดและไม่สามารถควบคุมได้ "การดําเนินการ" และ "การควบคุม" คือ Ethereum blockchain สิ่งที่คุณกําลังทําอยู่ ในฐานะที่เป็น "ซอฟต์แวร์แอปพลิเคชันพื้นฐาน" ที่ทํางานบน "คอมพิวเตอร์โลก" นี้เอ็นจิ้นเกมแบบ full-chain สามารถเพิ่มประสิทธิภาพอินพุต "ที่เก็บข้อมูล" ผ่านมันเท่านั้น

วิธีการแก้ปัญหาที่เฉพาะเจาะจงสำหรับการปรับปรุงการจัดเก็บคือการนำ "bitpacking" มาใช้งานอย่างมีประสิทธิภาพและกระชับสำหรับข้อมูลนำเข้า โดยเรียกเก็บข้อมูลบนบล็อกเชนตามปริมาตรของข้อมูล ปริมาตรข้อมูลเล็กน้อยหมายถึงต้นทุนการจัดเก็บต่ำกว่า ต้นทุนการจัดเก็บที่ถูกปรับแต่งอย่างสมบูรณ์คือเงื่อนไขพื้นฐานสำหรับการเกิดขึ้นของแอปพลิเคชันอน์เชนขนาดใหญ่และซับซ้อน ภาพด้านล่างแสดงกรณีเฉพาะของการปรับปรุงการจัดเก็บโดย MUD สำหรับรายละเอียด ดูที่เครื่องเกม Full-chain MUD จาก 0 ถึง V2。

ที่มาของภาพ:https://lattice.xyz/blog/mud-zero-to-v2

สรุปได้ว่าสำหรับคำถามหนึ่ง MUD แก้ปัญหาโดยส่วนใหญ่จากมุมมองของ "database-based"

ตอนนี้เรามาสู่คำถามที่สอง: “การซิงโครไนซ์ข้อมูลอัตโนมัติระหว่าง on-chain/clients”

นอกจากนี้ยังเป็นฟังก์ชั่นหลักที่มีให้โดยเอ็นจิ้น MUD ซึ่งช่วยให้นักพัฒนาช่วยตัวเองในการทํางานหนักในการจัดการการซิงโครไนซ์สถานะที่ซับซ้อน แผนการดําเนินงานเฉพาะคือ: การซิงโครไนซ์แบบเรียลไทม์ของฐานข้อมูลแบบ on-chain บนไคลเอนต์ กล่าวอีกนัยหนึ่งแต่ละไคลเอนต์มีสําเนาภายในเครื่องในตัวที่ซิงโครไนซ์กับฐานข้อมูลแบบ on-chain แบบเรียลไทม์

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

Image Source:https://mud.dev/services/indexer

สำหรับนักพัฒนา พวกเขามีฐานข้อมูล on-chain ตั้งแต่แรก ๆ ด้วยประสบการณ์ของผู้ใช้ที่ใกล้เคียงกับฐานข้อมูล local อย่างไรก็ตามเมื่อพูดถึงการนำ MUD มาใช้ พบว่ามันยากสำหรับลูกค้าที่จะนำฟังก์ชันเช่นการสร้างรายการทั่วโลก อีกทั้งมันไม่ใช่วิธีที่สมเหตุสมผลสำหรับแต่ละลูกค้าในการสร้างรายการทั่วโลก

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

ดังนั้น ใน mud2048.fun เราสร้างโหนดดัชนี MUD บนเซิร์ฟเวอร์ที่ central เพื่อสร้างอันดับผู้เล่นระดับโลกในลักษณะที่มีค่าใช้จ่ายต่อผู้เล่น (ดูรูปด้านล่าง)

URL:https://www.mud2048.fun/

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

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

ตอนนี้เรามาสู่คำถามที่สาม: "การจัดการความซับซ้อนที่เป็นส่วนร่วมสำหรับการพัฒนาแอปพลิเคชัน"

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

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

Image Source:https://mud.dev/world/introduction

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

Image Source:https://lattice.xyz/blog/mud-zero-to-v2

ข้างต้นคือบางส่วนของความคิดทางวิศวกรรมและประสบการณ์ของเราในขั้นตอนการพัฒนา mud2048.fun โดยใช้เครื่องยนต์ MUD โดยทั่วไปการเครื่องยนต์ MUD ยังสามารถเรียกตาม​​หลักการ "ฐานข้อมูลเป็นพื้นฐาน" ซึ่งสอดคล้องกับวิธีการของการพัฒนาแอปพลิเคชันบนอินเทอร์เน็ตอย่างมาก ดังนั้น เครื่องยนต์ MUD ก็จะไม่รู้สึกแปลกแยกต่อนักพัฒนาแอปพลิเคชันบนอินเทอร์เน็ต ต่อไปเราจะพูดถึงความคิดของเราเกี่ยวกับอุตสาหกรรมเกมส์เชื่อมโยงทั้งหมด

อุตสาหกรรม

เมื่อเราเข้าสู่วงการเกมเต็มโซ่ สามคำถามที่เราตลอดเวลาถามตัวเองคือ:

1. ทำไมต้องการเกมเต็มสาย?

2. เกมประเภทใดที่เหมาะสำหรับเครือข่ายทั้งหมด?

3. ความสัมพันธ์ระหว่าง Fully on-Chain และ Crypto native คืออะไร?

ถัดไปเราจะพูดถึงหนึ่งคนโดยหนึ่ง

สำหรับคำถามแรก: ทำไมเราต้องการเกมเต็มระบบ？

ปัญหานี้สามารถถูกแยกออกเป็นปัญหาย่อยสองปัญหา

1> ทำไมวงการบล็อกเชนต้องการเกมเต็มระบบ?

2> ทำไมตลาดสกุลเงินดิจิทัลต้องการเกมเต็มรูปแบบ?

จากมุมมองของอุตสาหกรรมบล็อกเชน:

ระบบนิเวศของ Ethereum ได้พัฒนาไปสู่ขั้นตอนที่ต้องการการเกิดขึ้นของแอปพลิเคชันแบบ on-chain ที่ซับซ้อน (ในอดีตแอปพลิเคชันแบบ on-chain DeFi/DAO/NFT นั้นค่อนข้างง่ายดังที่เห็นได้จากจํานวนสัญญาที่รองรับแอปพลิเคชัน) อีกตัวอย่างย้อนกลับคือการสนับสนุนคู่ Ethereum Layer 2 สําหรับห่วงโซ่เกมทั้งหมด จากมุมมองตรรกะภายในหากไม่มีงานพอร์ซเลนเพชรจะไม่สามารถทําเพชรได้ เลเยอร์ 2 ต้องการงานพอร์ซเลนทั้งหมดในห่วงโซ่ของเกมทั้งหมดเพื่อให้บรรลุตัวเอง

สาขา NFT ยังไม่มีแนวคิดใหม่ในการส่งเสริมการพัฒนาหลังจากฟองฟอง PFP จุดที่แตกต่าง NFT จาก ERC-20 คือ composability และฉากเกมเป็นสถานที่ธรรมชาติสำหรับ NFT composability

จุดมุ่งหมายสุดท้ายของเกมเครือข่ายทั้งหมดโลกอัตโนมัส" เป็นอีกรายละเอียดหนึ่งของรูปแบบที่ดีที่สุดของโลกดิจิทัล (รายละเอียดสุดท้ายคือ "Metaverse" ที่กลายเป็นระเบียบหลังจากวางตลาดมากเกินไป) ในฐานะที่เป็นจินตนาการร่วมกันของมนุษยชาติเพื่ออนาคตที่ดีกว่าโลกอิสระมีความน่าสนใจอย่างมากและโลกทั้งใบเป็นวิธีสําคัญในการบรรลุเป้าหมายนี้เกมลูกโซ่ก็มีความหวังสูงเช่นกัน

เว็บไซต์อย่างเป็นทางการของ Autonomous Worlds:https://aw.network/

มองไปที่ตลาด Crypto:

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

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

เรามาสู่คำถามที่สอง: เกมประเภทใดที่เหมาะสำหรับเครือข่ายทั้งหมด?？

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

ส่วนตัวฉันคิดว่าคลาส Meta Rules มีศักยภาพมากกว่าอย่างสัมพันธ์เพราะมีโอกาสเกิดขึ้นธรรมชาติมากขึ้นที่ระดับกฎและระดับประสิทธิภาพ อย่างไรก็ตาม ยังเป็นเวลาเร็วมากและยากที่จะประเมินความแน่นอนของมัน ภาพด้านล่างคือ อินเตอร์เฟซของเกมเต็มรายการ meta-rules PixeLAW

Image Source:https://twitter.com/0xPixeLAW/status/1704375844674912515

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

ตอนนี้เรามาพูดถึงคำถามที่สาม: ความสัมพันธ์ระหว่าง Fully on-Chain และ Crypto native คืออะไร?

โดยทั่วไปแล้วการเน้นมากเกินไปที่ว่า “บนโซ่ทั้งหมด” จะทำให้คนตกอยู่ในวงจรอันตรายของการเชื่อศาสนาอย่างยิ่ง โครงสร้างพื้นฐานปัจจุบันของบล็อกเชนไม่สามารถรองรับเกมหลากหลายให้กับทุกข้อมูล/ตรรกะทั้งหมดบนโซ่ได้ อันที่จริง GubSheep ผู้ก่อตั้งของ “ป่ามืด”การสูตรเริ่มต้นคือ "เกม Crypto-Native" เพื่อให้ความคิดถึงว่าเกมสามารถสนับสนุนการพัฒนาอุตสาหกรรมบล็อกเชนให้มากที่สุดจากมุมมองของ Crypto-Native ภาพด้านล่างแสดงส่วนหนึ่งของข้อความต้นฉบับของ GubSheep

source:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis

คริปโตเนทีฟเป็นแนวคิดที่มีความหมายที่เปลี่ยนไปอย่างต่อเนื่องและมีขอบเขตที่ไม่ชัดเจน มีการตีความต่างกันในระยะการพัฒนาบล็อกเชนที่แตกต่างกัน

ในปี 2017 CryptoKitties ถูกพิจารณาว่าเป็นสิ่งที่สำคัญของ crypto-native;

ในปี 2018 ยูนิสแวปเป็นตัวอย่างของคริปโทเนทีฟ

ในปี 2020 CryptoArt เป็นตัวอย่างที่ดีที่สุดของ crypto-native;

ในปี 2021 The DAO เป็นตัวอย่างที่ยิ่งใหญ่ของคริปโตเนทีฟ

โดย 2023 เกมเต็มโซ่ ที่มีข้อมูลและตรรกะอยู่บนโซ่ ถูกมองเห็นว่าเป็นแบบจำลองของคริปโต-เนทีฟ

แต่ในสาระสำคัญการเข้ารหัสเป็นความคิด ไม่ใช่หลักสูตร

Fully on-Chain is a methodology that implements Crypto native, but we cannot be constrained by it., just like centralization/decentralization, revolution/counterrevolution, are all relative concepts, and it is easy to lead to a dead end if you get too entangled with the literal meaning.

ดังนั้น ไม่ว่าจะเป็นเกมเต็มระบบหรือเกมคริปโตเนทีฟ มันจะนำเอาความเป็นไปได้ใหม่ๆมา

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

นอกจากนี้ โครงสร้างเกมเต็มรูปแบบเช่น MUD (ในความจริงแล้ว มันเหมาะกว่าที่จะเรียกมันว่ากรอบการพัฒนาแอปพลิเคชันเต็มรูปแบบ) เป็นส่วนผสมของฐานข้อมูล + กรอบการพัฒนาแอปพลิเคชัน เป็นสิ่งที่มีความสำคัญอย่างชัดเจนในระบบนิวเทรนกิเคิล EVMs อย่างไรก็ตาม ฐานข้อมูล/กรอบการพัฒนาแอปพลิเคชันเป็นสินค้าสาธารณะและไม่มีโมเดลธุรกิจเลย โชคดีที่มีกลไก Token แบบธรรมชาติของบล็อกเชน และEIP-6969โครงการสิทธิ์ราชการของนักพัฒนาแบบนี้สามารถช่วยให้นักพัฒนาของสินค้าเหล่านี้จับค่าได้อย่างมีความเชื่อถือ นี่คือจุดที่บล็อกเชนเป็นเหนือกว่า Web2

“ความเห็นร่วม” ไม่ได้หมายถึงเพียงแค่ 51% ของพลังการคำนวณเท่านั้น แต่ยังเป็นค่าความคิดร่วมที่มีอยู่ในหมู่ชน/กลุ่ม ในทางนี้, การเข้ารหัสเป็นชนิดหนึ่งของค่าความคิด

สารบัญเสริม:

1. เว็บไซต์อย่างเป็นทางการของ MUD 2048:https://www.mud2048.fun/

2. โค้ดโครงการ MUD 2048:https://github.com/themetacat/MUD2048

3. เว็บไซต์อย่างเป็นทางการของ MUD engine: https://mud.dev/

4. เว็บไซต์อย่างเป็นทางการของ Autonomous Worlds Bible:https://aw.network/

5. GubSheep encrypted native game theory:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis

Disclaimer：

1. บทความนี้ถูกนำมาจาก [ MetaCat]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [CK]. If there are objections to this reprint, please contact the Gate Learn ทีมและพวกเขาจะจัดการกับมันทันที
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ ทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถูกห้าม