全链游戏的未来：“MUD ECS 引擎的承诺”

Web3 的理念似乎与游戏行业和近年来的游戏化趋势完美契合。相当长一段时间以来，我们一直被承诺以一种独特的体验：链上游戏的形式带来新的颠覆。去中心化等特性将权力平衡从游戏行业的现有者，更多地转向创意实体，可组合性打破了长期封闭的花园的围墙，以及玩家真正的所有权。但这些强大的理想仍然被搁置一边，因为我们尚未在实践中看到它们。MUD 是第一次勇敢的尝试，为链上游戏创建一个完整的框架，这可能会点燃下一代游戏的火花。

传统游戏行业的教训

关于创新、从头开始构建一切以及创造全新生物的痴迷有很多，但就游戏而言，设计模式和新工程利基创建方面有数十年的经验教训，值得被认真对待，忽略这些就相当于尝试使用 Atari 技术创建 AAA 游戏。

当回顾游戏开发的早期阶段时，我们可以看到与链上游戏明显的相似之处：大量的人才和高度鼓舞人心的项目，但缺乏协调和清晰的框架。

在视频游戏早期，在游戏引擎诞生之前，就已经确立了信念和设计模式。不同的视频游戏几乎没有共同点，在某种程度上，类似的游戏可能有完全不同的代码库。但随着游戏引擎的引入，一切都改变了。

很难在游戏引擎和游戏本身之间建立明确的区别。一般来说，游戏引擎是具有一组规则和设计模式的框架，可以稍微修改和扩展以创建不同的游戏实现。到了上世纪 90 年代，经过多年的碎片化游戏开发，情况发生了变化，“基于类型”的游戏引擎和一些开发通用引擎的努力占据了主导地位。《Doom》和《Unreal》等游戏的核心组件，可以重复用于创建许多不同的游戏，相似类型的游戏开始共享许多核心逻辑植入。开发赛车、格斗和第一人称射击游戏的成本和复杂性呈数量级下降。不可能变成了可能，一代又一代的游戏和升级的代码不断累积。从软件的角度来看，这是游戏开发成为一个巨大产业的主要原因之一。

链上游戏存在几个核心问题：

1. 缺乏框架：每个团队都试图从头开始构建一切，导致效率低下，并且缺乏构建者处理相同问题，并优化最佳解决方案的经验汇总和系统知识。

2. 缺乏代码可重用性：以当今前在开发的许多链上游戏为例，其中有多少可以成功复制并创造出略有不同的游戏？有多少在游戏的不同层和组件之间有明确的区别，从而允许使用类似的代码库构建更新一代的游戏？创建最重要且相互关联的游戏开源项目的承诺似乎还很遥远。

3. 缺乏数据可组合性：它并不以代码可重用性结束，它还涉及链上游戏利用共享区块链状态，使用游戏 A 和游戏 B 中的数据相互构建的能力。在实践中，需要花费大量的工作和资源来整合游戏 A 的数据和逻辑，一场比赛变成另一场比赛。

MUD 的解决方案：

MUD 是第一个勇敢的尝试，通过提供可维护性、可升级性和可成型性的结构，作为链上游戏创建引擎和框架。MUD 倡导的实体组件系统（ECS）模式，对于一般游戏开发有意义，对于链上游戏开发更有意义。

智能合约中的 ECS：

MUD 中最基本的构建块是组件（Components），它们以智能合约形式存在，其功能类似于存储实体（Entity）数据的数据库。例如，我们有一个实体（以太坊地址），例如玩家的钱包地址。该地址表示的实体可以具有不同的属性，例如：位置组件中的位置(x,y)、级别组件中的级别10，以及代币组件中的数值 50，组件（Components）仅包含映射和基本配置。

系统（Systems）更加复杂，并且实现了改变组件（Components）值的逻辑。你可以将其视为系统（Systems）指定数据库（组件）上的 POST 请求 API。只有获得对特定组件（Components）的写入权限，他们才能向该组件写入数据，这里就变得有趣了。系统（Systems）可以与不同的组件交互以创建详细的逻辑。你可以有一个移动系统，指定玩家可以进行的有效移动（例如：每次移动两步），你也可以有一个奖励系统，每次玩家升级时都会给他们金币。

所有这些都在世界合约（World contact）中注册，以便组件数据的每次更改都会发出一个事件。世界合约是无需许可的，任何人都可以添加新的系统和组件。理论上，不同的世界合约可以相互作用。

将 ECS 引入链上游戏会产生非常优雅的结构，使得 OPcraft 仅由 10 个组件和大约 15 个系统组成。

真正的可组合性

ECS 系统不仅在传统游戏开发中具有完美的意义，在链上游戏中更是如此，因为它提供了两个重要的功能：

1. 已部署游戏的可升级性

2. 最高程度的可组合性

想象两条路径：一是保留基础设计，另一个是改变核心游戏逻辑。

