Phaser 宠物伙伴 AI：跟随、拾取、技能触发和亲密度要分层

为什么这个系统不能临时拼

一个冒险游戏里，玩家带着小机器人探索遗迹。它会跟随、帮忙拾取碎片、在战斗中放护盾，还会根据亲密度解锁表情。

真实项目里，最容易出问题的不是第一版能不能跑，而是后续能不能解释、能不能复现、能不能被内容团队稳定使用。宠物如果只是每帧追玩家，会挡路、抖动、抢镜头；如果技能触发写在战斗里，又会和亲密度、冷却、动画混成一团。 这类系统一旦和奖励、存档、关卡进度或玩家输入有关，就不能只写在某个 Scene 的按钮回调里。更稳的做法是把规则层、表现层和调试层拆开：规则层只处理数据和状态，表现层负责 Phaser 动画、粒子、音效和 UI，调试层负责把中间状态暴露出来。

本文按一个可上线的小型系统来拆。它不追求一次覆盖所有商业项目的复杂度，而是把边界先立住：哪些数据进入模型，哪些事件触发表现，哪些失败可以恢复，哪些日志能帮助线上排查。只要这些边界清楚，后续加活动、加难度、加皮肤或加服务端同步，都不会把系统推倒重写。

核心架构

flowchart TD
  A["输入：一个冒险游戏里，玩家带着小机器人探索遗迹。它会跟随、帮忙拾取碎片、在战斗中放护盾，还会根据亲密度解锁表情。"] --> B["PetBrain"]
  B --> C["FollowSlot"]
  C --> D["LootAssistant"]
  D --> E["PetSkillController"]
  E --> F["BondModel"]
  F --> G["Phaser 表现层：动画、UI、音效"]
  G --> H["调试与日志：复现、校验、上线观察"]

这个结构的重点是单向流动。玩法对象向系统提交意图或事件，核心系统计算结果，Phaser 层根据结果播放反馈。不要让 Sprite 的动画进度、按钮显示状态或粒子是否存在反过来决定规则。只要规则是纯数据，就能测试、回放、存档和迁移。

跟随不是追逐玩家坐标

宠物应跟随一个相对槽位，而不是直接追玩家中心。槽位可以在玩家后方、侧后方或飞行高度上，随玩家朝向和速度平滑移动。这样宠物不会挡住攻击，也不会在玩家停下时来回抖。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

状态机要有优先级

救援玩家高于拾取，拾取高于普通跟随，剧情演出高于一切。PetBrain 每次选择意图，再交给具体行为执行。不要让拾取逻辑和技能逻辑同时控制同一个 Sprite。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

拾取要尊重玩家节奏

宠物自动拾取可以减少重复操作，但不能抢走玩家想手动选择的物品。稀有物品可以先提示，普通材料自动捡。背包满时宠物停止拾取并给出轻量反馈。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

亲密度是长期模型

亲密度可以来自喂食、共同战斗、完成任务。它解锁外观、表情、技能槽或跟随动作。亲密度变化要进入存档，不要绑定某个 Scene。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

战斗技能需要冷却和解释

宠物护盾、治疗、嘲讽都应有冷却和触发条件。玩家要能知道宠物为什么刚才不放技能：冷却中、距离过远、能量不足。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

调试宠物 AI

开发模式显示当前意图、目标位置、跟随槽、技能冷却、拾取候选和亲密度事件。宠物 AI bug 常表现为挡路或不响应，可视化能快速定位。

在实现时，建议把这部分写成可以单独调用的服务或 resolver。Scene 只把当前上下文传进去，再根据返回结果更新画面。这样不仅便于测试，也能让调试面板复用同一套计算结果。若这部分逻辑未来需要服务端复算，迁移成本也会低很多。

TypeScript 实现骨架

type PetIntent = "follow" | "pickup" | "assist" | "idle";
interface PetContext { distanceToOwner: number; lootNearby: boolean; ownerHpRate: number; skillReady: boolean }

export function resolvePetIntent(ctx: PetContext): PetIntent {
  if (ctx.ownerHpRate < 0.35 && ctx.skillReady) return "assist";
  if (ctx.distanceToOwner > 180) return "follow";
  if (ctx.lootNearby) return "pickup";
  return "idle";
}

这段代码只展示核心判断，不直接创建 Phaser 对象。实际项目里，你可以在 Scene 中把输入、时间、对象状态整理成快照，再交给这个函数或类。返回值用于驱动动画、音效和 UI，而不是让 UI 自己猜发生了什么。这样写的好处是很直接的：你可以为它写单元测试，也可以在调试面板里把输入和输出打印出来。

数据结构和配置边界

配置要尽量表达设计意图，而不是暴露太多底层实现细节。内容团队更关心“这个节点需要什么条件”“这个阶段持续多久”“这个奖励来自哪里”，不应该被迫理解 Phaser 的坐标、Tween 名称或对象池实现。底层字段可以存在，但要由工具生成或校验。

每份配置都应该有版本。只要系统会进入存档、奖励、关卡成绩或玩家长期进度，就不能假设配置永远不变。版本号能帮助你判断旧数据如何迁移，日志如何解释，客服如何复现。配置更新后，旧玩家的状态要么安全迁移，要么明确补偿或重置，不能静默损坏。

UI 和玩家反馈

玩家不需要看到所有内部数字，但必须理解关键结果。按钮为什么灰掉，失败为什么发生，奖励为什么没有到账，系统为什么选择了这个目标，这些都要有可见反馈。反馈可以很轻：一行原因、一个高亮、一个短音效、一个图标状态。比起华丽动画，可信的解释更能减少挫败。

