🚀前言

在游戏开发的世界中，跑酷游戏因其快节奏和极具挑战性的玩法而广受欢迎。然而，设计一个成功的跑酷游戏不仅仅依赖于创意的关卡和角色，还需要一个稳健的游戏架构来支撑整个项目的顺利进行。随着人工智能技术的进步，AI正日益成为游戏架构设计中的关键助手，帮助开发者构建更高效、灵活且可扩展的游戏系统。

本文将深入探讨AI如何辅助跑酷游戏的架构设计，包括数据管理、模块化设计、实时性能监测等方面。我们将分享一些实际案例，展示AI在优化架构决策、提升开发效率以及改善游戏性能方面的显著作用。无论你是游戏开发的初学者，还是希望提升项目管理能力的资深开发者，这篇文章都将为你提供实用的见解和方法。让我们一起探索AI在跑酷游戏架构设计中的无限可能，共同打造更流畅、稳定的游戏体验！

🚀一、游戏架构设计

作为一名程序员，我对架构设计这一环节充满期待。尽管我使用的是 ChatGPT 3.5 版本，只能生成文本和代码，但它已经能够生成 PlantUML 作图语言代码，通过相应的语言解析器就可以产出架构图。

我让 ChatGPT “扮演一个架构师，回答中所有的架构图都用 PlantUML 描述”，ChatGPT 随即在回答中提供了架构图的 PlantUML 代码描述。我只需将这些 PlantUML 代码粘贴到 PlantUML 解析器中，即可得到架构图。我使用的 PlantUML 解析器是 plantuml.com 官网，此外，一般的 IDE 插件市场以及许多笔记类软件（如语雀）也集成了 PlantUML 的解析器功能。

以下所有关于架构图的对话都基于“你的身份是一个架构师，回答中所有的架构图都用 PlantUML 描述”这一预设。为了方便阅读，我将 PlantUML 代码部分转换成可视化的架构图。

🔎1.架构选型

我要实现一个跑酷游戏，我可以采用哪些架构模式?

在实现跑酷游戏时，可以考虑采用以下几种常见的架构模式来组织代码，提升可维护性、可扩展性和可测试性：

### 1. **MVC（Model-View-Controller）模式**
   - **概述：** MVC 将游戏的逻辑（Model）、用户界面（View）和控制逻辑（Controller）分离。
   - **应用场景：** 当你需要确保游戏逻辑与显示逻辑的分离时，MVC 是一个非常有效的架构。可以使你的代码更加模块化，便于修改和扩展。
   - **示例应用：**
     - **Model:** 存储玩家数据、分数、游戏状态等。
     - **View:** 处理图形界面和动画效果。
     - **Controller:** 接收玩家输入（如跳跃、滑动），控制游戏的运行逻辑和规则。

### 2. **ECS（Entity-Component-System）模式**
   - **概述：** ECS 是一种常用于游戏开发的架构模式，将实体（Entity）与它们的属性（Component）和行为（System）分离。
   - **应用场景：** 对于有大量可复用游戏对象的跑酷游戏（如角色、障碍物、道具），ECS 能简化对象管理和行为的复用。
   - **示例应用：**
     - **Entity:** 玩家角色、障碍物、鬼火等。
     - **Component:** 组件如“位置”、“速度”、“碰撞体积”等。
     - **System:** 管理物理计算、碰撞检测、渲染等。

### 3. **Event-Driven（事件驱动）模式**
   - **概述：** 通过事件来解耦系统中的各个模块，触发特定事件时相关模块做出响应。
   - **应用场景：** 当你的游戏中有很多状态变化需要通知各个子系统（如道具拾取、碰撞检测、得分变化）时，可以使用事件驱动架构。
   - **示例应用：**
     - 当玩家收集蓝水晶时，触发“得分增加”事件。
     - 当碰到障碍物或被鬼火追上时，触发“游戏结束”事件。

### 4. **State Machine（状态机）模式**
   - **概述：** 游戏中的角色、物体会在不同的状态间转换，状态机模式帮助管理这些状态和转换逻辑。
   - **应用场景：** 适合管理游戏的不同阶段（如菜单、游戏运行中、暂停、结束）、角色状态（跑、跳、滑）或敌人的行为逻辑（鬼火的追踪模式）。
   - **示例应用：**
     - 玩家角色在跑酷中的状态转换：跑步 -> 跳跃 -> 滑行 -> 被击败。

