全鏈遊戲是如何進行「狀態」同步的？

作者：Fiona, IOSG Ventures

封面：Photo by Javier Martínez on Unsplash

本文為 IOSG 原創內容，僅做行業學習交流之用，不構成任何投資參考。 如需引用，請註明來源，轉載請聯繫 IOSG 團隊獲取授權及轉載須知。 感謝 @BriefKandle Creator of @netherscape_xyz， @stokasz CEO@rhascau @mintersworld，@0xcurio team， @SebastienGllmt cofounder@PaimaStudios， @hiCaptainZ， and @SerenaTaN5 提供的説明和寶貴意見！

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 为例来看其运作流：

  1. 一个开发者会在 Mud 调用一些 Web2 的前端工具来编写代码，利用这些强大的功能如渲染使得游戏更可视化看起来更好玩；
  2. 同时，开发者会依 Mud 的智能合约框架（Mud World）来写游戏的人物、物品以及具体的运行逻辑等，比如当英雄 A 从 X 处移动至 Y 处，并发起对 Y 地块的讨伐，多大概率或什么情况下能成功占领该地块；
  3. 以上的动作及游戏状态会被记录在 Mud Store，它是一个链上数据库，负责全局游戏状态，是游戏状态同步的信任来源；
  4. 当英雄 A 对 Y 进行讨伐，其实是玩家在前端本机上点击了鼠标并提交了该命令上链，该命令依据开发者的游戏设计逻辑，以及当前 Store 里的游戏状态，造成了一个结果，该结果被更新至新的游戏全局状态，并被同步上链；
  5. 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。

很明显，FOG/AW 正在成为公链争夺的关键生态，由 Lattice 提出的 AW（自治世界）是一个很大的概念，不仅限于游戏、还包含社交、金融等众多属性。因此，构建在此之上的是一个充满想象力的虚拟世界，即 Metaverse。我们可以期待一些新形态的游戏、社交、金融等融合应用。

Reference:

1.https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY

2.https://jumpcrypto.com/writing/defining-on-chain-gaming/

3.https://www.oneqode.com/what-is-a-game-server/

4.https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950

5.https://latticexyz.notion.site/Building-Autonomous-Worlds-with-MUD-39d5eb5d31034589bc54a2053efb4c56

6.https://twitter.com/tarrenceva/status/1660686571270705152

7.https://book.dojoengine.org/framework/sozo/overview.html

8. https://www.youtube.com/watch?v=A0OXif6r-Qk

免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。

欢迎加入 Web3Caff 官方社群：X(Twitter)账号丨微信读者群丨微信公众号丨Telegram订阅群丨Telegram交流群