在上一篇文章中，我們了解了構建鏈上游戲會給我們帶來的一些優勢，現在回顧一下ARC（Action Registry Core）架構，我們認為 ARC 是構建鏈上游戲及其相關基礎設施的最佳方法。
ARC 是一種以數據為導向的信息組織方法（與面向對象的方法相對），由傳統遊戲架構模式ECS（實體組件系統，Entity Component System）所啟發。傳統ECS 與我們的鏈上實現ARC 之間的主要區別在於，ARC 考慮了到區塊鏈架構是基於推送（push-based）的，而傳統遊戲系統則是基於循環（loop-based）的。在ARC 架構中，Entities 是沒有數據的容器，Components 是沒有行為的純數據類型，可以「掛載」到 Entities 上，而Actions 是可以執行與組件相關的行為的函數。
因此，Actions 負責與遊戲進程相關的鏈上狀態更新。具體來說，它們負責兩種類型的操作：i）讀取實體PDA 並反序列化組件；ii）修改序列化組件以便與實體一起更新。為實現最佳性能，Actions 需要相關的基礎設施，這些基礎設施根據遊戲運行在區塊鏈上不同的部分而有所不同。下面，我們將介紹這些基礎設施的功能，以及全鏈遊戲（FOC）與鏈上資產遊戲（OCA）之間，這些基礎設施的需求會有哪些不同。
在閱讀本文之前，建議閱讀：基礎設施是遊戲發展的關鍵（二）：初探新框架——Action Registry Core
通信基礎設施類型
ARC 運行所需的通信基礎設施類型，同與傳統數據庫交互所需的基礎設施相當相似。遊戲進程涉及的代碼庫（即鏈上資產遊戲的服務器、全鏈遊戲的客戶端），需要能夠從區塊鏈讀取狀態並將狀態寫入區塊鏈。與傳統數據庫一樣，第一部分可以通過索引器解決，第二部分則可以通過某種數據中繼基礎設施解決。下面我們詳細介紹每個部分，包括鏈上資產遊戲和全鏈遊戲的需求差異。
注意：儘管在下文中我們是在ARC 方法中討論這些基礎設施，但是其中一些基礎設施並非僅適用於ARC，也可能適用於面向對象的方法。
1. 索引器
索引器這一基礎設施是全鏈遊戲和鏈上資產遊戲的共同需求。簡而言之，遊戲進程涉及的代碼庫需要從區塊鏈中獲取當前狀態，以便按照單個事件順序進行處理。對於鏈上資產遊戲，這是遊戲服務器；對於全鏈遊戲，這則是遊戲客戶端。
遊戲的索引器與傳統區塊鏈RPC 節點的主要區別在於性能要求。常規RPC 節點在提供數據方面可以承受幾秒鐘的數據響應時間，因為大多數用戶交易本質上都是一次性的金融交易。而對於遊戲來說，可能會在每個用戶會話中涉及多個鏈上交互，這取決於遊戲中哪些部分是存儲在區塊鏈上的。並且，玩家對延遲的容忍度也明顯較低，這意味著數據服務時間需要在亞秒級別。遊戲專用索引器還可以優化查詢語言。RPC 節點通常提供基本的API 用於查詢原始數據，而索引器則可以構建專用的API 來查詢人類可讀狀態，便於向玩家展示遊戲數據和狀態。
2. 數據中繼- 鏈上資產遊戲的Actions
由於Actions 只是可以執行與組件相關的行為的代碼，因此無需上鍊。對於遊戲循環在鏈下、資產在鏈上的遊戲，狀態更新需要經常傳遞到區塊鏈上。在ARC 架構下，Action 邏輯可以在鏈下推送到中繼基礎設施層，並將智能合約更新權限委託給該基礎設施。這種方法還可以幫助減少延遲，因為它引入了一定程度的自動化，而面向對象的方法則不具備這種自動化，後者需要單獨的機制來調整對象狀態的變化。對於選擇盡量減少信任假設的遊戲，還有可能添加有效性或基於零知識證明的遊戲狀態證明。雖然相對來說，現在的計算成本較高，且大多數遊戲並不需要這種信任度，但隨著證明生成成本和時間的降低，這種程度的無需信任可能會變得更加可行。
3. 客戶端SDK – 全鏈遊戲的Action bundles
類似地，對於全鏈遊戲，Action 層的邏輯可以直接嵌入到客戶端SDK 之中。然後，玩家的操作將直接影響鏈上的狀態轉換。這種模塊化設計是ARC 獨有的，因為數據和意圖是分離的，使得Action 可以根據開發者的選擇分佈在不同的地方。
通信基礎設施實戰
鏈上資產遊戲狀態更新示例
我們可以以簡化版的《街頭霸王》（Street Fighter）為例。在簡化版遊戲中，玩家需要控制一個角色，進行十場戰鬥，才能完成遊戲。玩家的操作會影響每場比賽角色的生命值，每場比賽包括三個戰鬥回合，先贏得兩回合的玩家晉級。假設在鏈上資產方法中，主要遊戲角色（在這個例子中，我們設定的是Ryu 角色）被存儲為鏈上資產。理論上，這個資產可以有多個外觀屬性和功能屬性，但在這個例子中，我們關注的是有意義的屬性（即贏得的比賽次數）。以下是一個示例，展示了鏈上ARC 可能的設計模式：
Entity == Ryu character
Component #1 == Level / # of battles won
Component #2 == {Some series of cosmetic attributes}
在這種情況下，我們假設遊戲循環繼續在鏈下運行，只有我們的角色在2/3 多數制比賽中擊敗另一個角色，數據才會在戰鬥結束時傳回鏈上。在會話開始時，當用戶連接錢包，遊戲服務器將通過索引器查詢實體內組件的狀態。
假設它識別到角色已經贏得了三場比賽；它將利用這個信息來安排第四場戰鬥。現在，假設我們的角色贏了三場中的兩場，遊戲服務器會在內部更新狀態以捕捉這一信息。但是，這些信息尚未反映在鏈上資產狀態中。
這時，某種數據中繼/ 預言機基礎設施就派上用場了。根據一些預定義的觸發器，遊戲服務器會通過這個數據中繼傳遞一個有效載荷，將這些數據發佈到鏈上。在ARC 架構下，最終影響實體內組件狀態轉換的是Action。在這種情況下，Action 可以作為智能合約存在於鏈上，也可以存在於數據中繼邏輯中。無論哪種情況，一旦Action 獲取到信息，它將反序列化組件數據，並用狀態更新重新序列化它，以便下一個出塊週期的組件狀態反映出戰鬥中獲勝次數的變化。
全鏈遊戲狀態更新示例
我們繼續使用《街頭霸王》的例子。在全鏈遊戲中，與鏈上資產遊戲唯一的區別是，沒有鏈下數據庫來處理任何狀態更改，這意味著區塊鏈必須是所有遊戲狀態轉換的記錄數據庫。
我們再次假設我們的實體是遊戲角色（如Ryu）。和鏈上資產方法一樣，一個組件將是我們在戰鬥中獲勝次數的計數器。然而，在全鏈遊戲中，我們還需要記錄每個比賽中每一個操作後與生命值有關的狀態更新。假設我們正在玩遊戲的PvP 版本，每場比賽中的兩個玩家的角色實體都需要在一個共享合約中可訪問，該合約存儲了這場比賽的共享狀態。
Entity == Ryu character
Component #1 == Level / # of battles won
Component #2 == Health in Match #1 in Battle #1
Component #3 == Health in Match #2 in Battle #1
如果開始遊戲，玩家1 的客戶端將從共享合約中查詢他們自己的角色和對手的狀態。接著玩家1 做一個動作，這個動作會對玩家2 的生命值產生影響。假設這是使用ARC 構建的，Action 邏輯可以與客戶端軟件共享，Action 將反序列化玩家2 實體內的組件#2，從而帶來鏈上的狀態轉換。在對玩家2 做出操作對玩家1 的組件#2 狀態造成類似影響之前，玩家2 的客戶端可以索引共享合約。這樣的過程將持續進行，直到比賽結束，組件#2 可以從兩個實體中移除，組件#1 可以更新獲勝的戰鬥次數數據。
這個示例對於全鏈遊戲來說，會有計算量過大的問題，但它確實說明了基礎設施在理論上是如何運作的。
需要注意的是，在這種情況下，Action 還可以獨立地反序列化組件數據，以避免客戶端級別的信任假設。
結論
ARC 需要一套特定的周邊基礎設施，以支持其高效運行。與傳統的面向對像模型相比，ARC 架構可以提供增量靈活性，因為架構中的Action 可以嵌入到周邊基礎設施的各個點，以使自動化更加順暢。一旦這些周邊基礎設施建立起來，並對速度進行優化，鏈上游戲最終可以擁有與鏈下游戲類似的用戶體驗，同時享有可驗證資產所有權和可編程性帶來的優勢。