### 5. **Singleton（单例模式）**
   - **概述：** 确保一个类在全局只有一个实例，并提供全局访问点。
   - **应用场景：** 适用于需要全局唯一且共享的资源管理（如音效管理器、游戏设置、关卡管理器等）。
   - **示例应用：**
     - **音效管理器：** 控制游戏中所有的音效和背景音乐。
     - **关卡管理器：** 管理关卡逻辑、地图生成等。

### 6. **Observer（观察者模式）**
   - **概述：** 观察者模式允许对象订阅其他对象的状态变化，当被观察的对象状态发生变化时通知所有订阅者。
   - **应用场景：** 可以用在跑酷游戏中，当游戏状态变化时（如玩家死亡、得分增加）通知其他模块。
   - **示例应用：**
     - 当玩家状态发生变化时，UI 自动更新得分或游戏状态。

### 7. **Component-Based（基于组件）模式**
   - **概述：** 将游戏中的各个功能分为多个组件，每个组件独立负责一项功能，并可以通过组合形成复杂的对象。
   - **应用场景：** 对于对象行为多变的游戏，采用组件化设计可以极大增强代码的灵活性和可维护性。
   - **示例应用：**
     - 一个玩家角色可能拥有“运动组件”、“动画组件”、“碰撞组件”等。

### 8. **Command（命令模式）**
   - **概述：** 将动作或操作封装成命令对象，以便进行更灵活的调用、撤销、存储和组合。
   - **应用场景：** 在处理玩家输入和操作时，命令模式可以帮助你记录操作、执行撤销等功能。
   - **示例应用：**
     - 玩家控制的“跳跃”命令和“滑动”命令可以通过此模式来实现，并且方便添加撤销或重复执行功能。

### 9. **Prototype（原型模式）**
   - **概述：** 使用原型模式可以通过复制已有对象来创建新的对象，而不是直接实例化类。
   - **应用场景：** 在需要大量生成同类型对象的场景中非常有效，比如障碍物、道具、敌人等重复性较高的对象。
   - **示例应用：**
     - 通过复制一个障碍物原型来生成多个障碍物实例，减少生成开销。

### 10. **Service Locator（服务定位器模式）**
   - **概述：** 使用服务定位器来解决全局服务依赖问题，将所有服务注册在一起，方便获取。
   - **应用场景：** 游戏中的全局服务（如音效、网络连接、数据保存）可以通过服务定位器来管理和提供统一访问接口。
   - **示例应用：**
     - 在任何地方调用游戏音效、数据保存等服务时，通过服务定位器统一获取服务实例。

### 总结
- **MVC** 或 **ECS** 适合构建清晰的代码结构和模块化管理。
- **Event-Driven** 或 **Observer** 模式适合处理复杂的事件触发和响应机制。
- **State Machine** 和 **Command** 模式适合管理游戏中的状态和操作逻辑。

你可以根据游戏的复杂度和需要的功能，组合使用多个架构模式来构建一个高效、可扩展的跑酷游戏架构。

🦋1.1 GameManager 集中管理

首先我让 ChatGPT帮我生成了一个简单的GameManager 管理类，直接关联和引用其他游戏实体，类图如图所示。

🦋1.2 使用消息机制解耦

可以用事件去做解耦吗?画出架构图并告诉我两种模式之间的差异。

在直接调用子类的方法时，子类之间存在强耦合关系，这会增加代码的复杂度和维护成本。当子类之间存在复杂的依赖关系时，修改其中一个子类可能会影响其他子类的实现，从而导致代码的脆弱性增加。

如图所示，使用事件通信可以削弱子类之间的依赖关系，使它们之间更加松散，从而提高代码的可维护性和可扩展性。事件通信的实现不依赖于具体的子类，而是依赖于定义的事件。不同的子类可以通过注册和触发相同的事件来实现通信。

此外，事件通信还使得代码更容易进行单元测试。由于每个子类相互独立，可以更方便地进行单元测试，而无需考虑其他子类的影响。这是事件通信的一个重要优点。

最后，需要注意的是，在某些情况下，直接调用子类的方法可能更加简洁和高效。例如，当子类之间的依赖关系非常简单，或者需要高频率的通信时，使用事件通信可能会增加代码的复杂度和运行时开销。因此，在使用事件通信与直接调用子类方法之间需要进行权衡和选择。

在基于事件通信的架构下，需要事件管理中心吗?需要的话，请你补充上去。

是的，在基于事件通信的架构中，需要一个事件管理中心来协调不同模块之间的通信。事件管理中心负责注册、存储和分发事件，模块之间通过该中心进行通信。事件管理中心通常包含以下功能：

1. **事件注册**：模块可以向事件管理中心注册自己感兴趣的事件，并提供处理该事件的回调函数。
2. **事件存储**：事件管理中心将所有注册的事件存储在内部数据结构中，以便于管理和分发。
3. **事件分发**：当某个事件发生时，事件管理中心会遍历所有已注册该事件的模块，并依次调用它们提供的回调函数来处理事件。
4. **事件过滤**：事件管理中心可以支持事件过滤功能，仅分发符合特定条件的事件给模块，从而提高分发的效率和精度。

事件管理中心通常是一个全局单例对象，能够被整个系统中的模块访问和使用。在实现事件管理中心时，可以采用观察者模式、发布-订阅模式等技术。下图展示了基于事件通信的架构图，其中包含了事件管理中心。

🦋1.3 消息中心和 Actor 模式的差异

基于事件通信的架构和 Actor 模式有差异吗?

基于事件通信的架构与 Actor 模式虽然有一定相似之处，但并不完全等同。Actor 模式中的 Actor 是并发的个体，每个 Actor 
拥有自己的状态和行为，并可以通过消息传递与其他 Actor 进行交互。而在事件通信模式中，组件是相互独立的，它们之间通过事
件来传递消息，实现任务的协作。因此，尽管事件通信模式与 Actor 模式都采用了消息传递机制，但它们的目的和实现方式存在显
著差异。Actor 模式的示意图见下图。

🦋1.4 MVC 模式

直接调用子类方法的架构和MVC有区别吗?我看到有一个GameManager 类，实现了数据共享和处理。

直接调用子类方法的架构与 MVC 架构有一定相似之处，但存在重要区别。架构图如下：

在 MVC 架构中，游戏被划分为三个主要组件：模型（Model）、视图（View）和控制器（Controller）。模型代表游戏的数据和状态，视图负责渲染游戏界面，而控制器处理用户输入并更新游戏状态。这三个组件之间通过特定的接口和规则进行通信与协作。

而在直接调用子类方法的架构中，游戏通常由一个 GameManager 类来管理整个游戏的状态和逻辑。GameManager 类直接调用各个子类的方法来控制游戏行为。在这种架构中，游戏以层次化方式组织，每个组件代表游戏中的一个子系统或模块。与 MVC 架构相比，这种架构更加简单直接，通常适用于小型游戏或原型开发。

GameManager 类通常包含游戏的数据和状态，并负责协调各个子系统之间的协作和通信。因此，GameManager 类类似于 MVC 架构中的控制器，但其职责更加广泛，同时包含了模型和视图的部分职责。

总的来说，直接调用子类方法的架构相比 MVC 架构更加简单，但也更不灵活。对于较复杂的游戏而言，MVC 架构通常更为适合，因为它能够更清晰地划分游戏各个组件，并通过接口和规则实现组件之间的协作与通信。

你为什么把 DataModel 和 Model 分开?

在 MVC 架构中，Model 表示应用程序使用的数据和业务逻辑，而 DataModel 是 Model 的一种特殊形式，专注于数据的存储和处理。在某些情况下，Model 还可能包含其他业务逻辑，例如计算和数据验证。

DataModel 通常与数据库或其他数据存储介质相关联，负责将存储在数据库中的数据转换为应用程序可理解的形式。而 Model 则更加关注业务逻辑的实现，如数据的计算、验证和转换等。因此，将 DataModel 与 Model 分开，可以更清晰地表达数据与业务逻辑之间的区别，同时也便于维护和修改应用程序。

🔎2.模块功能细分

