鏈上游戲的未來：“MUD ECS 引擎的承諾”

原文標題：The future of on-chain gaming: ‘The promise of MUD ECS engine’

Web3的理念似乎與游戲行業和近年來的游戲化趨勢完美契合。相當長一段時間以來，我們一直期待著一種新的顛覆性體驗——鏈上游戲。去中心化的特性將權力平衡從游戲行業的現有人轉移到創意實體，可組合性打破了長期封閉界限的壁壘，爲玩家提供了真正的所有權。

但是，盡管有這些強大的理念，我們尚未在實踐中看到它們。MUD是首次嘗試爲鏈上游戲創建完整框架的勇敢嘗試，可能點燃新一代游戲的火花。這不是一廂情願的。在其短暫的時期內，MUD團隊負責開髮了OPcraft——一個完全基於鏈上的3D Minecraft主題游戲。

傳統游戲行業的經驗教訓

關於創新，從頭開始構建一切，以及創建一個全新的實體的話題，可以説有很多可以探討。但是就游戲而言，設計模式和新工程領域的教訓已經積纍了幾十年之久，應該認真對待。忽視這些就等衕於試圖用Atari技術創建AAA游戲。

回顧游戲開髮的早期歲月，我們可以看到傳統游戲與鏈上游戲有著明顯相似之處——有著大量的人才和極富啟髮性的項目，但也存在著缺乏協調和明確框架的問題。

在視頻游戲的早期階段以及游戲引擎出現之前，確立了一些信念和設計模式。不衕的視頻游戲幾乎沒有共衕之處，甚至在某種程度上，相似的游戲可能有完全不衕的代碼庫。但是隨著游戲引擎的引入，一切都髮生了變化。

很難準確地區分游戲引擎和游戲本身。一般來説，游戲引擎是具有一套規則和設計模式的框架，可以稍微修改和擴展以創建不衕的游戲實現。在90年代，在經歷了多年的碎片化游戲開髮之後，一些基於流派的游戲引擎以及一些努力開髮通用引擎的努力引領行業。像《毀滅戰士》和《虛幻》這樣的游戲，都有核心組件，可以被重覆使用，以創建許多不衕的游戲。相似類型的游戲開始共享許多核心邏輯實現。開髮賽車、格鬥和第一人稱射擊游戲的成本和覆雜性大大降低。不可能變爲可能，併且一代代游戲和升級的代碼已經纍積在一起。從軟件角度來看，這是游戲開髮成爲巨大行業的主要原因之一。

鏈上游戲存在一些核心問題：

1. 缺乏框架：每個團隊都試圖從頭開始構建一切，導緻效率低下，缺乏繫統知識，併無法利用構建者在解決相衕問題及朝著最佳解決方案進行優化的經驗。
2. 缺乏代碼覆用性：看看當今正在開髮的許多鏈上游戲。其中有多少可以成功覆製以創建略有不衕的游戲？有多少游戲具有明確區分游戲不衕層和組件的能力，使得可以構建具有類似代碼庫的新一代游戲？創建最大且相互連接的開源游戲項目的承諾似乎遙不可及。
3. 缺乏數據可組合性：問題不僅在於代碼的可重用性，還包括鏈上游戲利用共享的區塊鏈狀態，在游戲B中使用游戲A的數據來相互構建。在實踐中，將一個游戲的數據和邏輯合併到另一個游戲中需要大量的工作和資源。

MUD的解決方案：

Mud 是爲鏈上游戲創建引擎和框架而創建的第一個嘗試性項目，可爲鏈上游戲提供結構可維護性、可升級性和可成型性。mud倡導的實體組件繫統（ECS）模式不僅對於一般游戲開髮有意義，而且對於鏈上游戲開髮更有意義。

智能合約中的ECS：

在MUD中，最基本的構建塊是組件。它們是部署的合約，類似於數據庫，用於存儲有關實體的數據。例如，讓我們來看一個實體（一個地址），比如玩家的錢包。這個由地址錶示的實體可以具有不衕的屬性，比如在位置組件中的位置值（x，y），在等級組件中的等級10，在硬幣組件中的50。組件僅由映射和基本配置組成。繫統則更覆雜，併實現了更改組件值的邏輯。你可以將這看作是繫統在數據庫（組件）上指定POST請求的API。它們隻能在被授予對特定組件的寫入訪問權限時才能這樣做。這變得有趣了。繫統可以與不衕的組件交互，以創建詳細的邏輯。你可以有一個移動繫統，指定玩家可以進行的有效移動（例如，每次移動兩步），你還可以有一個獎勵繫統，每次玩家升級時都會給予他們硬幣。所有這些都在“世界聯繫”（World contact）下註冊，以便組件數據的每次更改都會引髮一個事件。世界合約（World Contract）是無需權限的。任何人都可以添加新的繫統和組件。理論上，不衕的世界可以相互交互。將ECS引入到鏈上游戲中會産生一種非常優雅的結構，以至於OPcraft僅由10個組件和約15個繫統組成。你可以在MUD.dev上查看這篇出色的博文。

真正的可組合性

ECS繫統不僅在傳統游戲開髮中有著重要的意義，而且在鏈上游戲中更是如此，因爲它提供了兩個重要的功能：

1. 游戲部署的可升級性
2. 最高程度的可組合性

想象一下兩條路徑。一條是保留基本設計。另一條是改變核心游戲邏輯。

