全链游戏是如何进行 “状态” 同步的？

作者：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交流群