IOSG Weekly Brief ｜链上游戏技术栈：如何同步游戏状态？

CoinVoice2023-07-25

作者：Fiona, IOSG Ventures

TL;DR

全链游戏/自治世界（"FOG/AW"）是围绕Web3的少数重要叙事之一。相比于只通过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，而卡牌游戏等回合制游戏则不需要。

对于完全运行在链上的游戏，区块链是游戏服务器并作为游戏状态的去中心化的信任源。在这种情况下，不仅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。