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

原文标题：The future of on-chain gaming: ‘The promise of MUD ECS engine’

Web3的理念似乎与游戏行业和近年来的游戏化趋势完美契合。相当长一段时间以来，我们一直期待着一种新的颠覆性体验——链上游戏。去中心化的特性将权力平衡从游戏行业的现有人转移到创意实体，可组合性打破了长期封闭界限的壁垒，为玩家提供了真正的所有权。

但是，尽管有这些强大的理念，我们尚未在实践中看到它们。MUD是首次尝试为链上游戏创建完整框架的勇敢尝试，可能点燃新一代游戏的火花。这不是一厢情愿的。在其短暂的时期内，MUD团队负责开发了OPcraft——一个完全基于链上的3D Minecraft主题游戏。

传统游戏行业的经验教训

关于创新，从头开始构建一切，以及创建一个全新的实体的话题，可以说有很多可以探讨。但是就游戏而言，设计模式和新工程领域的教训已经积累了几十年之久，应该认真对待。忽视这些就等同于试图用Atari技术创建AAA游戏。

回顾游戏开发的早期岁月，我们可以看到传统游戏与链上游戏有着明显相似之处——有着大量的人才和极富启发性的项目，但也存在着缺乏协调和明确框架的问题。

在视频游戏的早期阶段以及游戏引擎出现之前，确立了一些信念和设计模式。不同的视频游戏几乎没有共同之处，甚至在某种程度上，相似的游戏可能有完全不同的代码库。但是随着游戏引擎的引入，一切都发生了变化。

很难准确地区分游戏引擎和游戏本身。一般来说，游戏引擎是具有一套规则和设计模式的框架，可以稍微修改和扩展以创建不同的游戏实现。在90年代，在经历了多年的碎片化游戏开发之后，一些基于流派的游戏引擎以及一些努力开发通用引擎的努力引领行业。像《毁灭战士》和《虚幻》这样的游戏，都有核心组件，可以被重复使用，以创建许多不同的游戏。相似类型的游戏开始共享许多核心逻辑实现。开发赛车、格斗和第一人称射击游戏的成本和复杂性大大降低。不可能变为可能，并且一代代游戏和升级的代码已经累积在一起。从软件角度来看，这是游戏开发成为巨大行业的主要原因之一。

链上游戏存在一些核心问题：

1. 缺乏框架：每个团队都试图从头开始构建一切，导致效率低下，缺乏系统知识，并无法利用构建者在解决相同问题及朝着最佳解决方案进行优化的经验。
2. 缺乏代码复用性：看看当今正在开发的许多链上游戏。其中有多少可以成功复制以创建略有不同的游戏？有多少游戏具有明确区分游戏不同层和组件的能力，使得可以构建具有类似代码库的新一代游戏？创建最大且相互连接的开源游戏项目的承诺似乎遥不可及。
3. 缺乏数据可组合性：问题不仅在于代码的可重用性，还包括链上游戏利用共享的区块链状态，在游戏B中使用游戏A的数据来相互构建。在实践中，将一个游戏的数据和逻辑合并到另一个游戏中需要大量的工作和资源。

MUD的解决方案：

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

智能合约中的ECS：

在MUD中，最基本的构建块是组件。它们是部署的合约，类似于数据库，用于存储有关实体的数据。例如，让我们来看一个实体（一个地址），比如玩家的钱包。这个由地址表示的实体可以具有不同的属性，比如在位置组件中的位置值（x，y），在等级组件中的等级10，在硬币组件中的50。组件仅由映射和基本配置组成。系统则更复杂，并实现了更改组件值的逻辑。你可以将这看作是系统在数据库（组件）上指定POST请求的API。它们只能在被授予对特定组件的写入访问权限时才能这样做。这变得有趣了。系统可以与不同的组件交互，以创建详细的逻辑。你可以有一个移动系统，指定玩家可以进行的有效移动（例如，每次移动两步），你还可以有一个奖励系统，每次玩家升级时都会给予他们硬币。所有这些都在“世界联系”（World contact）下注册，以便组件数据的每次更改都会引发一个事件。世界合约（World Contract）是无需权限的。任何人都可以添加新的系统和组件。理论上，不同的世界可以相互交互。将ECS引入到链上游戏中会产生一种非常优雅的结构，以至于OPcraft仅由10个组件和约15个系统组成。你可以在MUD.dev上查看这篇出色的博文。

真正的可组合性

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

1. 游戏部署的可升级性
2. 最高程度的可组合性

想象一下两条路径。一条是保留基本设计。另一条是改变核心游戏逻辑。

考虑一个标准的PVP策略游戏，玩家可以建立军队互相对战。基本版本是2D的，但现在团队决定他们想要创建一个详细的3D渲染的游戏。他们所需要做的就是取出所有与位置相关的系统，并创建升级版本，使用(x，y，z)坐标代替(x，y)。所有其他系统和组件（如攻击系统、HP和建造军队）都可以保持不变。它甚至超越了最初的开发团队，社区可以通过重新部署系统和组件或甚至授予新系统写入访问权限（如果它是社区所有的游戏，可以应用不同的治理模型来做出这些决定）来创建游戏的不同模式。

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

客户端整体视角：

请注意，MUD 是一个正在进行的项目。下一部分可能不是最新的，并且包含一些不准确和粗略的区别，但总体架构预计不会发生巨大变化。

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

1. 客户端可组合性
2. 客户端与区块链状态变化（游戏数据）完全同步
3. PhaserX作为渲染层

让我们深入研究技术细节，从而更加具体地展现它。

网络层：

网络层是客户端的基础层。它包含基本配置（世界合约、游戏和网络配置）和游戏交互的 API。创建网络层时，它具有您的客户端能够与之交互的所有不同组件和系统的规范，并且您可以选择仅与特定组件/系统进行交互。例如，如果您希望在游戏中创建运动并在前端为其提供表示，则需要创建一个与位置组件部署的智能合约以及运动系统同步的网络层。现在，您可以创建一个 Move API，它采用一个位置和一些游戏对象（实体）并设置其位置或将其从一个地方移动到另一个地方。任何时候玩家都会使用 Move API。他们将向区块链提交交易。就运动系统而言，他们将执行运动系统智能合约中的功能。

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

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

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

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

渲染层 -何时以及如何渲染事件

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

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

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

声明：

1. 本文转载自[mirror]，原文标题《The future of on-chain gaming: ‘The promise of MUD ECS engine》，著作权归属原作者[Matchbox DAO]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.com的情况下不得复制、传播或抄袭经翻译文章。