HTH华体会如何将传统游戏开发中的经验应用到区块链游戏中？由 ECS 架构所启发，Jump Crypto 提出了一种新框架 ARC，为全链游戏和资产上链的游戏提供了高效、可重用、易扩展和跨链互操作的支持，让 Web3 游戏开发更加轻松。

　　在上一篇文章中，我们讨论了三种链上游戏类型，分别是：（1）完全上链（fully on-chain games, FOC），（2）资产上链（on-chain assets, OCA），和（3）可选资产铸造（optional cosmetic mints, OCM）。回顾一下，由于目前缺乏支持 FOC 和 OCA 的基础设施HTH华体会，大多数游戏工作室选择了 OCM 方法，以避免给用户带来太多的阻力。在接下来的几篇文章中，我们将重点介绍一些可能支持 FOC 和 OCA 的基础设施，以及每个部件在实际应用中可能的设计方案。

　　首先需要的基础设施是——一个能够高效管理链上资产和游戏状态的系统。定义资产在链上的操作方式对资产可编程性（如权限管理、元数据更新等）有着实质性的影响。为了更好地了解这样的系统可能会是什么样子，我们决定自己开发一个链上游戏（稍后会有更多介绍）。同时，我们很快发现，当游戏的规模扩大时，基于面向对象编程（object-oriented programming, OOP）的传统方遇到可扩展性的挑战，因为资产依赖关系会随着游戏规模的扩大呈现出线性的增长。

　　因此，我们决定尝试使用数据驱动的设计模式，这些模式在传统游戏开发中已被广泛使用，但在链上的实践很少。通过这个过程，我们在 Solana 上尝试了一个名为 ARC（Action Registry Core）的框架，我们认为这是管理链上资产和游戏逻辑最有效的方法之一。传统游戏开发中常用到一种数据驱动的架构模式是实体组件系统（Entity Component System, ECS)，ARC 正是由 ECS 所启发构建的。

　　在本文中，我们将介绍 ECS 的工作原理、它在传统游戏中为什么如此重要、如何将这种理念扩展到构建类似 ARC 的框架，以及可能的底层架构。

　　我们的目标是为开源研究做出贡献，并帮助推动链上游戏基础设施的发展。秉着这种精神，我们决定开源 ARC 参考实现，并欢迎社区给予任何反馈。

　　ECS 是近年来广泛应用于视频游戏的一种架构。与经典的面向对象编程（OOP）相比，ECS 可以将数据与行为分离，因此在视频游戏领域具有一定优势。在传统的 Web2 游戏中，它可以帮助提高游戏性能（改善缓存局部性），同时在开发游戏本身时，也能更好地控制游戏逻辑。

　　在传统的 OOP 中，Mammal 可以作为一个实体，继承自基类 LandBreather（陆地呼吸者），Fish 可以作为一个实体，继承自基类 WaterBreather（水中呼吸者）。在这里，我们遇到了 Amphibian 的挑战，它既具有 LandBreather的属性，又具有 WaterBreather的属性，但不能同时继承两者。在经典的面向对象编程中，这被称为“钻石继承问题或菱形继承问题”。这个问题在游戏中比其他应用更为普遍，因为游戏角色、物品和资产的数量随着特征和依赖关系的增加而增加。虽然存在一些变通方法，但对于游戏来说，我们认为 ECS 是最优雅的解决方案。

　　然后，您可以动态地为实体添加更多组件，例如 Fly（飞行）或 Fight（战斗），并且也可以在它们下面创建具有不同组件的更多实体。

　　ARC（Action Registry Core）是一个受传统 ECS 架构启发的链上信息组织框架。与 ECS 一样，ARC 有用于组件的无数据容器——实体，以及可以“挂载”到实体上的无行为的纯数据类型——组件。

　　与 ECS 不同的是，ARC 有可以针对特定组件执行的“操作”（actions），而不是“系统”（systems）。主要区别在于，传统 ECS 中的系统是围绕传统游戏中使用的基于循环（loop-based）的架构构建的，而 Action Bundles 则考虑到了区块链架构是基于推送（push-based）的。这里概述的 ARC 的具体实现是针对 Solana 生态系统的，但其他生态系统中也可以使用类似的架构。ARC 的基本架构是一个分为三层的洋葱架构。首先，要有负责维护注册表和实体的核心层（the Core）。其次，有各种注册表（Registry）合约，它们负责维护组件和操作的注册表以及治理功能。最后HTH华体会，需要有（可选的）游戏或修改组件的操作（Actions）合约。

　　链上只需要存在一个核心程序，因为通过注册表实例，我们可以将不同的组件、实体和规则进行分桶。在 EVM 链上，这种方法可能行不通，因为每个合约的合约存储有限，所以最好启用多个核心。

　　具体在 Solana 中，实体结构类似于为每个 Metaplex NFT 生成的 Metaplex 元数据。一个显著的区别是在给定代币上的每个注册表实例都有一个新的实体映射。这意味着一个代币，理论上可以有多个实体，只要它们属于不同的注册表（很可能有不同的组件、组件值等）。

　　这种行为模式是否“优于”一个代币一个实体，这是一个尚待解答的问题。因为核心只处理序列化组件，所以它不需要担心如何反序列化任何东西。这意味着所有反序列化逻辑可以推给游戏或操作层。

　　注册表实例是赋予注册表及其实例 ID 的唯一标识。不同的实例有助于在同一核心中实例化不同的“游戏”，从而允许在给定的一组组件和操作中重复使用相同的注册表管理代码——只允许实体不同的实例化。

　　同样适用于用其注册的任何组件。例如，假设给定的游戏 X 中，存在一个移动操作，允许玩家以每秒1个格子的速度将棋子从一个格子移动到另一个格子。另一个团队来创建“Portals”，在这个注册表中允许更快的移动。要允许 Portals 操作能够修改单位上的“位置”组件，需要注册表的治理来投票决定是否允许这种规则的改变。例如，它们可能允许特定的注册表实例（你可以在“Portals Server”上使用它，但不能在“Hardcore Server”上使用）。

　　组件的更新权限在注册表这里HTH华体会，因为 Actions 只是向注册表提交其建议的更改，然后注册表检查治理，将更改提交给核心来修改实体。关键的是，Actions 不需要是链上游戏。它们可以是链下游戏基础设施，如预言机，向游戏 DAO 控制的链上资产层提交更改。

　　特定于应用程序的 Actions 代码允许游戏的“分层”。例如，可能存在“目标：山丘之王（King of the Hill）”和“目标：击败（Kills）” 两个 Actions，可能可以玩三种游戏。可以实例化一个注册表实例，该实例仅允许第一个 Action、第二个 Action 或两者都处于活跃状态并允许对组件进行更改。

　　总的来说，Action Registry Core 是一个用于管理游戏链上资产层的框架，支持全链游戏和利用链上资产的游戏。这种架构提供了可扩展性，随着游戏资产数量和相互依赖性的增加，可以避免面向对象编程方法可能带来的技术债务。在接下来的文章中，我们将深入探讨基于 ARC 的链上游戏后端的使用情况，并探索完成堆栈所需的其他基础设施。