想象一下标准的 PVP 策略游戏，玩家可以组建军队互相战斗。基础版本是 2D，但现在团队决定为游戏创建 3D 渲染。他们所需要做的就是获取所有与位置相关的系统（Systems），并使用 (x,y,z) 坐标而不是 (x,y) 创建升级版本。所有其他系统（Systems）和组件（如：攻击系统、生命值和军队建筑）可以保持不变。它甚至超越了最初开发团队的范围，社区可以通过重新部署系统和组件，来创建游戏的不同模组（Mod），甚至可以通过授予对新系统（Systems）的写入权限，来与相同的组件进行交互（如果是社区拥有的游戏，可以使用各种治理模型来表决此类决定）。

另一种方法保留相同的组件和系统，不给予新系统写入访问权限，而是通过添加组件（Components）和系统（Systems）来扩展游戏内的功能，它会是什么样子？考虑一个基本的链上国际象棋游戏，动作和规则系统已经部署。人们可以像玩现实生活中的国际象棋一样玩游戏，但也许你的团队决定创建一个额外的层：一个包含用于匹配或任何其他用例的评级系统的社交层。你需要做的就是添加一个评级组件（Component）和一个具有评级规则的系统（System）。这不仅可以非常无缝地使用户迁移到新的游戏版本（更好的用户体验），而且还为不同版本在智能合约层面并存或相互叠加创造了技术手段。玩家可以在不同的游戏版本上玩，同时与相同的核心组件的数据进行交互，这除了可组合性应用程序之外，也是非常创新的。它创造了选择加入不变性的功能，创造了链上游戏提供的另一个所有权维度。不同游戏资产（如分数、NFT、成就）的真正所有权由不可变的逻辑保护，这些逻辑可以通过额外的升级进行扩展，但其核心不会改变。它解决了 Web3 游戏的主要问题之一，即创作者可以在未经同意的情况下削弱资产的能力。

客户端整体视角：

请注意，MUD 是一个正在进行的项目。下一部分可能不是最新的，并且可能有一些不准确的描述，但总体架构应该不会发生巨大变化。

目前为止，我们已经研究了智能合约层面的 MUD。但还有更多，MUD 提供了一整套包含客户端库和层的套件， MUD 的设计有一些独特的功能。

1. 客户端可组合性

2. 客户端与区块链状态变化（游戏数据）完全同步

3. PhaserX 作为渲染层

让我们深入研究技术细节，使其更加具体。

网络层：

网络层是客户端的基础层。它包含基本配置（World 合约、游戏和网络配置）和游戏交互的 API。创建网络层时，它具有你的客户端能够与之交互的，所有不同组件和系统的规范，并且你可以选择仅与特定组件/系统进行交互。

例如，如果你希望在游戏中创建运动，并在前端对其进行表示，则需要创建一个与位置组件部署的智能合约，以及运动系统同步的网络层。现在你可以创建一个 Move API，它作用于一个位置和一些游戏内对象（实体），并设置其位置或将其从一个地方移动到另一个地方。任何时候玩家都可以使用 Move API，他们将向区块链提交交易。对运动系统而言，他们将执行运动系统智能合约中的功能。

这种结构允许基于多客户端的游戏。每个人都可以创建独特的客户端，只要与区块链同步并遵循网络层基础结构，所有客户端都同等有效。我们已经看到了非常酷的多客户端游戏用例，例如在黑暗森林中，玩家相互竞争但使用不同的客户端和插件。客户端的结构允许我们在网络层植入，并修改API以非常快速地获得不同的客户端版本，实现高水平的客户端可塑性和可组合性。

你可能会问客户端组件如何与链组件同步。这是开发者在处理链上游戏客户端时面临的重大挑战之一，MUD 有一些解决方案。

首先，MUD 引入了快照功能，使客户端与 World 状态（即组件的实体值）同步，而无需处理所有过去的事件来重建状态，从而降低延迟并降低复杂性。

此外，MUD 的 ID 系统，其中每个系统（System）和组件（Component）都会根据其名称获得一个 id，并且在部署时，它们会在 World 合约中注册，从而更容易跟踪更改、与游戏交互。

渲染层：Event 何时以及如何渲染

MUD 附带 PhaserX，“构建在 Phaser 之上的高度可扩展的引擎”，PhaserX 不是必选的。在 OPcraft 中，用的是 Noa 体素引擎，而不是 PhaserX。理论上，你可以使用任何引擎，只要它遵循结构即可。

如前所述，每个组件和系统都在 World 合约上注册，当发生更改时，将发出一个事件（带有组件 ID 和实体 ID 等标识数据）。这里 ECS 流服务可以为客户端提供选择订阅哪些事件的选项。

实体的图形表示可以是你想要的任何形式。格斗游戏可以有动漫人物、骑士，甚至是你最喜欢的加密领域 KOL。只要它们代表链上事件并对链上事件做出反应，它们都是有效的版本。

原文链接：https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY