游戏之所以需要 AI，本质上是为了让虚拟世界里的角色看起来有“智能”， 让玩家觉得“他们在思考”，从而增加沉浸感、挑战性和乐趣。
🎯 为什么游戏需要 AI？
| 目的 | 说明 |
|---|---|
| 制造挑战 | 让敌人会战斗、躲避、追击，增加对抗的乐趣 |
| 增强沉浸感 | 让NPC像真人一样说话、巡逻、吃饭、反应 |
| 节省成本 | 不可能让所有角色都由真人控制，AI 可以自动化行为 |
| 创造剧情/氛围 | AI 控制的角色可以推动剧情发展，或者制造环境氛围（如围观、逃跑等） |
🤖 游戏 AI 能做什么？
| 功能类型 | 示例 |
|---|---|
| 敌人行为 | 巡逻、警觉、追击、攻击、撤退等 |
| 角色控制 | 队友协作、自动寻路、选择技能等 |
| 生活模拟 | 村民按时间表上下班、聊天、购物 |
| 战术决策 | 决定是否攻击、防守、集结，RTS中常见 |
| 对话/情绪系统 | 简单的聊天逻辑，甚至配合 NLP 模拟更真实互动 |
| 群体行为 | 蜂群AI、群体移动、动态避障 |
| 任务执行 | 角色自动完成“去某地”“收集物品”等任务步骤 |
📌 一句话总结：
游戏 AI 是让 NPC 看起来“活着”的灵魂，让游戏世界有逻辑、有反馈、有惊喜。如果没有 AI，所有角色就像木偶，只会傻站着或重复动作，根本无法打动玩家。
🧱 没有 AI 时，你需要做的事（用“脚本/状态手写硬逻辑”补上）：
| 目标 | 替代方案 | 缺点 |
|---|---|---|
| 巡逻行为 | 写死路径，定时移动或随机方向 + 碰撞判断 | 没有感知能力，容易出BUG |
| 敌人攻击 | 碰到就打 or 距离小于X就攻击 | 不会判断形势，显得“蠢” |
| 队友跟随 | 始终跟主角一段距离，简单追踪 | 卡位、掉队、绕障碍差 |
| 剧情NPC互动 | 写死对话逻辑 + 时间表 + 脚本事件 | 没有状态判断，行为不连贯 |
| 逃跑/反应行为 | 如果生命<30%，向远离玩家方向移动 | 无环境评估，容易走火入魔 |
| 选择技能/战术 | 随机选或轮流用技能，或HP低用治疗 | 缺少上下文判断，看起来不聪明 |
🔄 你需要补的模块：
- 大量的状态/条件判断代码（手动实现“if…else…”）
- 写死行为逻辑树（每个 NPC 单独写行为流程）
- 人工调试每种情况的切换（异常容易错）
- 使用计时器、事件系统模仿“感知”和“选择”
- 更多维护成本（越复杂越难 debug）
📌 举个例子：
比如你想让敌人“看到玩家就追，追一段时间没追到就放弃”， 如果用 AI（比如行为树或状态机），只需要几条规则就能搞定。
但如果不用 AI，你得自己：
- 写“视野判定”
- 写“追击逻辑”
- 写“计时器”
- 写“回归原地逻辑”
- 然后处理各种奇怪的BUG：卡住、追出地图、不放弃等
时间成本会指数级增长，而且最终也不一定比“AI方式”更好维护。
✅ 结论：
没有AI也能实现复杂行为，但代价是“你得亲手写出每一步逻辑 + 状态切换”，而一套好的 AI 框架（哪怕是简化版）可以让你少写 80% 的代码、增加 300% 的表现力。
所以哪怕不是为“智能”，也建议用 AI 框架来管理行为——因为它就是“人类写行为逻辑的好工具”。
实现AI有哪些技术方案
现代游戏 AI 的实际应用非常多。 随着技术发展，尤其是机器学习的引入，游戏 AI 的设计方法已经越来越多样化。 下面是业界常见或主流的一些 AI 方法：
🎮 游戏 AI 主流方案对比总览
| 类型 | 名称 | 是否主流 | 简介 | 特点 |
|---|---|---|---|---|
| 传统规则系统 | FSM（有限状态机） | ✅ 基础常用 | 最基础的状态切换系统 | 简单、性能高，但不易扩展 |
| 行为树（BT） | ✅ 主流 | 类似逻辑树的结构，层级清晰 | 易扩展、调试方便 | |
| GOAP（目标导向动作规划） | ⚠️ 小众但强大 | 通过目标反推行为组合 | 灵活但性能压力大 | |
| HTN（层次任务网络） | ⚠️ 高复杂度系统用 | 预定义任务拆分 + 规划 | 结构清晰但设计成本高 |
🤖 现代/进阶 AI 方法
| 类型 | 名称 | 是否主流 | 简介 | 特点 |
|---|---|---|---|---|
| 学习型 AI | 行为克隆（Behavior Cloning） | ⛔ 少见 | 模拟人类玩家输入训练模型 | 简单但泛化差 |
| 强化学习（Reinforcement Learning） | ⛔ 研究多于实际用 | AI 自我试错学会策略 | 灵活但训练难度高 | |
| 模糊逻辑系统（Fuzzy Logic） | ⚠️ 一些老游戏用 | 状态不是0/1，而是连续的“程度” | 适用于模拟“情绪”等模糊概念 | |
| 决策树 + 表达式（Utility AI） | ✅ 越来越流行 | 用评分选择行为，如“哪个行为最有价值” | 类似 GOAP，但更易控、更快 | |
| 规划系统（PDDL/STRIPS） | ⛔ 理论性强 | 和 HTN/GOAP 类似的 AI 规划语言 | 重而慢，工业级用较多 |
🔍 近几年更火的 AI 实践方向
| 名称 | 描述 | 应用案例 |
|---|---|---|
| Utility AI（效用系统） | 每个行为定义“得分函数”，实时评估哪种行为当前最划算 | 《天际》、《上古卷轴Online》 |
| AI 编辑器+数据驱动 | 用可视化工具配置行为逻辑，避免代码写死 | UE 的 Behavior Tree Editor / Unity 的 AI Planner |
| 多层AI（Layered AI） | 高层策略 + 低层反应，比如高层决定目标，低层执行走位 | RTS、MOBA 游戏常用 |
| 基于黑板（Blackboard）系统 | 所有系统共享一个“黑板”记录当前世界/目标信息 | 与 BT、HTN 一起使用效果更好 |
✅ 主流选择建议（根据项目）
| 项目规模/类型 | 推荐方案 |
|---|---|
| 小型休闲游戏 | FSM / 简化行为树 |
| 中型动作/RPG | 行为树 + 黑板 / Utility AI |
| 大型战术/策略 | HTN / GOAP + 行为树混合 |
| 高度复杂 NPC | HTN / Utility AI / 多层结构 |
| 想要 AI 像人一样思考 | 强化学习 + 模拟对局训练（但门槛很高） |
🧠 总结一句话：
除了经典的状态机、行为树、GOAP、HTN，现代游戏 AI 越来越向 **“数据驱动 + 分层决策 + 可解释的行为评估”**方向发展，其中 Utility AI 是近年来非常受欢迎的折中方案。
聚焦实战中常用、工程落地成熟的游戏AI方法
✅ 常用游戏 AI 方法对比表（实战精选）
| 类别 | 名称 | 核心逻辑 | 优势 | 局限 | 推荐使用场景 |
|---|---|---|---|---|---|
| 🧱 基础型 | 有限状态机 FSM | 状态 + 明确切换条件 | 简单、性能好、可控 | 扩展困难，状态爆炸 | 巡逻、简单敌人、规则明确 |
| 🌲 结构型 | 行为树 Behavior Tree | 树状节点组织行为，条件分支控制流程 | 模块化、复用性强、调试方便 | 不擅长复杂计划或动态行为选择 | 中复杂AI，NPC交互、敌人战斗 |
| 📊 评估型 | Utility AI（效用系统） | 每个行为打分，选择分最高的执行 | 响应灵活、行为自然、可微调 | 缺少长序列规划能力 | 策略型敌人、动态响应单位、模拟日常角色 |
| 🧠 规划型 | GOAP（Goal Oriented Action Planning） | 根据目标反向规划行为序列 | 自主性强、智能感强 | 学习成本高、调试复杂 | RPG、模拟、潜行、沙盒类角色 |
🔁 可选配合系统：
| 名称 | 用途 | 常配合 |
|---|---|---|
| 黑板系统（Blackboard） | 共享状态信息（例如敌人、位置） | 行为树、GOAP |
| 感知系统（Perception） | 模拟视野、听觉、嗅觉 | 所有决策系统 |
🚫 移除的冷门/研究型：
| 被移除项 | 理由 |
|---|---|
| 模糊逻辑系统 | 调试复杂、已被 Utility AI 吸收替代 |
| HTN | 工程落地难、资料稀少、替代方案足够好 |
| 强化学习、行为克隆 | 数据需求大、调参难、缺乏控制性，不适合中小团队 |
🎯 四大游戏 AI 方法全面对比表
| 评估项 | FSM（有限状态机） | BT（行为树） | GOAP（目标导向行为规划） | Utility AI（效用系统） |
|---|---|---|---|---|
| 实现难度 | ★☆☆☆☆（非常易） | ★★☆☆☆（较易） | ★★★★☆（较难） | ★★★☆☆（中等） |
| 扩展性 | ★☆☆☆☆（差） | ★★★★☆（好） | ★★★★☆（好） | ★★★☆☆（中等） |
| 行为复杂度 | ★★☆☆☆（低） | ★★★☆☆（中） | ★★★★★（高） | ★★★★☆（高） |
| 动态反应能力 | ★★☆☆☆（固定响应） | ★★★☆☆（靠分支逻辑） | ★★★★★（基于目标自动规划） | ★★★★★（可动态打分响应） |
| 行为复用性 | ★☆☆☆☆（差） | ★★★★★（非常强） | ★★★☆☆（中） | ★★★★☆（高） |
| 逻辑清晰性 | ★★★★☆（结构明确） | ★★★★☆（节点清晰） | ★★☆☆☆（规划路径难读） | ★★☆☆☆（分数调试难） |
| 调试难度 | ★☆☆☆☆（最易） | ★★☆☆☆（较易） | ★★★★★（难） | ★★★★☆（较难） |
| 适合数量多单位 | ★★★★★（性能高） | ★★★★☆（合理） | ★★☆☆☆（重规划开销大） | ★★★★☆（评估轻量） |
| 支持中断行为 | ★☆☆☆☆（手动处理） | ★★★★☆（节点中断支持） | ★★★★☆（动态可重规划） | ★★★★★（天然支持重新评估） |
| 目标驱动能力 | ★☆☆☆☆（被动） | ★★☆☆☆（有限） | ★★★★★（强） | ★★★★☆（强） |
| 智能感 | ★★☆☆☆（僵硬） | ★★★☆☆（自然） | ★★★★★（自主性高） | ★★★★☆（灵活聪明） |
| 学习/维护成本 | ★☆☆☆☆（低） | ★★☆☆☆（中等） | ★★★★★（高） | ★★★☆☆（中高） |
| 典型使用场景 | 巡逻、攻击、逃跑等简单AI | NPC行为、敌人AI、中复杂AI | 沙盒角色、策略游戏、潜行AI | 战术AI、日常NPC、动态环境响应 |
🔍 说明简要解释
- 实现难度：从开发者角度考虑的上手复杂度
- 扩展性：能否方便添加新行为或改变逻辑
- 行为复杂度：支持的行为链条/决策深度
- 动态反应能力：应对突发情况或环境变化能力
- 行为复用性：行为是否能在多个AI复用
- 逻辑清晰性：是否容易阅读理解AI执行逻辑
- 调试难度：排查行为异常的难度
- 适合多单位：大量实体运行下的性能表现
- 中断支持：是否能灵活中止当前行为切换到新行为
- 目标驱动：是否支持角色“自主”决定目标
- 智能感：玩家是否觉得“这AI好像真的在想”
- 学习成本：对团队学习曲线的负担
Bevy生态
Bevy生态库对fsm/bt/goap/utility都有支持,传送门.