作者：Dev Bharel & Shanav K Mehta
編譯：Leia
概述
在上一篇文章中，我們討論了三種鏈上游戲類型，分別是：（1）完全上鍊（fully on-chain games, FOC），（2）資產上鍊（on-chain assets, OCA），和（3）可選資產鑄造（optional cosmetic mints, OCM）。回顧一下，由於目前缺乏支持FOC 和OCA 的基礎設施，大多數遊戲工作室選擇了OCM 方法，以避免給用戶帶來太多的阻力。在接下來的幾篇文章中，我們將重點介紹一些可能支持FOC 和OCA 的基礎設施，以及每個部件在實際應用中可能的設計方案。
首先需要的基礎設施是——一個能夠高效管理鏈上資產和遊戲狀態的系統。定義資產在鏈上的操作方式對資產可編程性（如權限管理、元數據更新等）有著實質性的影響。為了更好地了解這樣的系統可能會是什麼樣子，我們決定自己開發一個鏈上游戲（稍後會有更多介紹）。同時，我們很快發現，當遊戲的規模擴大時，基於面向對象編程（object-oriented programming, OOP）的傳統方法會遇到可擴展性的挑戰，因為資產依賴關係會隨著遊戲規模的擴大呈現出線性的增長。
因此，我們決定嘗試使用數據驅動的設計模式，這些模式在傳統遊戲開發中已被廣泛使用，但在鏈上的實踐很少。通過這個過程，我們在Solana 上嘗試了一個名為ARC（Action Registry Core）的框架，我們認為這是管理鏈上資產和遊戲邏輯最有效的方法之一。傳統遊戲開發中常用到一種數據驅動的架構模式是實體組件系統（Entity Component System, ECS)，ARC 正是由ECS 所啟發構建的。
在本文中，我們將介紹ECS 的工作原理、它在傳統遊戲中為什麼如此重要、如何將這種理念擴展到構建類似ARC 的框架，以及可能的底層架構。
我們的目標是為開源研究做出貢獻，並幫助推動鏈上游戲基礎設施的發展。秉著這種精神，我們決定開源ARC 參考實現，並歡迎社區給予任何反饋。
ARC GitHub 鏈接：[https://github.com/JumpCrypto/sol-arc?ref=jumpcrypto-com.ghost.io]
傳統遊戲開發中的ECS 是什麼？
ECS 是近年來廣泛應用於視頻遊戲的一種架構。與經典的面向對象編程（OOP）相比，ECS 可以將數據與行為分離，因此在視頻遊戲領域具有一定優勢。在傳統的Web2 遊戲中，它可以幫助提高遊戲性能（改善緩存局部性），同時在開發遊戲本身時，也能更好地控制遊戲邏輯。
了解傳統OOP 方法在面對多個依賴關係時的局限性，可以更好地幫助理解ECS 的優勢。
OOP 面臨的挑戰- 鑽石繼承問題
假設我們正在構建一個非常簡單的遊戲，具有以下屬性：
-
三個實體：i) Mammal（哺乳動物），ii) Fish（魚），iii) Amphibian（兩棲動物）
-
Mammal 可以在陸地上呼吸，但不能在水里呼吸
-
Fish 可以在水里呼吸，但不能在陸地上呼吸
-
Amphibian 既可以在水里呼吸，也可以在陸地上呼吸
在傳統的OOP 中，Mammal 可以作為一個實體，繼承自基類LandBreather（陸地呼吸者），Fish 可以作為一個實體，繼承自基類WaterBreather（水中呼吸者）。在這裡，我們遇到了Amphibian 的挑戰，它既具有LandBreather 的屬性，又具有WaterBreather 的屬性，但不能同時繼承兩者。在經典的面向對象編程中，這被稱為“鑽石繼承問題或菱形繼承問題”。這個問題在遊戲中比其他應用更為普遍，因為遊戲角色、物品和資產的數量隨著特徵和依賴關係的增加而增加。雖然存在一些變通方法，但對於遊戲來說，我們認為ECS 是最優雅的解決方案。
ECS 作為一種解決方案
基於ECS 的遊戲具有以下特性：
-
Entity（實體） – 組件的唯一標識或容器
-
Component（組件） – 不具備行為的純數據類型，可以“掛載”到實體上
-
System（系統） – 與具有一定組件集合的實體匹配的函數
實體可以包含零個或多個組件。通過使用系統，實體可以動態地添加/刪除/修改其組件。
為了了解ECS 如何解決遊戲中OOP 面臨的限制，我們可以使用ECS 解決上面舉例遇到的問題。在ECS 模式下，我們會創建兩個組件：LandBreather（陸地呼吸者）和WaterBreather（水中呼吸者）。系統LandBreatherSystem 處理具有LandBreather 組件的任何實體的移動，而係統WaterBreatherSystem 處理具有WaterBreather 組件的任何實體的移動。實體可以如下所示：
-
Mammal：[LandBreather]
-
Fish：[WaterBreather]
-
Amphibian：[LandBreather，WaterBreather]
然後，您可以動態地為實體添加更多組件，例如Fly（飛行）或Fight（戰鬥），並且也可以在它們下面創建具有不同組件的更多實體。
什麼是ARC？
ARC（Action Registry Core）是一個受傳統ECS 架構啟發的鏈上信息組織框架。與ECS 一樣，ARC 有用於組件的無數據容器——實體，以及可以“掛載”到實體上的無行為的純數據類型——組件。
與ECS 不同的是，ARC 有可以針對特定組件執行的“操作”（actions），而不是“系統”（systems）。主要區別在於，傳統ECS 中的系統是圍繞傳統遊戲中使用的基於循環（loop-based）的架構構建的，而Action Bundles 則考慮到了區塊鏈架構是基於推送（push-based）的。這裡概述的ARC 的具體實現是針對Solana 生態系統的，但其他生態系統中也可以使用類似的架構。 ARC 的基本架構是一個分為三層的洋蔥架構。首先，要有負責維護註冊表和實體的核心層（the Core）。其次，有各種註冊表（Registry）合約，它們負責維護組件和操作的註冊表以及治理功能。最後，需要有（可選的）遊戲或修改組件的操作（Actions）合約。
核心層（the Core）
核心層負責以下三件事：
-
初始化新的註冊表實例
-
以NFT 或獨立實體PDA 的形式鑄造新實體
-
維護與實體相關的SerializedComponents（序列化組件）
鏈上只需要存在一個核心程序，因為通過註冊表實例，我們可以將不同的組件、實體和規則進行分桶。在EVM 鏈上，這種方法可能行不通，因為每個合約的合約存儲有限，所以最好啟用多個核心。
具體在Solana 中，實體結構類似於為每個Metaplex NFT 生成的Metaplex 元數據。一個顯著的區別是在給定代幣上的每個註冊表實例都有一個新的實體映射。這意味著一個代幣，理論上可以有多個實體，只要它們屬於不同的註冊表（很可能有不同的組件、組件值等）。
這種行為模式是否“優於”一個代幣一個實體，這是一個尚待解答的問題。因為核心只處理序列化組件，所以它不需要擔心如何反序列化任何東西。這意味著所有反序列化邏輯可以推給遊戲或操作層。
註冊表實例是賦予註冊表及其實例ID 的唯一標識。不同的實例有助於在同一核心中實例化不同的“遊戲”，從而允許在給定的一組組件和操作中重複使用相同的註冊表管理代碼——只允許實體不同的實例化。
註冊表（Registry）
註冊表程序基本上是一個治理合約。它記錄以下內容：
-
通過Schema URL 註冊的組件。
-
可以修改給定註冊表實例的特定組件的已註冊操作。
-
創建新註冊表實例的能力。
例如，它可能規定只有管理員才能創建新的註冊表實例，或者將該權限交給DAO。
同樣適用於用其註冊的任何組件。例如，假設給定的遊戲X 中，存在一個移動操作，允許玩家以每秒1個格子的速度將棋子從一個格子移動到另一個格子。另一個團隊來創建“Portals”，在這個註冊表中允許更快的移動。要允許Portals 操作能夠修改單位上的“位置”組件，需要註冊表的治理來投票決定是否允許這種規則的改變。例如，它們可能允許特定的註冊表實例（你可以在“Portals Server”上使用它，但不能在“Hardcore Server”上使用）。
組件的更新權限在註冊表這裡，因為Actions 只是向註冊表提交其建議的更改，然後註冊表檢查治理，將更改提交給核心來修改實體。關鍵的是，Actions 不需要是鏈上游戲。它們可以是鏈下游戲基礎設施，如預言機，向遊戲DAO 控制的鏈上資產層提交更改。
The Action Bundles
Actions 是鏈上或鏈下代碼，具有以下能力：
-
讀取實體PDA 並反序列化它們認為有價值的組件。
-
修改並提交更改後的序列化組件（或一組組件）給到註冊表，以便與實體一起更新。
特定於應用程序的Actions 代碼允許遊戲的“分層”。例如，可能存在“目標：山丘之王（King of the Hill）”和“目標：擊敗（Kills）” 兩個Actions，可能可以玩三種遊戲。可以實例化一個註冊表實例，該實例僅允許第一個Action、第二個Action 或兩者都處於活躍狀態並允許對組件進行更改。
ARC 對鏈上游戲的幫助
對於FOC 和OCA 類型的遊戲來說，ARC 具有幾個優點，包括：
-
模式更改的同時，保持向後兼容性（Backwards compatibility）。
-
由於實體可以容納動態組件，因此可以同時維護組件的v1和v2版本。
-
這允許舊應用程序可以進行查詢，而不會丟失操作支持。
-
效率（Efficiency） – 由於實體的大小由它們所擁有的組件決定，因此它們的大小只有在需要時才會變大。
-
可重複性（Repeatability） – 由於基礎實現非常簡單，因此可以在各種生態系統中輕鬆使用相同的實現。
-
熟悉性（Familiarity） – Web2 遊戲公司對這個框架也會更加熟悉。
-
模塊化（Modularity） – 隨著需求的變化，可以模塊化地添加新的屬性/行為。
-
可擴展性（Extensibility） – 鏈上資產層對於那些使用鏈上資產的混合遊戲以及全鏈遊戲（這些遊戲可以讀取和修改狀態）都很有用。
-
跨鏈可訪問性（Cross-chain accessibility） – 簡單的跨鏈序列化框架和跨鏈身份框架可以簡化應用程序向其他鏈的移植。接下來的文章中將詳細介紹。
總結
總的來說，Action Registry Core 是一個用於管理遊戲鏈上資產層的框架，支持全鏈遊戲和利用鏈上資產的遊戲。這種架構提供了可擴展性，隨著遊戲資產數量和相互依賴性的增加，可以避免面向對象編程方法可能帶來的技術債務。在接下來的文章中，我們將深入探討基於ARC 的鏈上游戲後端的使用情況，並探索完成堆棧所需的其他基礎設施。
特別感謝Joe Howarth、Ben Huan、Anirudh Suresh 以及其他朋友們的寶貴意見！
原文：Gaming Infrastructure Part 2: Introduction to ARC
來源：Jump Crypto
