ARC 需要一套特定的周边基础设施，以支持其高效运行，链上游戏最终可以拥有与链下游戏类似的用户体验。

撰文：Dev Bharel、Shanav K Mehta，Jump Crypto

编译：Leia

在上一篇文章中，我们了解了构建链上游戏会给我们带来的一些优势，现在回顾一下 ARC（Action Registry Core）架构，我们认为 ARC 是构建链上游戏及其相关基础设施的最佳方法。

ARC 是一种以数据为导向的信息组织方法（与面向对象的方法相对），由传统游戏架构模式 ECS（实体组件系统，Entity Component System）所启发。传统 ECS 与我们的链上实现 ARC 之间的主要区别在于，ARC 考虑了到区块链架构是基于推送（push-based）的，而传统游戏系统则是基于循环（loop-based）的。在 ARC 架构中，Entities 是没有数据的容器，Components 是没有行为的纯数据类型，可以「挂载」到 Entities 上，而 Actions 是可以执行与组件相关的行为的函数。

因此，Actions 负责与游戏进程相关的链上状态更新。具体来说，它们负责两种类型的操作：i）读取实体 PDA 并反序列化组件；ii）修改序列化组件以便与实体一起更新。为实现最佳性能，Actions 需要相关的基础设施，这些基础设施根据游戏运行在区块链上不同的部分而有所不同。下面，我们将介绍这些基础设施的功能，以及全链游戏（FOC）与链上资产游戏（OCA）之间，这些基础设施的需求会有哪些不同。

在阅读本文之前，建议阅读：基础设施是游戏发展的关键（二）：初探新框架——Action Registry Core

通信基础设施类型

ARC 运行所需的通信基础设施类型，同与传统数据库交互所需的基础设施相当相似。游戏进程涉及的代码库（即链上资产游戏的服务器、全链游戏的客户端），需要能够从区块链读取状态并将状态写入区块链。与传统数据库一样，第一部分可以通过索引器解决，第二部分则可以通过某种数据中继基础设施解决。下面我们详细介绍每个部分，包括链上资产游戏和全链游戏的需求差异。

注意：尽管在下文中我们是在 ARC 方法中讨论这些基础设施，但是其中一些基础设施并非仅适用于 ARC，也可能适用于面向对象的方法。

1. 索引器

索引器这一基础设施是全链游戏和链上资产游戏的共同需求。简而言之，游戏进程涉及的代码库需要从区块链中获取当前状态，以便按照单个事件顺序进行处理。对于链上资产游戏，这是游戏服务器；对于全链游戏，这则是游戏客户端。

游戏的索引器与传统区块链 RPC 节点的主要区别在于性能要求。常规 RPC 节点在提供数据方面可以承受几秒钟的数据响应时间，因为大多数用户交易本质上都是一次性的金融交易。而对于游戏来说，可能会在每个用户会话中涉及多个链上交互，这取决于游戏中哪些部分是存储在区块链上的。并且，玩家对延迟的容忍度也明显较低，这意味着数据服务时间需要在亚秒级别。游戏专用索引器还可以优化查询语言。RPC 节点通常提供基本的 API 用于查询原始数据，而索引器则可以构建专用的 API 来查询人类可读状态，便于向玩家展示游戏数据和状态。

2. 数据中继 - 链上资产游戏的 Actions

由于 Actions 只是可以执行与组件相关的行为的代码，因此无需上链。对于游戏循环在链下、资产在链上的游戏，状态更新需要经常传递到区块链上。在 ARC 架构下，Action 逻辑可以在链下推送到中继基础设施层，并将智能合约更新权限委托给该基础设施。这种方法还可以帮助减少延迟，因为它引入了一定程度的自动化，而面向对象的方法则不具备这种自动化，后者需要单独的机制来调整对象状态的变化。对于选择尽量减少信任假设的游戏，还有可能添加有效性或基于零知识证明的游戏状态证明。虽然相对来说，现在的计算成本较高，且大多数游戏并不需要这种信任度，但随着证明生成成本和时间的降低，这种程度的无需信任可能会变得更加可行。

3. 客户端 SDK - 全链游戏的 Action bundles