移动端尤其要注意误触和信息密度。交互区域要足够大，状态变化不要只靠颜色，关键提示不要被刘海屏、虚拟摇杆或系统手势挡住。桌面端则要考虑键盘、鼠标、手柄和窗口失焦。Phaser 能同时覆盖很多平台，系统设计不能只按开发机体验来定。

调试工具

这个系统至少需要一个开发模式面板，显示当前状态、最近事件、配置版本和失败原因。调试面板不是奢侈品，而是内容生产工具。没有它，设计师只能通过反复试玩猜测系统为什么不工作；有了它，问题会变成可讨论的事实。

日志也要分层。开发环境可以详细记录每一步，正式环境只记录关键事件、异常和玩家失败前后的上下文。日志字段要稳定，不要只输出一段中文字符串。结构化日志能被脚本分析，也能帮助客服和运营复现问题。

上线前检查清单

• 跟随槽位不挡玩家
• 行为意图有优先级
• 拾取有过滤和背包检查
• 技能冷却可见
• 亲密度持久化
• 剧情时宠物可被接管
• 配置有版本，旧数据有迁移或回退策略
• UI 能解释失败原因和当前状态
• 关键操作有幂等保护，重复点击不会造成重复收益或重复扣费
• 低端设备有降级方案，不改变核心规则
• 调试面板能显示最近事件和当前计算结果

常见坑

第一，把表现当规则。动画没播完就不结算、粒子存在就算命中、按钮亮着就允许领奖，这些都会在暂停、跳过、切后台或弱网时出问题。

第二，只有成功路径。真实玩家会取消、重试、断网、切场景、连点、误触、读旧存档。每一个关键状态都要有失败恢复和安全回退。

第三，配置无校验。内容越多，拼写错误、引用缺失、数值越界越常见。启动时或导出时做校验，能拦住大量线上事故。

第四，缺少版本意识。只要系统会被存档、回放、排行榜、奖励或活动引用，就必须知道当时使用的是哪一版配置。

收束

这个 Phaser 宠物伙伴 AI：跟随、拾取、技能触发和亲密度要分层，真正难点不在于 Phaser API 本身，而在于规则能否被长期维护。把核心计算从 Scene 中拿出来，把配置、状态、表现和日志分清楚，系统就会从“能演示”变成“能上线”。这也是 Phaser 做中小型 Web 游戏时最值得坚持的工程习惯：用轻量工具快速表现，用清晰模型守住规则。

宠物不要破坏玩家主导权

宠物伙伴最容易从“贴心”变成“碍事”。自动拾取、自动释放技能、自动触发机关都必须尊重玩家主导权。关键机关、稀有掉落、剧情物品最好由玩家确认；宠物可以提示或靠近，但不要直接替玩家决定。战斗技能也要避免抢节奏，例如宠物自动击退敌人可能打断玩家连招，自动嘲讽可能把 Boss 拉出技能范围。

可以给宠物设置行为模式：跟随、辅助、收集、待命。玩家在设置或快捷轮盘里选择模式，PetBrain 在模式范围内决策。这样宠物既有智能，又不会违背玩家意图。模式变化也要有可见反馈，比如宠物头顶小图标或短动画。

宠物路径和卡位

宠物跟随常见问题是卡在门口、推着玩家、被地形困住。解决办法不是让宠物拥有完整复杂寻路，而是设定合理的跟随规则。距离近时使用平滑跟随，距离远时走寻路，距离过远或跨地图时传送到玩家附近。传送要有轻量特效，避免突兀。宠物不应拥有和玩家完全一样的碰撞阻挡，很多游戏会让宠物对玩家无碰撞，对场景有轻碰撞。

开发模式应显示宠物当前路径、目标槽位和传送阈值。若某个地图点经常触发宠物传送，说明地形或导航点需要调整。宠物系统不是只靠 AI 代码，关卡也要给跟随留空间。

宠物外观和能力解耦

宠物系统很容易商业化或收集化。外观皮肤不应该默认改变能力，除非明确是不同宠物类型。可以把 petSkin 和 petAbility 分开：皮肤决定贴图、动画、特效，能力决定技能和数值。这样玩家更换外观不会意外改变战斗构筑，也方便活动皮肤上线。

若某些宠物确实有不同能力，UI 要清楚展示。亲密度、等级、技能、外观分别存储。不要把所有状态塞进一个 petId，否则版本更新和皮肤复刻会很难迁移。

多宠物和上场规则

后期可能允许玩家拥有多只宠物，但只上场一只或两只。上场规则要明确：谁负责拾取，谁负责战斗，技能冷却是否共享，亲密度是否同时增长。若多个宠物都能拾取，可能造成屏幕混乱；若多个宠物都有碰撞，可能挡路。建议第一版只允许一个主宠物上场，其他宠物作为收藏或派遣。

宠物切换也要有冷却或场景限制。战斗中随时换宠物会影响平衡，探索中自由切换更合理。切换时保存旧宠物状态，停止它的持续技能和跟随行为，再激活新宠物。

宠物系统的上线指标

上线后要观察宠物技能触发次数、拾取成功率、玩家手动关闭自动拾取的比例、宠物卡住传送次数和亲密度增长速度。如果很多玩家关闭宠物辅助，说明它打扰了主流程；如果技能几乎不触发，说明条件过严或 UI 没讲清。宠物是陪伴系统，也是一组长期行为数据，不能只看外观购买率。