基础设施是游戏发展的关键(四):ARC 架构如何运作?

By Dev Bharel & Shanav K Mehta

|概述

在上一篇文章中,我们了解了构建链上游戏会给我们带来的一些优势,现在回顾一下 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 可能的设计模式:

1 Entity == Ryu character
2 Component #1 == Level / # of battles won
3 Component #2 == {Some series of cosmetic attributes}

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

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

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

>>全链游戏状态更新示例

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

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

1 Entity == Ryu character
2 Component #1 == Level / # of battles won
3 Component #2 == Health in Match #1 in Battle #1
4 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 可以嵌入到周边基础设施的各个点,以使自动化更加顺畅。**一旦这些周边基础设施建立起来,并对速度进行优化,链上游戏最终可以拥有与链下游戏类似的用户体验,同时享有可验证资产所有权和可编程性带来的优势。

原文:Gaming Infrastructure Part 4: Communication Infra in an ARC World

来源:Jump Crypto

Subscribe to TEDAO
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.