Web3 的理念似乎與遊戲產業和近年來的遊戲化趨勢完美契合。相當長一段時間以來，我們一直被承諾以一種獨特的體驗：鏈上游戲的形式帶來新的顛覆。去中心化等特性將權力平衡從遊戲產業的現有者，更多地轉向創意實體，可組合性打破了長期封閉的花園的圍牆，以及玩家真正的所有權。但這些強大的理想仍然被擱置一邊，因為我們尚未在實踐中看到它們。 MUD 是第一次勇敢的嘗試，為鏈上遊戲創建一個完整的框架，這可能會點燃下一代遊戲的火花。
傳統遊戲產業的教訓
關於創新、從頭開始構建一切以及創造全新生物的痴迷有很多，但就遊戲而言，設計模式和新工程利基創建方面有數十年的經驗教訓，值得被認真對待，忽略這些就相當於嘗試使用Atari 技術創建AAA 遊戲。
當回顧遊戲開發的早期階段時，我們可以看到與鏈上遊戲明顯的相似之處：大量的人才和高度鼓舞人心的項目，但缺乏協調和清晰的框架。
在電玩遊戲早期，在遊戲引擎誕生之前，就已經確立了信念和設計模式。不同的電玩遊戲幾乎沒有共同點，在某種程度上，類似的遊戲可能有完全不同的程式碼庫。但隨著遊戲引擎的引入，一切都改變了。
很難在遊戲引擎和遊戲本身之間建立明確的區別。一般來說，遊戲引擎是具有一組規則和設計模式的框架，可以稍微修改和擴展以創建不同的遊戲實現。到了90 年代，經過多年的碎片化遊戲開發，情況發生了變化，「基於類型」的遊戲引擎和一些開發通用引擎的努力佔據了主導地位。 《Doom》和《Unreal》等遊戲的核心組件，可以重複用於創建許多不同的遊戲，相似類型的遊戲開始共享許多核心邏輯植入。開發賽車、格鬥和第一人稱射擊遊戲的成本和複雜性呈數量級下降。不可能變成了可能，一代又一代的遊戲和升級的程式碼不斷累積。從軟體的角度來看，這是遊戲開發成為龐大產業的主要原因之一。
鏈上遊戲有幾個核心問題：
-
缺乏框架：每個團隊都試圖從頭開始建立一切，導致效率低下，並且缺乏建構者處理相同問題，並優化最佳解決方案的經驗匯總和系統知識。
-
缺乏程式碼可重用性：以當今前在開發的許多鏈上遊戲為例，其中有多少可以成功複製並創造出略有不同的遊戲？有多少在遊戲的不同層和組件之間有明確的區別，從而允許使用類似的程式碼庫來建立更新一代的遊戲？創建最重要且相互關聯的遊戲開源專案的承諾似乎還很遙遠。
-
缺乏資料可組合性：它並不以程式碼可重複使用性結束，它還涉及鏈上游戲利用共享區塊鏈狀態，使用遊戲A 和遊戲B 中的資料相互建構的能力。在實踐中，需要花費大量的工作和資源來整合遊戲A 的數據和邏輯，一場比賽變成另一場比賽。
MUD 的解決方案：
MUD 是第一個勇敢的嘗試，透過提供可維護性、可升級性和可成型性的結構，作為鏈上游戲創建引擎和框架。 MUD 所提倡的實體組件系統（ECS）模式，對於一般遊戲開發有意義，對於鏈上游戲開發更有意義。
智能合約中的ECS：
MUD 中最基本的建構塊是元件（Components），它們以智慧合約形式存在，其功能類似於儲存實體（Entity）資料的資料庫。例如，我們有一個實體（以太坊地址），例如玩家的錢包地址。此位址表示的實體可以具有不同的屬性，例如：位置元件中的位置(x,y)、層級元件中的層級10，以及代幣元件中的數值50，元件（Components）僅包含對映和基本配置。
系統（Systems）更加複雜，並且實作了改變元件（Components）值的邏輯。你可以將其視為系統（Systems）指定資料庫（元件）上的POST 請求API。只有獲得特定元件（Components）的寫入權限，他們才能向該元件寫入數據，這裡就變得有趣了。系統（Systems）可以與不同的元件互動以建立詳細的邏輯。你可以有一個移動系統，指定玩家可以進行的有效移動（例如：每次移動兩步），你也可以有一個獎勵系統，每次玩家升級時都會給他們金幣。
所有這些都在世界合約（World contact）中註冊，以便組件資料的每次變更都會發出事件。世界合約是無需許可的，任何人都可以添加新的系統和組件。理論上，不同的世界合約可以相互作用。
將ECS 引入鏈上游戲會產生非常優雅的結構，使得OPcraft 僅由10 個組件和大約15 個系統組成。
真正的可組合性
ECS 系統不僅在傳統遊戲開發中具有完美的意義，在鏈上遊戲中更是如此，因為它提供了兩個重要的功能：
-
已部署遊戲的可升級性
-
最高程度的可組合性
想像兩條路徑：一是保留基礎設計，另一個是改變核心遊戲邏輯。
想像一下標準的PVP 策略遊戲，玩家可以組成軍隊互相戰鬥。基礎版本是2D，但現在團隊決定為遊戲創建3D 渲染。他們所需要做的就是取得所有與位置相關的系統（Systems），並使用(x,y,z) 座標而不是(x,y) 建立昇級版本。所有其他系統（Systems）和組件（如：攻擊系統、生命值和軍隊建築）可以保持不變。它甚至超越了最初開發團隊的範圍，社群可以透過重新部署系統和元件，來創建遊戲的不同模組（Mod），甚至可以透過授予對新系統（Systems）的寫入權限，來與相同的元件進行互動（如果是社群擁有的遊戲，可以使用各種治理模型來表決此類決定）。
另一種方法保留相同的元件和系統，不給予新系統寫入存取權限，而是透過添加元件（Components）和系統（Systems）來擴展遊戲內的功能，它會是什麼樣子？考慮一個基本的鏈上國際象棋遊戲，動作和規則系統已經部署。人們可以像玩現實生活中的國際象棋一樣玩遊戲，但也許你的團隊決定創建一個額外的層：一個包含用於匹配或任何其他用例的評級系統的社交層。你需要做的就是增加一個評級元件（Component）和一個有評級規則的系統（System）。這不僅可以非常無縫地使用戶遷移到新的遊戲版本（更好的用戶體驗），而且還為不同版本在智慧合約層面並存或相互疊加創造了技術手段。玩家可以在不同的遊戲版本上玩，同時與相同的核心組件的數據進行交互，這除了可組合性應用程式之外，也是非常創新的。它創造了選擇加入不變性的功能，創造了鏈上游戲提供的另一個所有權維度。不同遊戲資產（如分數、NFT、成就）的真正所有權由不可變的邏輯保護，這些邏輯可以透過額外的升級進行擴展，但其核心不會改變。它解決了Web3 遊戲的主要問題之一，即創作者可以在未經同意的情況下削弱資產的能力。
客戶端整體視角：
請注意，MUD 是一個正在進行的項目。下一部分可能不是最新的，並且可能有一些不準確的描述，但整體架構應該不會發生巨大變化。
到目前為止，我們已經研究了智能合約層面的MUD。但還有更多，MUD 提供了一整套包含客戶端庫和層的套件， MUD 的設計有一些獨特的功能。
-
客戶端可組合性
-
客戶端與區塊鏈狀態變化（遊戲資料）完全同步
-
PhaserX 作為渲染層
讓我們深入研究技術細節，使其更加具體。
網路層：
網路層是客戶端的基礎層。它包含基本配置（World 合約、遊戲和網路配置）和遊戲互動的API。建立網路層時，它具有你的客戶端能夠與之互動的，所有不同元件和系統的規範，並且你可以選擇僅與特定元件/系統進行互動。
例如，如果你希望在遊戲中創建運動，並在前端對其進行表示，則需要創建一個與位置組件部署的智慧合約，以及運動系統同步的網路層。現在你可以建立一個Move API，它作用於一個位置和一些遊戲內物件（實體），並設定其位置或將其從一個地方移動到另一個地方。任何時候玩家都可以使用Move API，他們將向區塊鏈提交交易。對運動系統而言，他們將執行運動系統智能合約中的功能。
這種結構允許基於多客戶端的遊戲。每個人都可以創建獨特的客戶端，只要與區塊鏈同步並遵循網路層基礎結構，所有客戶端都同等有效。我們已經看到了非常酷的多客戶端遊戲用例，例如在黑暗森林中，玩家相互競爭但使用不同的客戶端和插件。客戶端的結構允許我們在網路層植入，並修改API以非常快速地獲得不同的客戶端版本，實現高水平的客戶端可塑性和可組合性。
你可能會問客戶端元件如何與鏈結元件同步。這是開發者在處理鏈上遊戲用戶端時面臨的重大挑戰之一，MUD 有一些解決方案。
首先，MUD 引入了快照功能，使客戶端與World 狀態（即元件的實體值）同步，而無需處理所有過去的事件來重建狀態，從而降低延遲並降低複雜性。
此外，MUD 的ID 系統，其中每個系統（System）和元件（Component）都會根據其名稱獲得一個id，並且在部署時，它們會在World 合約中註冊，從而更容易追蹤更改、與遊戲互動。
渲染圖層：Event 何時以及如何渲染
MUD 附帶PhaserX，“構建在Phaser 之上的高度可擴展的引擎”，PhaserX 不是必選的。在OPcraft 中，用的是Noa 體素引擎，而不是PhaserX。理論上，你可以使用任何引擎，只要它遵循結構即可。
如前所述，每個元件和系統都在World 合約上註冊，當發生變更時，將發出事件（帶有元件ID 和實體ID 等識別資料）。這裡ECS 串流服務可以為客戶端提供選擇訂閱哪些事件的選項。
實體的圖形表示可以是你想要的任何形式。格鬥遊戲可以有動漫人物、騎士，甚至是你最喜歡的加密領域KOL。只要它們代表鏈上事件並對鏈上事件做出反應，它們都是有效的版本。
原文連結：https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY
