Argus：迈向跨游戏之路的论文

主要收获

• Argus 是一家链上游戏开发和发行公司，创建了 World Engine，这是一个内部引擎，旨在克服链上游戏的技术限制。World Engine 是一个分片 Layer 2 SDK，具有循环驱动的运行时和分片功能，可提高可扩展性，这两者都更适合游戏应用。

• World Engine 将智能合约相关的逻辑和游戏执行逻辑分别分离到 EVM 基本分片和游戏分片中。EVM 基本分片使用名为 Polaris 的框架来利用现有的以太坊开发者工具和基础设施，同时通过路由器与游戏分片进行交互。

• Argus 的 World Engine 的潜在应用通过一个链上视觉小说游戏的案例研究来说明。该游戏是在 Interchain Hackathon 期间创建的，它连接了 Cardinal、Nakama（一个开源游戏服务器）和一个用户客户端，以提供多人在线视觉小说体验。

游戏很难制作，但完全链上游戏（FOCG）更难。在弥合这一差距的显著尝试中，今天我们将关注 Argus 和 World Engine。

1、Argus 是一家游戏开发和发行公司

Argus 的根源可以追溯到第一代 FOCG，Dark Forest。在不到一周的时间里拥有超过 1 万名玩家，并占据了当时 Gnosis Chain 的大部分区块空间，Dark Forest 是一款具有历史意义的游戏，它展示了 FOCG 的潜力。Scott 共同创建了 Dark Forest，我想知道他在这段时间的经历是否促成了 Argus 的成立。

来源：designboom

当你想到 Argus 时，首先想到的就是 World Engine，但 Argus 对被视为基础设施公司持谨慎态度，并将其描述为一家游戏开发和发行公司。为什么？我在这个播客中找到了答案。World Engine 是 Argus 创建的一个内部引擎，以便他们可以创建链上游戏，而不受当今现有技术选择的限制。该基础设施仅公开，以便其他游戏工作室可以使用它。换句话说，重点是“制作有趣的游戏”。事实上，仅仅看看他们的网站，似乎他们目前正在使用 World Engine 开发大约三款游戏。

如果我们看看传统游戏行业的早期，最流行的游戏引擎并非有意创建的，而是由游戏工作室创建和共享以制作自己的游戏，我们可以假设，在链上游戏行业中，最有用的游戏引擎将来自制作各种游戏的游戏工作室，而不是来自专门从事链上游戏基础设施的公司。

来源：Argus

2、World Engine 的背景

与链上游戏相关的许多技术限制和约束，从根本上说，都是因为我们试图在一个最初并非为游戏设计的区块链上构建游戏，而许多声称是游戏链的项目实际上是 NFT 的链。在此背景下，World Engine 是一个从头开始构建的分片 Layer 2 SDK，其中考虑了游戏开发者和玩家。

World Engine 的主要特点如下：

首先，它是一个循环驱动的运行时。大多数现有的 dApp，例如 Uniswap，都使用响应用户输入的事件驱动型运行时。但是，这对于游戏来说并不理想。例如，在 Minecraft 等游戏中，无论用户输入如何，都需要不断更新天气和重力等元素。游戏更喜欢循环驱动的运行时，其中状态在单个tick中以定义的循环更新。此外，游戏更常见的是在单个tick内具有或多或少固定的状态更改顺序。但是，事件驱动型运行时不适合游戏，因为交易的执行顺序总是会因多种因素而发生变化，因此循环驱动型运行时更适合游戏。

接下来是分片。由于 Layer 2 也是一个计算平台，因此当它达到一定数量的玩家时，必须采取某些措施来提高可扩展性。通常的方法是启动另一个 rollup，但是你会遇到 rollup 之间的互操作性和碎片化问题。使用共享排序层（这是当今的趋势）可以在一定程度上避免此问题，但是它也引入了新问题，例如必须依赖 slashing 并容易受到 DOS 攻击。因此，World Engine 采用了一种分片方法，该方法受到传统 MMO 游戏服务器结构的启发。实际的分片可能因游戏公司而异：每个区域都可以进行分段并分配给不同的分片，或者每个服务器实例都可以像 MapleStory 中的频道一样分配给一个分片。默认情况下，每个分片彼此异步，因此分片之间的原子捆绑之类的操作是不可能的，尽管除非是 DeFi，否则几乎不需要两个链同步兼容。

最后，还有可组合性。Argus 设想了 Intergame Thesis，这不仅是游戏之间的兼容性，还是链上游戏行业中利益相关者（例如游戏发行商、市场、模组制作者等）之间的兼容性。为了实现这一 Intergame Thesis，需要一个通用标准或系统，而 World Engine 目前正在努力实现这一目标。

3. World Engine 的结构

通过将与智能合约相关的逻辑与 EVM 基本分片分离，并将与游戏执行相关的逻辑与游戏分片分离，World Engine 可以将区块链的兼容性与高吞吐量游戏服务器相结合。

来源：Argus

3.1 EVM 基本分片

前面，我们提到 World Engine 使用分片，所有与智能合约相关的逻辑都在此基本分片上处理。EVM 基本分片是一个通用的 EVM rollup，它仍然利用以太坊生态系统的开发者工具和基础设施，并通过路由器与游戏分片进行交互。EVM 基本分片是开发者、模组制作者和玩家可以部署各种与游戏相关的服务（例如市场和 DEX）的地方。Argus 通过名为 Polaris 的东西来实现 EVM 基本分片。

3.1.1 Polaris

Polaris 是 Berachain 创建的一个框架或插件，其主要目的是允许任何链使用以太坊等效级别的 EVM。例如，你可以使用 Comet 作为共识层，使用 Cosmos SDK 作为执行层，然后使用 Polaris 作为其上的运行时层，以获得与以太坊相同级别的 EVM。

通过将基础层与 EVM 运行时层分离，Polaris 允许开发者在基础层上尝试不同的方法，而不会破坏 EVM。预计通过目前正在开发中的 Precompile Development Kit，添加自定义预编译将变得更加容易。Polaris 的有状态预编译还可以访问 Cosmos 的应用程序和共识层，从而允许你通过 EVM 使用 Cosmos 模块，例如 Staking 和 Authz。

3.1.2 回到 World Engine

利用 Polaris 的可定制性，World Engine 的 EVM 基本分片具有以下特点：

• 它具有一个专门的 gRPC 服务器，以便以后的游戏分片可以连接到 EVM 基本分片以提交和存储交易。请注意，gRPC 比 JSON-RPC 具有许多优点，例如效率更高，并且支持不同的编程语言和流类型。

• EVM 基本分片的特殊预编译允许消息从智能合约传递到实现此 gRPC 服务器的游戏分片。

EVM 基本分片通过 Rollkit 连接到数据可用性层 Celestia，你可以在本文中阅读有关 Rollkit 的更多信息，并观看此视频以了解有关将 Rollkit 与 Polaris 结合使用的更多信息。

3.2 游戏分片

运行游戏涉及的所有逻辑都由游戏分片处理，游戏开发者可以使用现有的游戏分片或为其游戏创建一个新的游戏分片。Cardinal 是 Argus 创建的第一个游戏分片实现。

作为第一个游戏分片，Cardinal 具有以下特点：

• 原生支持游戏开发中常用的 ECS 框架，使游戏开发者更容易适应。

• 支持基于 tick 的循环驱动的运行时，支持高达每秒 20 个 tick。

• 游戏逻辑可以用 Golang 编写。

• 与 Unity、Unreal Engine 等游戏引擎兼容。

• 不需要索引器。

你可以在 Argus 的 GitHub 上看到使用 CardInal 的一个示例游戏。

4、案例研究：链上视觉小说

4.1 免责声明

这是在参加 Interchain Hackathon 时对 World Engine 的独立、任意的理解和使用，因此它可能不正确，并且可能不是使用 World Engine 的最佳方式。建议你仅将其视为“这就是你可以使用 World Engine 的方式”之类的东西。完整的代码可以在以下 GitHub 上找到：

• 后端

• 前端

4.2 背景

我们想要创建的游戏是一款多人在线视觉小说游戏，该游戏使用 GPT-4 API 户感觉像他们真的在与游戏中的 NPC 交谈，并且第一个与 NPC 达到 100 Likability 评分的玩家将赢得比赛。

我们的游戏不需要对 EVM 基本分片进行任何修改，因为我们不需要向现有的 EVM 基本分片添加智能合约逻辑，但是我们需要关注三个主要组件：

• Cardinal：我们从 Argus GitHub 上 fork 了“stater-game-template”，以使用现有的 Cardinal，并且只修改了游戏逻辑以适应我们的游戏。

• Nakama：Nakama 是 Heroic Labs 创建的一个开源游戏服务器，它提供了多人游戏所需的许多元素。在此示例中，Nakama 用于连接 Cardinal 和 Client。

• Client：我们使用 Next.js 作为用户直接查看和玩游戏的界面。

我们理解的 Cardinal、Nakama 和 Client 之间的关系如下：

1. 发生来自用户的输入。

2. Client 通过 RPC 调用将该输入传递给 Nakama。

3. Nakama 将与 RPC 调用对应的交易传递给 Cardinal。

4. Cardinal 接收交易，在下一个游戏 tick 中执行它，更新游戏状态，并生成交易回执 (tx receipt)。

5. 交易回执从 Cardinal 传递给 Nakama。

6. 客户端订阅 dispathcer，并定期从 Cardinal 接收交易回执，并更新客户端状态。

4.3 Cardinal

4.3.1 ECS 模型

在查看 Cardinal 之前，我们首先来谈谈 ECS 结构。我们通常在编程时使用的基于继承的结构对于大规模多人游戏来说可能效率不高。在下面的示例中，我们目前有一个名为“Mammal”的类和一个名为“Bird”的类，它们继承自名为“Thing”的类。如果我们想添加鸭嘴兽，我们将无法从这些类继承，并且必须创建一个新类。在真正的游戏中，有很多时候你需要像这样添加新的游戏对象，并且基于继承的结构可能不合适。

与基于继承的结构不同，ECS 通过将每个部分分离为以下部分来强调模块化：

• 组件：组件是 ECS 模型的核心，仅保存数据。例如，“Health”组件仅包含健康指标，“Location”组件仅包含当前位置的坐标值。

• 实体：实体充当容器，其中包括多个带有唯一标识符标识的组件。例如，特定实体可能包含诸如“Health”、“Location”、“Player”等组件，这些组件将用于表示用户。

• 系统：访问或修改特定组件的逻辑。例如，影响“Health”组件的“attack_player”，影响“Location”组件的“move_player”等都将是系统。

4.3.2 交易回执

由于 Cardinal 不会在收到交易后立即处理交易，因此它首先将交易哈希值传递给 Nakama，然后在实际处理交易后生成并交付带有哈希、结果和任何错误的回执。

4.3.3 代码示例

在我们的游戏中，我们定义了新的玩家和 likeness 组件，并在 ECS 模型中实现了它们的逻辑，但是让我们以如何添加玩家为例。

首先，我们定义一个“Player”组件，该组件仅保存有关玩家姓名的数据。

接下来，我们首先定义一个“CreatePlayer”交易，该交易在用户加入游戏时触发新玩家的创建。

收到上述交易后，Cardinal 将运行一个“PlayerSpawnerSystem”，该系统将实际创建玩家。正如你在下面的代码中看到的那样，当 PlayerSpawnerSystem 收到“CreatePlayer”交易时，它会创建一个新的实体，其中包含一个玩家和一个 likeness 组件。

最后，在“main.go”文件中，我们需要将新创建的组件、交易和系统注册到“world”对象。

4.4 Nakama

Nakama 1) 提供了 Cardinal 和客户端之间的连接，并且 2) 提供了多人游戏服务器的许多功能。例如，用户身份验证、会话管理、比赛设置等都可以通过 Nakama 轻松实现。几乎每种与游戏相关的语言（包括 Javascript、Unity 和 Godot）都有 SDK 和引导式示例，因此即使是我们这些 Nakama 新手也可以上手。对于我们的团队而言，我们在 Next.js 中实现了我们的客户端，因此我们严重依赖于一个名为“ xoxo-phaserjs”的 Nakama + Javascript 示例。

4.4.1 Nakama w/ Cardinal

Argus 提供的“starter-game-template”是对 Nakama 的一个轻微修改，使其可以更好地与 Cardinal 一起使用，因此，如果你想使用 Cardinal 创建游戏，则可以使用此模板。当新玩家启动基于 Cardinal 的游戏时，他们需要做的第一件事是设置 Persona Tag。此 Persona Tag 存储在 Nakama 中，用于为该用户生成签名秘钥，该秘钥将自动签名并将该用户提交的未来交易发送给 Cardinal。这就是为什么默认情况下已经存在“claim-persona”和“show-persona” RPC 端点的原因。

4.4.2 代码示例

我们通过组合使用“starter-game-template”和前面提到的“xoxo-phaserjs”来实现 Nakama 部分，连接 Nakama 到 Cardinal 的部分使用“starter-game-template”的现有实现，而连接 Nakama 到 Client 的部分默认使用前面提到的“xoxo-phaserjs”项目，并进行了一些修改。

要连接 Nakama 和 Cardinal，我们需要做的第一件事是允许新用户设置他们的 Persona Tag，因此我们从“starter-game-template”导入了“claimPersonaTag”函数。

我们还添加了逻辑，以便在当前没有玩家寻找比赛时创建新比赛，并且在已经有玩家寻找比赛时开始比赛。你还可以根据游戏的需求为此部分设置最小或最大玩家数。

最后，我们添加了一个“createPlayer”函数，以便客户端可以对“CreatePlayer”交易进行 RPC 调用，该交易会触发我们之前创建的新玩家的创建。

4.5 客户端

4.5.1 代码示例

我们的目标是让用户在页面上输入他们的姓名并按回车键时发生以下情况。

1. 验证用户

2. 将用户输入的姓名设置为 Persona Tag。

3. 使用“createPlayer”创建一个新实体。

4. 寻找比赛。

这是我们在代码中的实现方式：

5、结论

World Engine 背后的核心思想是拥有尽可能接近传统游戏服务器的体验和吞吐量，而不牺牲可组合性，而可组合性是区块链的最大优势。我们迫不及待地想看看 Argus 有哪些即将推出的游戏，并且希望 Scott 谈到的“为什么不构建 Onchain？”问题将在不久的将来被游戏开发者提出。

6、参考资料

• 使用 World Engine 构建复杂的实时链上游戏 - Scott Sunarto (Argus)

• ARGUS 介绍 WORLD ENGINE

• Scott Sunarto - 加密游戏、Argus Labs 以及基础设施与应用之争

• Intergame Thesis：链上游戏的终局 - Scott Sunarto

• Polaris 文档

• Berachain：Polaris EVM 框架 - Dev Bear

• Rollkit & Polaris Workshop

• World Engine 文档

• Starter game template

• Nakama JavaScript 客户端指南

感谢 Kate 为本文设计图形。

• 原文链接： 4pillars.io/en/articles/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～