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

星球君的朋友们

Odaily资深作者

2023-07-25 10:49 (UTC+8)

本文約3392字，閱讀全文需要約5分鐘

全鏈遊戲是如何進行“狀態”同步的？

AI總結

全鏈遊戲是如何進行“狀態”同步的？

原文作者：Fiona，IOSG Ventures

TL;DR

感謝@BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld,@0x curio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN 5 提供的幫助和寶貴意見！
全鏈遊戲/ 自治世界（「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 需要所有中間狀態的「輸入」。

圖片描述

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 需要所有中間狀態的「輸入」。