AISystem：鸿蒙游戏中的 AI 行为驱动

好的，没问题。作为一名在游戏开发领域摸爬滚打多年的老手，我来帮你把这个关于“鸿蒙游戏AI系统”的内容重新梳理一下，让它读起来更像是一个资深工程师的经验分享，而不是AI生成的模板文稿。 先说几个核心判断。当你在鸿蒙游戏里把架构拆成 `Store`、`System`、`Engine`、`UI` 这套东西后，处理玩家行为通常是顺滑的：点击按钮 → 触发System → 更新状态。但一旦你开始琢磨NPC行为、敌人决策、自动战斗、动态难度这些玩意儿，事情就变得棘手了。 很多人第一反应就是：嗨，这不就是一堆 `if-else` 吗？直接往 `BattleSystem` 里写，或者干脆塞进UI层的逻辑里。结果呢，用不了多久，代码就乱成了一锅粥，行为变得不可控，想加点新东西更是难上加难。所以，我们要解决的核心问题，就是如何优雅地引入“智能”。关键在于建立一套独立的、行之有效的决策系统。 **为什么不能把AI决策直接写进BattleSystem？** 看看这个典型的反面教材： ```typescript class BattleSystem { update(store: GameStore) { // 玩家逻辑 this.handlePlayer(store) // AI逻辑 if (store.enemyHp < 30) { this.escape() } else { this.attack() } } } ``` 问题非常明显：**规则（怎么计算伤害、处理冷却）和决策（什么时候攻击、什么时候逃跑）被硬生生搅合在一起了。** 这就好比你把厨房和餐厅混在一起，做饭和吃饭都在同一个地方，肯定会乱。这带来的直接后果就是AI逻辑无法复用，行为很难扩展，系统也变得脆弱。你改一个地方的决策，很可能就影响了另一个地方的规则。 **一个关键拆分：规则 vs. 决策** 你必须把这两件事彻底分开。游戏世界里，有两种截然不同的逻辑。 * **System（系统）：** 回答“**如何做**”的问题。攻击怎么计算？伤害怎么生效？冷却时间怎么处理？这些是游戏世界的铁律，是客观规则。 * **AISystem（AI系统）：** 回答“**做什么**”的问题。什么时候攻击？什么时候逃跑？选择哪个技能？这些是基于当前状态做出的主观判断，是智能决策。 一句话总结就是：系统决定世界怎么运转，AI决定角色怎么选择。 **AISystem的核心职责** AISystem的本分很明确，它有三不碰： * **不直接修改Store（状态）。** 它只读数据，不写数据。 * **不写具体的游戏规则。** 它不关心攻击力计算，也不管技能冷却。 * **不控制执行流程。** 它只负责给出一个“想法”（Action），具体怎么执行，那是System的事。 它唯一要做的一件事，就是**根据当前状态，输出一个行为指令。** **AISystem的最小模型** 一个最朴素的AISystem，其实就是一个决策函数： ```typescript export class AISystem { decide(store: GameStore): Action { if (store.enemyHp < 30) { return { type: "ESCAPE" } } return { type: "ATTACK" } } } ``` 然后，由另一个系统（比如 `BattleSystem`）来执行这个决策结果： ```typescript const action = ai.decide(store) battleSystem.execute(store, action) ``` **从“if-else”到“行为模型”** 初学者的写法是直接写死条件判断： ```typescript if (hp < 30) run() else attack() ``` 但进阶之后，你会希望将它构造成一个清晰的行为模型： 1. **行为枚举（ActionType）：** 定义游戏里所有可能的AI行为。 2. **行为选择器（Decide）：** 实现具体的决策逻辑，输出一个行为类型。 3. **行为执行器（Execute）：** 根据决策结果，调用具体的System规则来执行。 这样拆开的好处是立竿见影的：结构清晰，易于扩展（加个新行为只需改枚举和选择器），并且方便单独测试（可以只测试决策逻辑）。 **AISystem的三种进阶模式** 根据游戏的复杂度和需求，AISystem可以有不同的实现模式： 1. **规则驱动（Rule-Based）：** 最直接的方式，纯 `if-else`。简单可控，适合基础AI，比如小怪。 2. **权重驱动（Weighted Scoring）：** 给每个行为打分，选择分数最高的。比如攻击得0.7分，逃跑得0.9分，那AI就会选择逃跑。这种方式更灵活，能平滑地调节AI的倾向性。 3. **模型驱动（Model-Driven）：** 通过调用机器学习模型来做决策。最灵活、最智能，但也最不可预测，适合Boss或特殊NPC。 **AISystem与System的协作关系** 记住这个核心原则：**AISystem只决策，System只执行。** 错误的做法是： ```typescript // 错误：AI直接修改状态 ai.decide(store) // 内部直接 store.hp -= 10 ``` 正确的协作方式应该是： ```typescript const action = ai.decide(store) // AI输出 Action engine.dispatch(action) // 调度器分发 Action ``` **引入“行为调度层（AIEngine）”** 当游戏里有多个AI实体（比如多个敌人、队友）时，你不能简单地一个 `ai.decide()` 搞定。你需要一个统一的调度器： ```typescript class AIEngine { aiSystems: AISystem[] = [] run(store) { return this.aiSystems.map(ai => ai.decide(store)) } } ``` 这个调度层的作用很关键：统一所有AI的执行，支持多AI并行决策，并且让系统更容易组合和扩展。 **避免AI失控的关键机制** AI一旦复杂起来，就很容易“发疯”。你必须加上几层保护： 1. **约束：** AI不能无视硬性规则。比如角色被眩晕了，它就不能做任何事。 2. **校验：** AI决策出来的Action是否合法？比如角色MP不够，它就不能释放了一个需要消耗MP的技能。 3. **优先级：** 当AI同时想干好几件事时，必须有明确的优先级。比如逃跑永远比攻击重要。 **AISystem在多端中的作用** 在多人协同或跨设备同步的场景下，AI决策必须统一。如果每个设备各算各的AI，结果必然导致状态漂移。 正确的做法是：**在权威端（Host）运行AI，其他设备同步决策结果。** 这样可以保证所有玩家看到的游戏世界是一致的。 **一个关键认知升级** 初学者会觉得：`AI = 一段逻辑`。但当你真正理解了这个架构后，你会知道：**AI = 一个独立的决策层**，它是一个输入（状态） → 输出（行为）的函数。 整个游戏运行流程就变成了： ``` 状态（Store） ↓ AISystem（决策） ↓ Action System（执行） ↓ 状态变化（回到第一步） ``` **最终架构** 最后，一个理想的鸿蒙游戏AI架构应该像这样： * `Store`：存放所有游戏状态。 * `AIEngine` & `AISystem(s)`：负责从Store读取数据，并输出所有实体的Action列表。 * `System(s)`：接收Action，执行具体的游戏规则，并更新Store。 * `Engine`：负责整个流程的调度。 * `UI`：从Store读取数据，渲染画面。 **总结** 在鸿蒙游戏开发中，你需要清晰地划分两个角色： * `System`：**定义游戏世界的规则**。 * `AISystem`：**决定游戏角色的行为**。 两者缺一不可。当你能真正用好 `AISystem`，你的游戏就会从一个“写死的逻辑”进化为一个“拥有生命的系统”。这才是游戏变得真正有趣和复杂的关键所在。