类似地，对于全链游戏，Action 层的逻辑可以直接嵌入到客户端 SDK 之中。然后，玩家的操作将直接影响链上的状态转换。这种模块化设计是 ARC 独有的，因为数据和意图是分离的，使得 Action 可以根据开发者的选择分布在不同的地方。

通信基础设施实战

链上资产游戏状态更新示例

我们可以以简化版的《街头霸王》（Street Fighter）为例。在简化版游戏中，玩家需要控制一个角色，进行十场战斗，才能完成游戏。玩家的操作会影响每场比赛角色的生命值，每场比赛包括三个战斗回合，先赢得两回合的玩家晋级。假设在链上资产方法中，主要游戏角色（在这个例子中，我们设定的是 Ryu 角色）被存储为链上资产。理论上，这个资产可以有多个外观属性和功能属性，但在这个例子中，我们关注的是有意义的属性（即赢得的比赛次数）。以下是一个示例，展示了链上 ARC 可能的设计模式：

Entity == Ryu character

Component #1 == Level / # of battles won

Component #2 == {Some series of cosmetic attributes}

在这种情况下，我们假设游戏循环继续在链下运行，只有我们的角色在 2/3 多数制比赛中击败另一个角色，数据才会在战斗结束时传回链上。在会话开始时，当用户连接钱包，游戏服务器将通过索引器查询实体内组件的状态。

假设它识别到角色已经赢得了三场比赛；它将利用这个信息来安排第四场战斗。现在，假设我们的角色赢了三场中的两场，游戏服务器会在内部更新状态以捕捉这一信息。但是，这些信息尚未反映在链上资产状态中。

这时，某种数据中继 / 预言机基础设施就派上用场了。根据一些预定义的触发器，游戏服务器会通过这个数据中继传递一个有效载荷，将这些数据发布到链上。在 ARC 架构下，最终影响实体内组件状态转换的是 Action。在这种情况下，Action 可以作为智能合约存在于链上，也可以存在于数据中继逻辑中。无论哪种情况，一旦 Action 获取到信息，它将反序列化组件数据，并用状态更新重新序列化它，以便下一个出块周期的组件状态反映出战斗中获胜次数的变化。

全链游戏状态更新示例

我们继续使用《街头霸王》的例子。在全链游戏中，与链上资产游戏唯一的区别是，没有链下数据库来处理任何状态更改，这意味着区块链必须是所有游戏状态转换的记录数据库。

我们再次假设我们的实体是游戏角色（如 Ryu）。和链上资产方法一样，一个组件将是我们在战斗中获胜次数的计数器。然而，在全链游戏中，我们还需要记录每个比赛中每一个操作后与生命值有关的状态更新。假设我们正在玩游戏的 PvP 版本，每场比赛中的两个玩家的角色实体都需要在一个共享合约中可访问，该合约存储了这场比赛的共享状态。

Entity == Ryu character

Component #1 == Level / # of battles won

Component #2 == Health in Match #1 in Battle #1

Component #3 == Health in Match #2 in Battle #1

如果开始游戏，玩家 1 的客户端将从共享合约中查询他们自己的角色和对手的状态。接着玩家 1 做一个动作，这个动作会对玩家 2 的生命值产生影响。假设这是使用 ARC 构建的，Action 逻辑可以与客户端软件共享，Action 将反序列化玩家 2 实体内的组件#2，从而带来链上的状态转换。在对玩家 2 做出操作对玩家 1 的组件#2 状态造成类似影响之前，玩家 2 的客户端可以索引共享合约。这样的过程将持续进行，直到比赛结束，组件#2 可以从两个实体中移除，组件#1 可以更新获胜的战斗次数数据。

这个示例对于全链游戏来说，会有计算量过大的问题，但它确实说明了基础设施在理论上是如何运作的。

需要注意的是，在这种情况下，Action 还可以独立地反序列化组件数据，以避免客户端级别的信任假设。

结论

ARC 需要一套特定的周边基础设施，以支持其高效运行。与传统的面向对象模型相比，ARC 架构可以提供增量灵活性，因为架构中的 Action 可以嵌入到周边基础设施的各个点，以使自动化更加顺畅。一旦这些周边基础设施建立起来，并对速度进行优化，链上游戏最终可以拥有与链下游戏类似的用户体验，同时享有可验证资产所有权和可编程性带来的优势。