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

作者:Dev Bharel & Shanav K Mehta

编译: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

通信基础设施类型

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

注意:尽管在下文中我们是在 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}

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

在这种情况下,我们假设游戏循环继续在链下运行,只有我们的角色在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

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

如果开始游戏,玩家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

TEDAO : 仅供学习研讨,转载/内容合作/寻求报道,请添加微信 tedaoo_0 授权并注明出处。如有任何关于协议设计、代币设计等问题,欢迎咨询、交流与探讨。

承接区块链项目定制开发

微信:btc9767

QQ :1330797917

TELEGRAM: BTCOK9

承接区块链项目定制开发


qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台-javagopython毕设 » 基础设施是游戏发展的关键(四):ARC 架构如何运作?