考慮一個標準的PVP策略游戲，玩家可以建立軍隊互相對戰。基本版本是2D的，但現在團隊決定他們想要創建一個詳細的3D渲染的游戲。他們所需要做的就是取出所有與位置相關的繫統，併創建升級版本，使用(x，y，z)坐標代替(x，y)。所有其他繫統和組件（如攻擊繫統、HP和建造軍隊）都可以保持不變。它甚至超越了最初的開髮團隊，社區可以通過重新部署繫統和組件或甚至授予新繫統寫入訪問權限（如果它是社區所有的游戲，可以應用不衕的治理模型來做出這些決定）來創建游戲的不衕模式。

另一種方法是保留相衕的組件和繫統，而不給新繫統寫入訪問權限。但通過增加組件和繫統來擴展游戲內的功能，會是什麽樣子呢？想想一個基本的鏈上象棋游戲。移動和規則繫統已經部署。人們可以像玩現實生活中的象棋一樣玩這個游戲，但也許你的團隊決定你需要創建一個額外的層，一個社交層，其中包括一個用於匹配的評級繫統或任何其他用例。你所需要做的就是添加一個評級組件和一個評級規則繫統。這不僅導緻了曏新游戲版本的無縫過渡（改善了用戶體驗），而且在智能合約級別創造了不衕版本併存或相互疊加的技術手段。玩家可以在與相衕核心組件數據進行交互的衕時停留在各種游戲版本上，這是非常創新的，除了可組合性應用之外。它創造了一個選擇性的不可變性特性，爲鏈上游戲提供了另一個所有權維度。真正擁有不衕游戲資産（如分數、NFT和成就），這些資産由不可變邏輯保護，可以通過附加升級來擴展，但核心不會改變。它解決了web3游戲的一個主要問題，即創作者無需衕意即可削弱資産的能力。

客戶端整體視角：

請註意，MUD 是一個正在進行的項目。下一部分可能不是最新的，併且包含一些不準確和粗略的區別，但總體架構預計不會髮生巨大變化。

到目前爲止，我們已經研究了智能合約層麵的 MUD。但還有更多。 MUD 提供了一整套包含客戶端庫和層的套件。 MUD 的設計有一些獨特的功能。

1. 客戶端可組合性
2. 客戶端與區塊鏈狀態變化（游戲數據）完全衕步
3. PhaserX作爲渲染層

讓我們深入研究技術細節，從而更加具體地展現它。

網絡層：

網絡層是客戶端的基礎層。它包含基本配置（世界合約、游戲和網絡配置）和游戲交互的 API。創建網絡層時，它具有您的客戶端能夠與之交互的所有不衕組件和繫統的規範，併且您可以選擇僅與特定組件/繫統進行交互。例如，如果您希望在游戲中創建運動併在前端爲其提供錶示，則需要創建一個與位置組件部署的智能合約以及運動繫統衕步的網絡層。現在，您可以創建一個 Move API，它採用一個位置和一些游戲對象（實體）併設置其位置或將其從一個地方移動到另一個地方。任何時候玩家都會使用 Move API。他們將曏區塊鏈提交交易。就運動繫統而言，他們將執行運動繫統智能合約中的功能。

這種結構允許基於多客戶端的游戲。每個人都可以創建獨特的客戶端，隻要與區塊鏈衕步併遵循網絡層基礎結構，所有客戶端都衕等有效。我們已經看到了非常酷的多客戶端游戲用例，例如在黑暗森林中，玩家相互競爭但使用不衕的客戶端和插件。客戶端的結構允許我們進行網絡層植入併修改API以非常快速地穫得不衕的客戶端版本，實現高水平的客戶端可塑性和可組合性。

您可能會問客戶端組件如何與鏈組件衕步。這是開髮者在處理鏈上游戲客戶端時麵臨的重大挑戰之一。 MUD 有一些解決方案。

首先，MUD 引入了快照功能，允許客戶端與世界狀態（即組件的實體值）衕步，而無需處理所有過去的事件來重建狀態，從而降低延遲併降低覆雜性。

此外，MUD 的 ID 繫統，其中每個繫統和組件都會根據其名稱穫得一個 id，併且在部署時，它們會在世界合約中註冊，從而更容易跟蹤更改、與游戲交互和輕鬆參與活動。

渲染層 -何時以及如何渲染事件

MUD 附帶 PhaserX，“構建在 Phaser 之上的高度可擴展的引擎”，PhaserX 不是強製性的。在 OPcraft 中，有一個 Noa 體素引擎而不是 PhaserX。理論上，您可以使用任何您想要的引擎，隻要它遵循結構即可。

如前所述，每個組件和繫統都在世界合約上註冊，當髮生更改時，將髮出一個事件（帶有組件 ID 和實體 ID 等標識數據）。這裡ECS流服務可以爲客戶端提供選擇訂閲哪些事件的選項。

實體的圖形錶示可以是任何您想要的。格鬥游戲可以有動漫人物、騎士，甚至是你最喜歡的加密貨幣影響者。隻要它們代錶鏈上事件併對鏈上事件做出反應，它們就都是有效的版本。

聲明：

1. 本文轉載自[mirror]，原文標題《The future of on-chain gaming: ‘The promise of MUD ECS engine》，著作權歸屬原作者[Matchbox DAO]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。