原文我发表在 PANEWS 上面。
传统游戏引擎#
游戏引擎是一种用于开发和创建电子游戏的软件框架。它包括了游戏开发所需的许多核心功能，对于传统的 Web2 游戏来说，一般包含如渲染引擎、音频处理、物理模拟和动画系统等。通过使用游戏引擎，开发者能够专注于游戏设计和创意，而无需从头开始构建整个技术基础设施。游戏引擎为游戏开发者提供了一个快速有效的工具，以降低开发成本和时间。
有许多知名的 Web2 游戏引擎，如 Unity、Unreal Engine 和 Godot 等。这些引擎不仅适用于专业开发者，也适用于独立开发者和初学者。游戏引擎具有高度可定制性，可以根据项目需求进行调整。它们通常支持跨平台开发，允许开发者为多种设备（如个人计算机、游戏机和移动设备等）创建游戏。此外，许多引擎还提供了对虚拟现实（VR）和增强现实（AR）的支持，以满足不断发展的技术需求。游戏引擎还包含了一套丰富的工具集，可以帮助开发者轻松地创建游戏世界、角色和物品。这些工具有助于实现高效的游戏开发流程，例如可视化的场景编辑器、脚本编辑器以及动画和特效工具等。
全链游戏引擎#
游戏引擎在游戏开发中发挥着至关重要的作用。对于全链上游戏来说，同样需要一个能够帮助开发者快速部署游戏逻辑的工具。这不仅能够缩短开发周期，还为后续的迭代开发和开放生态中的互操作提供了统一的数据标准。
在这个领域中，较为成熟的项目是由 Lattice 工作室开发的基于 Solidity 的全链游戏引擎 MUD。它使开发者能够迅速将游戏逻辑部署到智能合约中，并实现合约与客户端状态的同步等功能，从而显著提高开发效率。
值得注意的是，目前全链上游戏除了采用 Solidity 编写外，StarkNet 的 Cairo 也是一种常用的语言。然而，MUD 并不能很好地兼容 Cairo。因此，StarkNet 生态中的两个活跃项目 Realms 和 Briq 的创始人共同开发了基于 Cairo 的全链上引擎 Dojo。由于 Dojo 的核心理念与 MUD 相似，引发了 MUD 创始人 Ludens 的不满。但在一番争议之后，Ludens 最终表示愿意协助将 MUD 部署到 StarkNet 上。
ECS 架构#
开发游戏引擎时遇到的最大问题是如何表示游戏对象，游戏对象可以从没有控制或交互的简单 2D 图像到具有控制、声音、动画和 AI 的异常复杂 3D 对象。在概念上，很容易将游戏对象理解为表示游戏中具有多个功能的实体。最开始使用面向对象变成 OOP 的架构，现在更为流行的是 ECS 架构（Entity Component System）。
ECS 通过将逻辑、数据和实体分离，提高了游戏开发的灵活性和可维护性。这种架构模式有助于降低代码复杂度，减少耦合，从而提升性能和开发效率。ECS 由以下三个主要部分组成：
- 实体（Entity）：实体是游戏世界中的基本对象，如角色、道具或场景物体等。实体本身并不包含任何数据或逻辑，而只是一个唯一标识符，用于关联组件和系统。
- 组件（Component）：组件用于存储实体的属性和数据。每个组件负责表示一个特定的特征或功能，例如位置、速度或生命值等。组件只包含数据，不包含任何逻辑。通过将不同的组件组合在一起，可以轻松地创建具有各种功能和特性的实体。
- 系统（System）：系统负责处理游戏逻辑和行为。系统根据实体所拥有的组件来执行相应的操作。例如，一个处理移动的系统会查找具有位置和速度组件的实体，并根据其速度更新位置。系统独立于实体和组件，使得游戏逻辑更加模块化和可复用。
ECS 模式有助于解决传统面向对象编程（OOP）在游戏开发中的一些问题，如继承层次过深和代码重用困难等。ECS 使得游戏对象的构建更加灵活，可以通过组合不同的组件轻松创建出复杂的行为。此外，ECS 还有助于优化性能，特别是在处理大量游戏对象时。许多现代游戏引擎，如 Unity 和 Godot，已经采用了 ECS 作为其核心架构。
全链游戏和 Web2 游戏甚至常见的 GameFi 游戏（游戏资产上链但游戏本身不上链）有很大不同，比如，编程语言多采用 Solidity，游戏对象的属性状态储存在智能合约中，这就导致面向对象编程完全无法使用，只能采用 ECS 架构。
我们来看 Solidity，其实已经在不知不觉中使用过这种模式的变体。以 ERC-20 合约为例：ERC-20 合约将每个地址的代币余额存储在一个映射中（从 address 到 uint256 余额）。我们可以将每个 ERC-20 合约视为一个具有两列的表："地址" 和 "余额"。这对应于具有单个模式值（"余额"）的组件。表中的每行都将一个实体（"地址"）与一个组件值（"余额"）关联起来。一个地址可以在许多独立的 ERC-20 合约中持有余额，这对应于一个实体与许多独立的组件值关联。在当前的 ERC-20 参考实现中，状态和逻辑是耦合在同一个合约中的。在 ECS 中，我们将有一个通用的 "转账系统" 来处理从一个地址向另一个地址转账代币的逻辑，通过修改代币组件中存储的状态。
另一个例子是一个简单的视频游戏，可用的组件有 "位置" 和 "生命值"。具有位置的实体在位置组件中有一个条目，具有生命值的实体在生命值组件中有一个条目。"移动系统" 可以实现将实体从一个位置移动到另一个位置的规则。"战斗系统" 可以根据涉及实体位置的规则实现战斗逻辑，并修改实体的生命值。
MUD 游戏引擎#
MUD 是一个以太坊应用程序框架。其核心是一组合约接口和使用它们的约定。这些核心接口和库使得一系列周边工具、集成和库能够更加顺畅地进行，从而使链上应用程序的开发变得更加简洁。
MUD 可以实现如下功能
目前
- 在合约和客户端之间进行状态同步，无需定制网络代码
- 通用索引器（无需定制索引代码）
- 无缝合约升级（+ 开发过程中的自动合约升级）
- 合约共享状态
- Optimistic 更新
- 合约和系统的自动生成类型
- 与合约状态进行交互的查询语言
- 用于检查和修改合约和本地状态的数据浏览器
- 位打包实用工具
未来
- 本地模拟事务（包括 Optimistic 状态）
- 内置支持账户抽象化
- 合约包管理器
MUD 的框架包含 8 个库文件。
- SOLECS 是 MUD 的核心 Solidity 库，包含了链上组件、系统等的接口和参考实现。由于所有状态都存储在组件中，并且所有状态更新都在中心 World 合约中注册，MUD 可以提供开箱即用的网络逻辑，以实现合约和客户端状态的同步。
- RECS 是用 TypeScript 实现的一种响应式 ECS 库。它可以独立于任何链上组件使用，但也可以与 SOLECS 共同使用，以便在客户端上以相同格式镜像链上状态。
- Services 包含了使用上述方法同步链上状态的通用索引器。
- Network 是智能合约和节点做状态同步的库。
基于 StarkNet 的 Dojo 在功能上和 MUD 非常类似，甚至可以认为是用 Cairo 语言把 MUD 重新写了一遍，所以不再具体讲解。在 MUD 的开发者文档中给出了一个具体的例子来教会大家如何在一天时间就能开发出一个全链游戏：Emojimon（表情怪兽）。感兴趣的朋友可以参考这篇官方教程：https://mud.dev/tutorials/emojimon/
基于 MUD 开发的游戏#
Sky Strife
Sky Strife 是一个基于 MUD 构建的链上游戏。游戏以快节奏的实时战略（RTS）战斗为特点，展开一场争夺谁能带着 “Ember Crown” 逃离战场的激战。
Kamigotchi
Kamigotchi 是一款具有 PvP 机制的多人在线角色扮演闲置游戏。您可以使用您的 Kamigotchi（简称 “Kami”）从世界各地散布的节点中收获 $KAMI。$KAMI 可用于升级您的 Kami 并购买食物。然而，收获会消耗您的 Kami 的生命值，当生命值较低时，其他玩家可以使用他们的 Kami 猎杀您的 Kami。您需要保持您的 Kami 充饥并仔细观察它们以获得最大产出。死亡并不是永久的，核心 NFT 不受影响，但这会让您付出代价 —— 被杀死的 Kami 在游戏中无法再次使用，除非使用商店中的某些消耗品复活，当然这需要 $KAMI。此外，您的 Kami 会因为这次经历而心情受挫。
Muddy Forest
Muddy Forest 是一款完全基于链上的大型多人在线实时战略太空征服游戏，游戏中的每个动作，从运输、发送资源到占领星球等，都发生在区块链上。