IOSG Ventures：詳解鏈上遊戲技術棧，如何同步遊戲狀態？

2023-07-25 16:07:32

原文作者：Fiona， IOSG Ventures

感謝@BriefKandle Creator of @netherscape_xyz, @stokasz [email protected] @mintersworld,@0x curio team, @SebastienGllmt cofo[email protected], @hiCaptainZ, and @SerenaTaN 5 提供的幫助和寶貴意見！

TL;DR

全鏈遊戲 / 自治世界（「FOG/AW」）是圍繞 Web 3 的少數重要敘事之一。相比於只通過 NFT 連接到 Web3 的 Web2.5 應用不同，FOG/AW 將遊戲邏輯也放在了鏈上。它利用區塊鏈作為遊戲服務器，成為遊戲狀態的去中心化信任源。這帶來了持久性、抗審查、可組合性等優點，但也限制了構建在其之上的遊戲多樣性和復雜性。
隨着遊戲復雜性和可玩性要求的提高，對引擎架構提出了更多的挑战要求：比如幀數延遲、隨機數、生命值恢復、連續的被動效果、計時器等等。其中時間的概念以及 Ticks 單位在區塊鏈上是不一樣的。Mud 提供了不少思路來模擬時間流逝以及被動恢復技能。比如，當玩家在房間中移動時，交易中附帶根據一些預定義的設計移動房間中的所有物品。以此感知時間和狀態的變化。
FOG/AW 技術棧可被抽象為：开發者為 ui/ux 和遊戲核心邏輯編寫前端和後端代碼，然後通過遊戲狀態的循環來同步所有的變化，最後由索引器將新的狀態反映到前端的本地設備上。
由於許多遊戲類型，如 RTS，需要高的 tickrates，而由共識產生的區塊鏈只能處理區塊時間的變化，tickrate 是這裏要解決的一個大問題。 Curio 和 Argus 是這方面的領先者，他們正在摸索鏈的層面上增加遊戲 tickrate。Mud 在試圖最大程度實現全鏈上，整個應用程序狀態都保存在 EVM 中。並沒有為實現遊戲更高 tickrate 上引入鏈下結合的方案。
對於不同鏈的選擇上，Dojo 在引領 Starknet 的全鏈生態。根據@tarrenceva 的描述，Starknet 有 State diffs 狀態差異，不同於 optimistic rollups，重點放在了執行輸出而不是輸入。對遊戲的影響主要可能在於優化成本，例如國際象棋遊戲：在三分鐘的遊戲中，可能會發生 50 步。通過狀態差異，單個證明和最終狀態可以證明「輸出」。而 optimistic rollups 需要所有中間狀態的「輸入」。

定義 FOG/AW：遊戲狀態是如何同步的

我認為要判斷是否是 FOG，基准是遊戲狀態是如何同步的（source of truth）。

對於 Web 2.5 遊戲或傳統的多人遊戲，有一個中心化的服務器來定義當前的遊戲狀態，當玩家發送行動時，服務器會編譯這些輸入並將更新的結果返回給每個連接的玩家的設備。服務器處理所有的輸入（tick），解決不一致的問題，並定期向玩家發送更新，提供遊戲中所有元素的快照，每一個 tick 都更新遊戲狀態。遊戲狀態（「game state or tick」）是遊戲世界中每個對象的屬性的時間快照。Tickrate 是指遊戲服務器每秒鐘計算並向玩家廣播更新的遊戲狀態的次數。Tickrate 越高，遊戲體驗就越精確、越高保真。一般來說，實時战略或動作遊戲需要高。tickrate，而卡牌遊戲等回合制遊戲則不需要。

Source：https://www.gabrielgambetta.com/client-server-game-architecture.html

對於完全運行在鏈上的遊戲，區塊鏈是遊戲服務器並作為遊戲狀態的去中心化的信任源。在這種情況下，不僅 NFTs 或代幣有真正的所有權，就連遊戲者的 ticks 以及遊戲邏輯也是在鏈上的。這就是為什么可以實現真正的所有權、持久性、抗審查性、可組合性等。理想情況下，遊戲者的每個動作都應該提交給區塊鏈，在達成共識後，遊戲狀態被更新並返回到本地設備。因此，自然而然地，需要較少 tickrate 的遊戲類型更適合完全在鏈上進行。

解決遊戲的延遲、時間等的挑战

隨着遊戲復雜性和可玩性要求的提高，對引擎架構提出了更多的挑战要求：比如幀數延遲、隨機數、生命值恢復、連續的被動效果、計時器等等。

幀數延遲其實在 Web2 世界也非常普遍，來自包括客戶端渲染和用戶操作上的延遲。特別是 FPS 這種高 tickrate 遊戲，一旦出現延遲，玩家體驗會非常差，Web2 中的其中一個解決辦法是 lockstep state update，讓所有玩家的同步按玩家中最高延遲的標准來同步，以此解決玩家公平性的體驗。當引入區塊鏈並需要等待交易確認後，這個延遲可能會更嚴重。為此，Mud 也增加了遊戲中常用的 optimistic rendering 樂觀渲染這一機制，假設用戶操作成功，並在服務器同意之前（或者在本例中是在事務確認之前）將其渲染在客戶端中。

鏈上生成隨機數是一個經常被討論的課題，Mud 認為可以將用戶行為作為隨機結果的輸入，在交互發生後生成。

時間的概念以及 Ticks 單位在區塊鏈上是不一樣的。@SebastienGllmt 認為在用 fraud proof 概念的鏈上（比如 Op）很難使用計時器，因為一旦出錯，將需要回滾，如果遊戲中用到計時器，體驗將很差。Mud 提供了不少思路來模擬時間流逝以及被動恢復技能。比如隨時間流逝增加金幣，每次玩家執行需要金幣的操作時，根據玩家之前的金幣數量、最近一次刷新的數量和刷新率來計算玩家的金幣數量。再比如，當玩家在房間中移動時，交易中附帶根據一些預定義的設計移動房間中的所有物品。以此感知時間和狀態的變化。

寫腳本「作弊」也許不是問題。@BriefKandle 不認為對遊戲系統的 MEV 算作弊，防止腳本能簡單的 MEV 是遊戲團隊需要考慮的事情，Web2 的遊戲开發需要轉變思路，好的 MEV bot 是遊戲內的 NPC。

部分功能已在最近推出的一些鏈上遊戲中實現，比如 Rhascau 中，他們使用了計時器和連續被動效果。基本上使用區塊時間作為刻度。( 在當前的 L2 中，區塊時間 = tickrate）。

FOG/AW 技術棧

FOG/AW 引擎框架是一個开發者工具棧，可以讓开發者利用區塊鏈作為服務器和信任源構建遊戲。此外，它可以解決目前的一些問題：

由於沒有標准 / 現成的框架，構建鏈上 FOG/AW 的效率低下；
缺乏模塊化和代碼重用性；
缺乏可組合性。隨着 FOG/AW 引擎的發展，鏈上遊戲可以更加有趣和富有想象力。

為了便於理解，這類引擎一般簡化的技術流程是：开發者為 ui/ux 和遊戲核心邏輯編寫前端和後端代碼，然後通過遊戲狀態的循環來同步所有的變化，最後由索引器將新的狀態反映到前端的本地設備上。

為了使運行在區塊鏈上的遊戲也能順暢地運行這一回路，Mud，Dojo，Curio，Argus，Paima engine 及 Lootchain 等正在為此开發各自的技術棧。技術棧由 3 個關鍵部分組成：鏈、核心开發棧和遊戲前端。他們都有自己的創新，在去中心化和遊戲復雜性之間做出權衡。

遊戲前端：包含傳統引擎如 Unity、Unreal 等以及 react/Threejs 等語言和強大的工具提供渲染等功能，增強遊戲可玩性和體驗感必不可少的一環。以上項目基本都能提供相關 SDK 供开發者使用。
核心开發棧：設計一套方案能讓遊戲邏輯運行在區塊鏈上，並能按時同步到前端。關鍵組件包括合適的數據庫結構（定義遊戲行為和邏輯），以及遊戲狀態的同步和返回。
鏈：大部分選擇了 Ethereum 、 Optimism 和 Starknet 上構建。

下圖描繪了不同的協議是如何設計各自的技術棧。以 Mud V2 為例來看其運作流：

一個开發者會在 Mud 調用一些 Web2 的前端工具來編寫代碼，利用這些強大的功能如渲染使得遊戲更可視化看起來更好玩；
同時，开發者會依 Mud 的智能合約框架（Mud World）來寫遊戲的人物、物品以及具體的運行邏輯等，比如當英雄 A 從 X 處移動至 Y 處，並發起對 Y 地塊的討伐，多大概率或什么情況下能成功佔領該地塊；
以上的動作及遊戲狀態會被記錄在 Mud Store，它是一個鏈上數據庫，負責全局遊戲狀態，是遊戲狀態同步的信任來源；
當英雄 A 對 Y 進行討伐，其實是玩家在前端本機上點擊了鼠標並提交了該命令上鏈，該命令依據开發者的遊戲設計邏輯，以及當前 Store 裏的遊戲狀態，造成了一個結果，該結果被更新至新的遊戲全局狀態，並被同步上鏈；
Mud 上的遊戲支持 Web、Mobile 等各種前端，不過可能會面臨復雜的索引需求，Mode 正是為此而开發的一個鏈下索引器。

現在，讓我們談談這些核心框架的共同和不同的設計。

他們中的大多數遵循 Mud v1 設計，並利用 ECS 作為遊戲开發的數據結構。這是遊戲邏輯的編寫和呈現方式。Mud V2 對其進行了改進，數據被定義在 Tables 和 Systems，這允許其他的數據標准（不必如 V1 遵守 ECS 數據建模標准），這給了开發者更多的選擇，使其更具包容性。
大多數都使用去中心化的數據庫，因為區塊鏈自然地是遊戲狀態和數據庫的信任來源。Mud 在試圖最大程度實現全鏈上，整個應用程序狀態都保存在 EVM 中。並沒有為實現遊戲更高 tickrate 上犧牲去中心化或者引入鏈下結合的方案。
由於許多遊戲類型，如 FPS，需要高的 tickrates，而由共識產生的區塊鏈只能處理區塊時間的變化，tickrate 是這裏要解決的一個大問題。Curio 和 Argus 在自己的創新設計中，率先希望在鏈的層面上增加 tickrates。
對於不同鏈的選擇上，Curio 和 Loot 都利用 Caldera 構建 Op stack chain，除此之外，Dojo 在引領 Starknet 的全鏈生態。根據@tarrenceva 的描述，Starknet 有 State diffs 狀態差異，不同於 optimistic rollups，重點放在了執行輸出而不是輸入。對遊戲的影響主要可能在於優化成本，例如國際象棋遊戲：在三分鐘的遊戲中，可能會發生 50 步。通過狀態差異，單個證明和最終狀態可以證明「輸出」。而 optimistic rollups 需要所有中間狀態的「輸入」。

目前已經有一些遊戲構建在這些引擎之上，Mud 和 Dojo 都在為此舉辦黑客松吸引开發者構建應用，Curio 也剛在 ETHCC 發布魔獸爭霸的 minigame demo。