因为本次游戏的玩法简单，只包含较少的实体，我最终选择gameManager的管理类来组很游戏逻辑。接下来，我让 ChatGPT 细化一下其他模块。

我要实现一个跑酷游戏，有 player、background、play button、coin 几个模块，以及一个gameManager 控制器，帮我输出架构图。

希望以下架构图能帮助你开发一个完整的跑酷游戏：

1. **GameManager（游戏控制器）**：负责管理游戏流程，包括开始游戏、结束游戏、分数统计等功能，同时控制游戏菜单界面和游戏界面的显示与隐藏。
   
2. **MainMenu（菜单界面）**：负责显示游戏的主菜单，包括开始游戏按钮等。

3. **GameUI（游戏界面）**：负责显示游戏的 UI 元素，包括分数和游戏结束界面等。

4. **Player（玩家）**：处理玩家的操作，包括跳跃、滑行和死亡等。

5. **Background（背景）**：控制游戏背景的滚动。

6. **Coin（金钱）**：负责生成和管理金币，包括生成、回收和收集等功能。

在游戏开始时，GameManager 会实例化 MainMenu 和 Player，并开启背景滚动和金币生成的功能。当玩家开始游戏时，GameManager 会隐藏 MainMenu，显示 GameUI，并将游戏状态设置为“进行中”。

当玩家死亡时，GameManager 会显示游戏结束界面，并将游戏状态设置为“结束”。玩家可以选择重新开始游戏或返回主菜单。

好的，请帮我细化 GameManager。

细化后的架构图如下：

1. **GameManager 类** 新增了两个属性：`score` 和 `gameState`，分别表示当前游戏的分数和游戏状态。`player`、`bg`、`coin`、`mainMenu`、`gameUI` 和 `gameOverMenu` 等对象都是 GameManager 类的属性，用于控制游戏中的玩家、背景、金币、菜单和游戏界面等元素。

2. **GameManager 类的方法** 包括：
   - `startGame`：开始游戏
   - `gameOver`：游戏结束
   - `increaseScore`：增加分数
   - `resetScore`：重置分数
   - `showMainMenu`：显示主菜单
   - `hideMainMenu`：隐藏主菜单
   - `showGameOverMenu`：显示游戏结束界面
   - `hideGameOverMenu`：隐藏游戏结束界面

如何同步 Player 和 Background 的速度?

为了实现 Player 和 Background 的速度同步，可以通过 GameManager 类来实现它们之间的通信：

1. **在 GameManager 类中** 添加一个名为 `gameSpeed` 的属性，用于存储当前游戏的速度，初始值设为 1。

2. **在 Background 类中** 添加一个名为 `setSpeed` 的方法，用于设置背景的滚动速度。该方法可以根据 GameManager 中的 `gameSpeed` 属性来调整背景的滚动速度。具体实现见下图。

3.在Player 类中，可以添加一个名为updateSpeed的方法，用于更新角色的速度。在该方法中，可以根据GameManager中的gameSpeed属性来设置角色的速度。

4.在GameManager类中，可以添加一个名为update的方法，用于每帧更新游戏状态，在该方法中，可以调用Background和Player的 updateSpeed 方法，以便更新它们的速度。

5.在GameManager类的setGameSpeed方法中，除了更新gameSpeed 属性的值之外，还需要调用 Background 和 Player 的 updateSpeed 方法，以便更新它们的速度。

🔎3.ChatGPT架构能力总结

通过与 ChatGPT 进行架构选型和模块能力设计等方面的交流，我基本确定了游戏的代码框架。这份技术方案为我评估研发的复杂度和工作量提供了良好的参考。在这个过程中，ChatGPT 展现出的专业性和高效输出能力让我感到惊艳。

长期以来，我负责团队内外包同事的面试工作，观察到很多同事缺乏对架构弹性和合理性的思考能力。这可能与国内小游戏行业项目周期快、复杂度低等因素有关，甚至一些有七八年工作经验的开发人员也存在此问题。

我们并不鼓励过度设计，但了解不同玩法类型和设计模式之间的差异，以及合理评估项目研发周期的能力是必要的。通过这次尝试，我们可以看到 ChatGPT 在这方面表现出色，是一个很好的辅助工具。