1. 从普通状态机到分层状态机到底多了什么做角色AI的朋友们应该都有过这种经历一开始用枚举加switch写状态机感觉思路特别清晰一个状态一个case逻辑清清楚楚。等状态多到十几个转换条件开始互相交叉最外层的switch就变成了一坨几百行的大杂烩。这时候你会想有没有一种结构既能保留状态机那种“状态驱动行为”的直觉又不至于让状态和状态之间的关系乱成一锅粥分层有限状态机HFSM就是冲着这个痛点去的。它和普通FSM的核心区别就一条状态机的子节点本身还可以是一整套状态机。父状态负责“大阶段”子状态机负责“大阶段里的具体细节”。这种套娃式的结构让AI的逻辑可以按层次展开每一层的复杂度都控制在“一眼能看懂”的范围。这篇文章我会从框架设计到底层实现、从踩坑记录到选型建议完整拆一遍我自己搭HFSM的心得。先说清楚这东西适合谁。如果你手上的AI只有三五个状态例如巡逻、追击、攻击那么普通FSM完全够用没必要引入分层。当你发现单个状态内部开始出现“等待攻击窗口”“侧向走位”“后撤躲避”这种二级行为而这些二级行为又需要自己的时序和转换关系时你已经在为分层做准备了。要么把二级行为硬塞进一级状态的Update里代码越来越糊要么就把一层状态改成两层父状态管大阶段子状态机管细节。后者就是HFSM。1.1 为什么普通FSM撑不住复杂角色AI普通状态机的本质是一张有向图节点是状态边是转换。写出来的数据长这样当前状态、目标状态、转换条件。这个模型在处理“线性流程”和“简单反馈”时非常顺手比如门禁系统里的开、关、锁定三个状态。但游戏角色AI不是线性流程它是一个同时受玩家行为、环境变化、自身属性影响的动态系统。最常踩的坑是状态爆炸。假设角色有移动、攻击、受击、翻滚、死亡五个大状态每个大状态又需要区分武器类型、是否在空中、是否正在瞄准那实际状态数就是组合数。用普通FSM实现就得把这些组合都拍平变成十几个甚至几十个平铺的状态。麻烦点在于组合之间两两都要配置转换关系转换矩阵的复杂度是状态数量的平方。写到最后你会发现大部分转换是重复的因为“受击后如果在空中则倒地如果在地上则硬直”这种规则本质上描述的是父概念之间的切换而不是每一对具体状态的切换。另一个问题出现在状态内部。普通FSM的理想预期是“一个状态一段独立逻辑”但人形角色的攻击状态往往不是一秒就能结束的它内部可能包含前摇、判定帧、后摇、取消窗口四个阶段每个阶段之间还有允许被玩家输入打断的阈值。这些细节如果全写进同一个Update方法几百行的state machine代码就在所难免。一旦这个函数长了状态的可读性和可测试性都直线下降你知道它在逻辑上应该是“一个状态”但代码上已经变成了“一个大杂烩”。HFSM处理这个问题的方式是保留状态机的定义但让状态本身拥有结构。攻击可以是一个父状态它的内部是一套包含前摇、判定帧、后摇、取消的子状态机。父状态只管“我在攻击”子状态机管“这一刀现在挥到第几帧”。1.2 HFSM的核心思路状态里面套状态机“状态里面套状态机”这句话说起来容易实现起来要解决几个问题。首先是嵌套层级怎么定义。我习惯的命名是普通叶节点状态叫LeafState包含子状态机的容器状态叫CompositeState。CompositeState本身也是一个状态所以它拥有自己的OnEnter、OnUpdate、OnExit生命周期。区别在于CompositeState在OnEnter时会顺带创建并启动一个内部状态机这个内部状态机被称为子状态机。运行时执行顺序是这样的外部状态机驱动CompositeState的OnUpdateCompositeState内部再驱动子状态机的OnUpdate子状态机再去驱动它的当前状态。往下可以嵌套任意深度但实际项目里三层就够了四层几乎没人用不是技术不支持而是人脑维护这种四层嵌套已经很吃力了。这个结构的价值在于转换的局部性。普通FSM里任何状态和任何状态之间都可能发生转换所以配置是全局的。HFSM里父状态之间的转换只在父状态一层配置子状态之间的转换只在子状态机内部配置。比如角色从“追击”切到“战斗”这是顶层转换不再关心追击和战斗内部的二级状态是什么。而战斗内部的“接近”切到“攻击”是子状态机的局部转换不需要让外部的巡逻状态感知到。每一层的状态数量被严格限制在一个可控范围转换关系也不会出现全局交叉。一句话概括HFSM表面上是给你的状态加了一个容器本质上是给你的转换关系减了复杂度。2. 框架结构拆解核心模块与数据模型把HFSM落地成代码之前我建议先把数据模型想清楚。状态机框架的代码不复杂难点在边界和生命周期。我拆过几版之后最终沉淀下来的核心模块是五个状态IState、转换ITransition、动作IAction、条件ICondition、黑板Blackboard。这五个东西各管一摊尽量不要混。2.1 五个基础组件状态、转换、动作、条件、黑板先看状态接口。这个接口是整个框架的地基所有状态类都要实现它interface IState { onEnter(): void; onUpdate(deltaTime: number): void; onExit(): void; }onEnter做进入前的准备例如播放入场动画、重置计时器、初始化参数。onUpdate是状态运行期间每帧要执行的行为移动、朝向、技能释放逻辑都放在这里。onExit做退出清理例如恢复受击判定、停止粒子特效、释放临时资源。这个接口刻意保持狭窄因为它要被所有状态实现越宽约意味着实现成本越高。转换是状态机的“边”它描述在什么条件下可以离开当前状态。我最开始用的转换接口长这样interface ITransition { fromState: string; toState: string; condition: ICondition; }这里有个细节fromState到底该写成具体状态名还是允许通配符实际项目里你一定会遇到“无论我在哪个子状态只要血量归零就必须切到死亡”的需求。如果fromState只能是单个状态名那死亡转换就得在每个状态下面各写一遍这个体验很糟糕。所以我后来加了一个概念叫来源组允许一个转换声明自己是从“任意状态”出发的。这也解释了为什么后面很多框架都引入“AnyState”这种东西。我自己的实现里不直接给fromState留空字符串作为“任意”而是提供一个显式的通用状态标记让代码语义更清晰。条件是一个独立的布尔判断器它不持有状态机的引用只负责读取黑板数据并返回真或假。把它独立出来的价值是复用。比如“目标距离小于三米”这个条件在普通移动状态、攻击状态、后撤状态里都可能用到写成独立条件类之后配转换的时候直接引用同一实例即可。动作是可选的执行行为它可以绑定在状态上、绑定在转换上、甚至绑定在进入状态后的指定延迟上。我个人的习惯是尽量少用转换动作因为转换已经包含条件检查动作的出现会让调试时难以判断“到底是谁触发了这个行为”。状态内部的动作足够用转换动作只留给一个场景打断类技能触发的瞬间强制位移。黑板是共享数据的总线。角色AI的所有元素——目标位置、自身血量、技能冷却倒计时、是否受击、仇恨对象ID——都放进一个黑板对象里状态、条件、动作都从黑板读数据而不是直接互相引用。没有黑板的话你会发现两个微妙的问题一是条件判断需要访问外部对象接口被迫膨胀二是上下文参数被到处传递每次状态切换都要重新拼装参数列表。黑板相当于给所有逻辑块提供了一个公共工作区远程地解耦了读写依赖。2.2 生命周期约定进入、执行、退出生命周期是状态机框架里最容易写乱的地方也是我建议在一开始就定死规则的地方。三个方法之间的语义应该严格执行onEnter负责“建立前提”onUpdate负责“基于前提运转”onExit负责“撤销前提”。不能把进入动画播放一半的逻辑塞进onEnter里等动画事件也不能把退出清理丢给下一个状态的onEnter去做。换句话讲onEnter执行完毕后状态应当处于一个可运行的中间状态而不是等待某帧事件的尴尬状态。这要求框架对异步事件比如动画事件、远程调用回调有统一归宿。我的方案是引入状态内事件队列onEnter时如果需要等待某个动画Event不直接挂起状态而是注册一个延迟动作由状态机的主循环统一推进。这样状态永远不会处于“不知道自己在干嘛”的未定义状态。onExit还有个容易踩的坑退出时状态可能把自身的清理逻辑写成空实现。表面上看状态切换正常但内存里可能残留监听器、协程或者未停止的特效。某些项目里出现的“角色死过一次之后还会偶尔说话”这种怪病就是退出时没有摘干净事件监听导致的。我后面会在第五节细说这个问题。生命周期的执行顺序也值得明确一下。一个转换被触发时正确顺序是先调旧状态的onExit再调新状态的onEnter。如果有中间态或过渡态应该在两者之间额外插入一个过渡状态的onEnter。这里要注意不能让旧状态的onExit和过渡态onEnter同时重叠运行否则会出现两套移动指令同时作用于角色的撕裂感。2.3 为什么用类对象而不是枚举加switch相当多游戏项目的普通FSM是这么写的枚举定义状态Update里一个switch分支每个case里写行为状态切换就是一个变量赋值的功夫。这套方案在状态少于五个时非常方便但它的三个致命伤在HFSM场景下会变得无法容忍。第一switch里没有状态生命周期。状态切换只是一行赋值代码旧状态退出时的清理逻辑要么没写要么散落在各分支里形同虚设。没有onExit你就没法定点回收正在播放的技能动画、关闭温度传感器等临时资源。第二switch分支天然不利于状态数据封装。每个case要读取外部各种引用状态本地的私有数据只能定义在函数外层时间一长函数参数列表能绕地球三圈。第三嵌套状态机无法用switch旁路实现。一个case里如果还要再switch一次子状态机代码的可读性会瞬间归零。类对象方案把每个状态变成独立类状态自己的私有数据就定义在类的成员变量里生命周期方法天然存在转换逻辑被提升为独立组件。代价是每个状态都要写一个类文件数量变多。实践下来这个代价是值得的尤其是在你后续要给每个状态配编辑器、做可视化调试、甚至导出配置表的时候类结构远比switch分支容易工具化。一个我常用的妥协方案是叶子状态用类简单状态的逻辑可以写成一个lambda表达式包裹的轻量状态对象。框架提供两种状态实现一种是标准类一种是函数式简写。这样既保留了类结构的规范性又不至于为了一个“待机发呆两秒”的小状态专门写一个完整类。3. 父子状态协作分层是如何工作的框架的结构设计解决的是“代码怎么组织”但HFSM真正的灵魂在于父子状态之间怎么协作。这一节讲运行时行为也是最容易和普通FSM的思维惯性打架的地方。3.1 父状态如何把控制权交出去CompositeState首次进入时需要初始化它的内部状态机并选择一个默认子状态作为起始。这个默认子状态的选择逻辑可以静态配置也可以在父状态进入时根据黑板数据动态决定。比如“空中状态”的默认子状态是“自由下落”但如果角色进入空中时同时按着前冲键默认子状态应该是“空中冲刺”。动态选默认子状态的价值就在这里。父状态的onUpdate执行顺序应该是先更新自己独有的行为比如头顶的阵营标识、霸体状态检测再转发给子状态机执行。如果一个父状态没有自己的行为它可以完全不重写onUpdate让框架自动透传给子状态机这样可以少写很多空转代码。在父子协作的层级模型里决策权始终在“当前运行的那个叶节点状态”手里。父状态负责的是“我属于哪个大阶段”子状态负责的是“这个大阶段里我具体在做什么”。举个例子角色倒地这个父状态下子状态机可能在“倒地硬直”“倒地挣扎”“倒地起身中间态”之间切换父状态不需要感知具体是哪个它只知道“我处于倒地大阶段”并且可以被技能打断强制起身。这种抽象让打断行为的转换逻辑变得很简单强制起身往回跳转时不再需要准确穿越叶节点层级只要在顶层关闭倒地父状态即可子状态机被整体回收。3.2 转换优先级与默认子状态子状态机的转换逻辑和顶层状态机完全一致但它有个额外概念叫“优先级”。同一时刻转换条件可能同时满足多个例如“血量低于30%”和“玩家后撤超过五米”同时为真其中一个可能是要求立即停止追击进入防御的紧急转换。普通FSM一般靠配置顺序解决但HFSM里我建议给转换加上显式的优先级字段数值越高越先被检查。优先级只在条件交集出现时才有意义大多数日常转换并不相交。为了不让每张转换配置表都变成一场数字排序的口水战我的经验是只给特殊转换标优先级常见的普通转换统一用默认优先级。这就避免了你肉眼比较两个“没啥区别”的数字大小。除了优先级之外需要处理的还有转换周期问题。是每帧检查所有转换条件还是每0.1秒检查一次每帧检查必然引入性能开销尤其当条件里面包含路径计算或者场景查询时一帧一查会让CPU冒烟。我的做法是给条件配置自己的检查周期高频条件受击中断、死亡判断每帧检查低频条件目标丢失、检视距离每0.2秒检查一次。条件计时的实现很简单在条件接口里加入一个可选的评估间隔字段即可。3.3 历史状态与全局事件的取舍分层之外还有两个经常在HFSM里同时出现的概念一个是历史状态一个是全局事件。历史状态的意思是当父状态被临时踢出比如被一个高优先级的受伤状态覆盖下次再回到同一个父状态时是回到默认子状态还是回到上次被打断时的那个子状态前者实现简单行为固定后者会增加一点状态机的“记忆”能力但会把行为变得不那么可预测。我的取舍是默认不使用历史状态除非某个玩法的反馈明确要求“恢复场景”比如角色被击飞后落地应该回到倒地前的移动模式。实现上也很轻量CompositeState在onExit时多写一个变量记录当前子状态再次onEnter时优先恢复该记录。全局事件是处理跨层通知的利器。比如“玩家按下了闪避键”这个信息理论上应该让任何层级任何状态都能感知而不能要求它在某一个子状态才有效。处理方式有两种一种是在黑板里设置一个瞬时事件标记任何状态在onUpdate里都能读到另一种是给状态机注册一个事件通道事件发布后由各状态自行订阅。前者写起来更简单后者在需要带参数传递时更灵活。我的框架是两者都支持但黑板事件标记只用于无参布尔事态复杂数据还是走事件通道。4. 实操搭建一个角色战斗AI的HFSM实现理论说太多容易飘直接来一个能用的例子。下面演示一个动作游戏角色的战斗AI需求不算复杂但足够说明分层怎么用。4.1 需求分析与顶层状态划分需求描述一个近战角色在关卡里待机、巡逻发现敌人后进入追击与敌人距离合适时进入战斗。战斗中会根据距离和冷却时间切换接近、攻击、防御、后撤四个子行为。被命中且血量低于危险线时战斗优先变成防御状态。敌人死亡后回到巡逻。顶层状态量不大就三个待机、巡逻、战斗。这里战斗就是一个典型CompositeState它的内部子状态机是独立的一整套系统。class IdleState implements IState { onEnter() { agent.animator.Play(idle); } onUpdate(deltaTime: number) { // 待机时周期性扫视不做移动 agent.ScanSurrounding(1.5); } onExit() { agent.animator.Stop(idle); } } class PatrolState implements IState { onEnter() { agent.patrolPath.Reset(); } onUpdate(deltaTime: number) { // 沿路点移动到点后进入下一点 agent.MoveTo(agent.patrolPath.Current()); if (agent.Arrived()) agent.patrolPath.Next(); } onExit() { agent.patrolPath.Clear(); } } class CombatState extends CompositeState { onEnter() { // 进入战斗初始子状态为追击 this.subMachine.InitialState(new AttackApproachState(agent)); } }顶层转换条件就三个地方需要关注发现敌人待机或巡逻 - 战斗、敌人丢失战斗 - 巡逻、击杀完成战斗 - 巡逻。传统FSM里你需要在每个子行为上都配一遍“击杀完成”的转换在HFSM里这个转换只在顶层配一次战斗内部子状态机根本不需要知道自己外面发生了什么。4.2 战斗子状态机的搭建现在看战斗子状态机内部怎么设计。四个子状态接近、攻击、防御、后撤。接近状态负责保持攻击距离它朝向敌人移动满足距离小于攻击半径时切向攻击。攻击状态的内部又有一个小的“技能执行”子状态机里面是前摇、命中帧、后摇三个节点这就是第二层嵌套。防御状态负责按键式格挡和被动减伤当玩家集中输出时可进入。后撤状态用于拉开失控距离通常在被连续命中或技能CD真空期启用。子状态机代码和顶层结构完全一致复用的是同一套框架只是切入点不同class CombatSubMachine extends StateMachine { constructor(agent: Agent) { super(); this.AddTransition(new DistanceTransition(agent, 2.4, AttackStateName), attackApproach); this.AddTransition(new CooldownExpiredTransition(agent.skill), attackApproach, skill_cd_end); this.AddTransition(new HealthLowTransition(agent, 0.25), anyState, defendState); } }DistanceTransition属于可复用条件类它在构造函数里接收一个agent引用和阈值读取黑板上缓存的敌人距离返回是否小于阈值。任何需要用距离做判断的状态切换都可以复用它。这是前面说“条件独立成类”的直接收益。4.3 黑板数据与条件复用整个系统里的角色共享一个黑板实例里面放这些字段class Blackboard { enemyPosition: Vector3; selfPosition: Vector3; selfHp: number; skillCooldown: number; isUnderAttack: boolean; }条件实现只需要从黑板读取。比如DefenceCondition它判断isUnderAttack并且selfHp低于某个阈值时返回真。这个条件在顶层和子层都能使用因为黑板的数据是统一的条件类也不关心自己在第几层。这个特征做久了之后会很舒服因为你不需要针对层级写两套条件逻辑。4.4 数据驱动配置的思路框架搭建稳定之后有些项目会进一步把状态和转换做成配置表用脚本或JSON定义AI行为代码只提供状态类库。这是数据驱动的重要一步好处是不动代码就能调AI行为。缺点是需要设计一套配置格式并且要处理“运行时动态生成状态”的生命周期问题。我的建议是中小项目不急着上配置表先把框架和状态类写清楚等状态量突破二十个再考虑配置化。配置化的核心不是把代码翻译成JSON而是把转换关系从代码中解耦出来。例如“眩晕状态下无法执行任何移动类子状态”这类规则放在配置里的可读性远高于代码里的一个个if判断。如果你有编辑器或可视化工具的需求再把状态类用反射注册成可序列化的对象配置表的成本可控。5. 踩坑实录常见问题与排查技巧框架用久了坑遇到得多了反而积累出一套排查心法。这里整理我实际项目中碰到的高频问题每一个都附了定位思路。5.1 状态切不回去也要找回不到的原因症状角色从战斗退出后回到待机状态却一动不动。排查步骤先看onExit是否触发。如果战斗状态退出时没有停下来攻击动画也没有清空移动目标回到待机状态的表现当然就不正常。更隐蔽的情况是战斗子状态机里的某个子状态比如后撤持有对移动组件的持续引用退出时忘记释放导致虽然顶层状态机切到了待机但底层组件里还有一个残留指令在驱动角色移动。这类问题本质上都是生命周期没执行干净。我的排查思路是在状态机的基类里打日志记录每次onEnter和onExit的上下文对比异常状态的进入退出时间线。框架层级多的时候日志里能直接看到“战斗父状态退出时子状态机是否被正确清空”。5.2 转换条件互相打架与优先级震荡症状角色在两个状态之间疯狂抖动走两步切攻击攻击没放完又切回接近来回跳跃看起来像得了帕金森。原因往往是两个转换条件在一帧内同时为真且两个条件又刚好是互斥关系的两难判断。例如“距离小于三米”和“距离大于两米”的条件在距离正好落在二到三米的重叠区间内时会同时成立如果没有优先级设置状态就会反复跳转。对策是两条一是设计条件时尽量避免重叠区间或者在重叠处增加迟滞带。例如接近-攻击的阈值是三米攻击-接近的阈值设成一米两个方向的条件分别使用不同的阈值。这么做虽然会让“状态判断不够灵敏”但换来的是极强的稳定性。二是给转换加显式优先级确保打架时谁赢是确定的没有灰色地带。5.3 子状态泄漏与父状态退不干净症状父状态退出后子状态机还在跑。典型表现是角色已切到巡逻但攻击动作依然在播放或角色仍受战斗中断的移动指令影响。这个和第二个问题不一样第二个问题出在顶层这个出在父子关联。排查要点是确认CompositeState的onExit是否正确调用了它的子状态机exit方法。我见过不止一次因为父状态没有转发onExit子状态机还停留在子状态上没有任何清理行为。经验做法是在框架层强制规定CompositeState的onExit必须显式调用子状态机的Shutdown()。如果你不希望每次写CombatState都要记得这个约定那就在基类里封装一个默认行为CompositeState的onExit如果写的是super.onExit()框架就自动清空子状态机如果子类明确不调用super那你必须自己在代码里处理。这个选项设计成显式优于隐式可以少埋一半的雷。5.4 调试与可视化HFSM的调试量比普通FSM高出不少。单层状态出问题看几个日志就好多层嵌套的情况光靠打日志是灾难因为它会产生大量噪声日志。我的方案有两个。第一个是在框架层面加运行态路径打印。状态机每一帧维护一个“当前运行链”例如 [战斗 - 攻击 - 前摇]。这个运行链在编辑器里实时显示排查状态切换问题时一眼就知道当前执行到哪一层。第二个是给每个条件加一个“最近判定结果”的缓存并在调试面板上展示条件结果。这样你看到状态没切不用猜到底是条件没满足还是条件满足了但转换没生效。性能问题在调试阶段往往不明显等角色数量多到几十个时每帧的Update开销就会被放大。最耗的部分是条件检查。一个角色身上静态配置上百个转换条件每帧全check一遍几十个角色就是几千次条件调用。优化手段前面提过分频检查与条件短路。另外条件检查顺序也值得打磨把计算成本极低的布尔判断放在前面路径计算这类开销大的放在最后一旦低成本条件不满足就直接短路跳过省下的计算量很可观。6. HFSM和行为树怎么选在游戏AI圈聊状态机迟早会被问到“你为什么不用行为树”这句话。这俩不是互为替代关系它们解决的问题层次不一样但在实际项目中经常被放在一起比较。6.1 两者的本质区别行为树的本质是“决策树 任务节点”。它每帧从根节点开始自上而下地评估优先级选择一条分支执行。决策发生在遍历树的瞬间决策结果是一次性的选择每次执行都重新评估。HFSM的本质是“带有记忆的控制器”。当前状态会持续影响行为直到某个明确的条件把它转移走。这是一个“保持型”系统而行为树是“选择型”系统。这个区别会产生三种实际影响。第一状态连续性HFSM天生支持“我处于攻击状态”这种持续语境而行为树每次遍历都在重新问“接下来该做什么”如果不额外加记忆节点行为树很难表达“我这一刀已经挥到一半不能因为敌人跑出攻击范围就瞬间取消”HFSM的当前状态天然继承了这个信息。第二转换逻辑HFSM的转换定义在状态之间行为树的优先级定义在选择分支上二者各有优点。第三可维护性行为树的“可读性非常好”指的是决策层的可见性但树的深度一旦复杂调试起来并不比HFSM轻松两者都需要专门的工具支撑。6.2 实际项目里的混合用法大型项目里用得最多的方案不是二选一而是混合行为树负责高层决策目标选择、策略权衡HFSM负责底层行为表现具体动作的维持与切换。这个架构通常被称为“决策/表现分离”。决策层用行为树判断“当前应该追击还是防守”得到一个目标意图把它写入黑板。表现层用HFSM根据这些意图执行具体的身体动作保持状态连续性。战斗攻击动作作为CompositeState挂在表现层既不会被行为树的每帧重评估打断又可以通过决策层传达的新意图来打断退出。这么拆的好处是决策层可以随便调整策略优先级不会干扰到底层状态的稳定执行表现层可以安心优化动作衔接不必每帧去关心“我现在该不该换目标”。所以选型时我的判断标准很简单如果你需要的是“持续的状态流动”比如脚踩地面、攻击前摇、倒地恢复选HFSM。如果你是做“结构化决策”比如敌人类型、威胁等级、地形优势的综合权衡选行为树。两者不冲突甚至可以说是黄金搭档。最后再分享一个我个人的实操习惯不管用HFSM还是行为树都不要急着把所有逻辑都塞进框架里。先把角色AI的“状态边界”定义清楚再谈具体是分层还是决策树。状态边界才是整个系统最核心的资产框架只是把这份资产的价值放大出来的外壳。我见过很多人状态边界都没想明白换个框架照样踩坑代码一样乱。先把边界切对再讨论用HFSM还是用别的你的AI系统会走得更远。
1. 从普通状态机到分层状态机到底多了什么做角色AI的朋友们应该都有过这种经历一开始用枚举加switch写状态机感觉思路特别清晰一个状态一个case逻辑清清楚楚。等状态多到十几个转换条件开始互相交叉最外层的switch就变成了一坨几百行的大杂烩。这时候你会想有没有一种结构既能保留状态机那种“状态驱动行为”的直觉又不至于让状态和状态之间的关系乱成一锅粥分层有限状态机HFSM就是冲着这个痛点去的。它和普通FSM的核心区别就一条状态机的子节点本身还可以是一整套状态机。父状态负责“大阶段”子状态机负责“大阶段里的具体细节”。这种套娃式的结构让AI的逻辑可以按层次展开每一层的复杂度都控制在“一眼能看懂”的范围。这篇文章我会从框架设计到底层实现、从踩坑记录到选型建议完整拆一遍我自己搭HFSM的心得。先说清楚这东西适合谁。如果你手上的AI只有三五个状态例如巡逻、追击、攻击那么普通FSM完全够用没必要引入分层。当你发现单个状态内部开始出现“等待攻击窗口”“侧向走位”“后撤躲避”这种二级行为而这些二级行为又需要自己的时序和转换关系时你已经在为分层做准备了。要么把二级行为硬塞进一级状态的Update里代码越来越糊要么就把一层状态改成两层父状态管大阶段子状态机管细节。后者就是HFSM。1.1 为什么普通FSM撑不住复杂角色AI普通状态机的本质是一张有向图节点是状态边是转换。写出来的数据长这样当前状态、目标状态、转换条件。这个模型在处理“线性流程”和“简单反馈”时非常顺手比如门禁系统里的开、关、锁定三个状态。但游戏角色AI不是线性流程它是一个同时受玩家行为、环境变化、自身属性影响的动态系统。最常踩的坑是状态爆炸。假设角色有移动、攻击、受击、翻滚、死亡五个大状态每个大状态又需要区分武器类型、是否在空中、是否正在瞄准那实际状态数就是组合数。用普通FSM实现就得把这些组合都拍平变成十几个甚至几十个平铺的状态。麻烦点在于组合之间两两都要配置转换关系转换矩阵的复杂度是状态数量的平方。写到最后你会发现大部分转换是重复的因为“受击后如果在空中则倒地如果在地上则硬直”这种规则本质上描述的是父概念之间的切换而不是每一对具体状态的切换。另一个问题出现在状态内部。普通FSM的理想预期是“一个状态一段独立逻辑”但人形角色的攻击状态往往不是一秒就能结束的它内部可能包含前摇、判定帧、后摇、取消窗口四个阶段每个阶段之间还有允许被玩家输入打断的阈值。这些细节如果全写进同一个Update方法几百行的state machine代码就在所难免。一旦这个函数长了状态的可读性和可测试性都直线下降你知道它在逻辑上应该是“一个状态”但代码上已经变成了“一个大杂烩”。HFSM处理这个问题的方式是保留状态机的定义但让状态本身拥有结构。攻击可以是一个父状态它的内部是一套包含前摇、判定帧、后摇、取消的子状态机。父状态只管“我在攻击”子状态机管“这一刀现在挥到第几帧”。1.2 HFSM的核心思路状态里面套状态机“状态里面套状态机”这句话说起来容易实现起来要解决几个问题。首先是嵌套层级怎么定义。我习惯的命名是普通叶节点状态叫LeafState包含子状态机的容器状态叫CompositeState。CompositeState本身也是一个状态所以它拥有自己的OnEnter、OnUpdate、OnExit生命周期。区别在于CompositeState在OnEnter时会顺带创建并启动一个内部状态机这个内部状态机被称为子状态机。运行时执行顺序是这样的外部状态机驱动CompositeState的OnUpdateCompositeState内部再驱动子状态机的OnUpdate子状态机再去驱动它的当前状态。往下可以嵌套任意深度但实际项目里三层就够了四层几乎没人用不是技术不支持而是人脑维护这种四层嵌套已经很吃力了。这个结构的价值在于转换的局部性。普通FSM里任何状态和任何状态之间都可能发生转换所以配置是全局的。HFSM里父状态之间的转换只在父状态一层配置子状态之间的转换只在子状态机内部配置。比如角色从“追击”切到“战斗”这是顶层转换不再关心追击和战斗内部的二级状态是什么。而战斗内部的“接近”切到“攻击”是子状态机的局部转换不需要让外部的巡逻状态感知到。每一层的状态数量被严格限制在一个可控范围转换关系也不会出现全局交叉。一句话概括HFSM表面上是给你的状态加了一个容器本质上是给你的转换关系减了复杂度。2. 框架结构拆解核心模块与数据模型把HFSM落地成代码之前我建议先把数据模型想清楚。状态机框架的代码不复杂难点在边界和生命周期。我拆过几版之后最终沉淀下来的核心模块是五个状态IState、转换ITransition、动作IAction、条件ICondition、黑板Blackboard。这五个东西各管一摊尽量不要混。2.1 五个基础组件状态、转换、动作、条件、黑板先看状态接口。这个接口是整个框架的地基所有状态类都要实现它interface IState { onEnter(): void; onUpdate(deltaTime: number): void; onExit(): void; }onEnter做进入前的准备例如播放入场动画、重置计时器、初始化参数。onUpdate是状态运行期间每帧要执行的行为移动、朝向、技能释放逻辑都放在这里。onExit做退出清理例如恢复受击判定、停止粒子特效、释放临时资源。这个接口刻意保持狭窄因为它要被所有状态实现越宽约意味着实现成本越高。转换是状态机的“边”它描述在什么条件下可以离开当前状态。我最开始用的转换接口长这样interface ITransition { fromState: string; toState: string; condition: ICondition; }这里有个细节fromState到底该写成具体状态名还是允许通配符实际项目里你一定会遇到“无论我在哪个子状态只要血量归零就必须切到死亡”的需求。如果fromState只能是单个状态名那死亡转换就得在每个状态下面各写一遍这个体验很糟糕。所以我后来加了一个概念叫来源组允许一个转换声明自己是从“任意状态”出发的。这也解释了为什么后面很多框架都引入“AnyState”这种东西。我自己的实现里不直接给fromState留空字符串作为“任意”而是提供一个显式的通用状态标记让代码语义更清晰。条件是一个独立的布尔判断器它不持有状态机的引用只负责读取黑板数据并返回真或假。把它独立出来的价值是复用。比如“目标距离小于三米”这个条件在普通移动状态、攻击状态、后撤状态里都可能用到写成独立条件类之后配转换的时候直接引用同一实例即可。动作是可选的执行行为它可以绑定在状态上、绑定在转换上、甚至绑定在进入状态后的指定延迟上。我个人的习惯是尽量少用转换动作因为转换已经包含条件检查动作的出现会让调试时难以判断“到底是谁触发了这个行为”。状态内部的动作足够用转换动作只留给一个场景打断类技能触发的瞬间强制位移。黑板是共享数据的总线。角色AI的所有元素——目标位置、自身血量、技能冷却倒计时、是否受击、仇恨对象ID——都放进一个黑板对象里状态、条件、动作都从黑板读数据而不是直接互相引用。没有黑板的话你会发现两个微妙的问题一是条件判断需要访问外部对象接口被迫膨胀二是上下文参数被到处传递每次状态切换都要重新拼装参数列表。黑板相当于给所有逻辑块提供了一个公共工作区远程地解耦了读写依赖。2.2 生命周期约定进入、执行、退出生命周期是状态机框架里最容易写乱的地方也是我建议在一开始就定死规则的地方。三个方法之间的语义应该严格执行onEnter负责“建立前提”onUpdate负责“基于前提运转”onExit负责“撤销前提”。不能把进入动画播放一半的逻辑塞进onEnter里等动画事件也不能把退出清理丢给下一个状态的onEnter去做。换句话讲onEnter执行完毕后状态应当处于一个可运行的中间状态而不是等待某帧事件的尴尬状态。这要求框架对异步事件比如动画事件、远程调用回调有统一归宿。我的方案是引入状态内事件队列onEnter时如果需要等待某个动画Event不直接挂起状态而是注册一个延迟动作由状态机的主循环统一推进。这样状态永远不会处于“不知道自己在干嘛”的未定义状态。onExit还有个容易踩的坑退出时状态可能把自身的清理逻辑写成空实现。表面上看状态切换正常但内存里可能残留监听器、协程或者未停止的特效。某些项目里出现的“角色死过一次之后还会偶尔说话”这种怪病就是退出时没有摘干净事件监听导致的。我后面会在第五节细说这个问题。生命周期的执行顺序也值得明确一下。一个转换被触发时正确顺序是先调旧状态的onExit再调新状态的onEnter。如果有中间态或过渡态应该在两者之间额外插入一个过渡状态的onEnter。这里要注意不能让旧状态的onExit和过渡态onEnter同时重叠运行否则会出现两套移动指令同时作用于角色的撕裂感。2.3 为什么用类对象而不是枚举加switch相当多游戏项目的普通FSM是这么写的枚举定义状态Update里一个switch分支每个case里写行为状态切换就是一个变量赋值的功夫。这套方案在状态少于五个时非常方便但它的三个致命伤在HFSM场景下会变得无法容忍。第一switch里没有状态生命周期。状态切换只是一行赋值代码旧状态退出时的清理逻辑要么没写要么散落在各分支里形同虚设。没有onExit你就没法定点回收正在播放的技能动画、关闭温度传感器等临时资源。第二switch分支天然不利于状态数据封装。每个case要读取外部各种引用状态本地的私有数据只能定义在函数外层时间一长函数参数列表能绕地球三圈。第三嵌套状态机无法用switch旁路实现。一个case里如果还要再switch一次子状态机代码的可读性会瞬间归零。类对象方案把每个状态变成独立类状态自己的私有数据就定义在类的成员变量里生命周期方法天然存在转换逻辑被提升为独立组件。代价是每个状态都要写一个类文件数量变多。实践下来这个代价是值得的尤其是在你后续要给每个状态配编辑器、做可视化调试、甚至导出配置表的时候类结构远比switch分支容易工具化。一个我常用的妥协方案是叶子状态用类简单状态的逻辑可以写成一个lambda表达式包裹的轻量状态对象。框架提供两种状态实现一种是标准类一种是函数式简写。这样既保留了类结构的规范性又不至于为了一个“待机发呆两秒”的小状态专门写一个完整类。3. 父子状态协作分层是如何工作的框架的结构设计解决的是“代码怎么组织”但HFSM真正的灵魂在于父子状态之间怎么协作。这一节讲运行时行为也是最容易和普通FSM的思维惯性打架的地方。3.1 父状态如何把控制权交出去CompositeState首次进入时需要初始化它的内部状态机并选择一个默认子状态作为起始。这个默认子状态的选择逻辑可以静态配置也可以在父状态进入时根据黑板数据动态决定。比如“空中状态”的默认子状态是“自由下落”但如果角色进入空中时同时按着前冲键默认子状态应该是“空中冲刺”。动态选默认子状态的价值就在这里。父状态的onUpdate执行顺序应该是先更新自己独有的行为比如头顶的阵营标识、霸体状态检测再转发给子状态机执行。如果一个父状态没有自己的行为它可以完全不重写onUpdate让框架自动透传给子状态机这样可以少写很多空转代码。在父子协作的层级模型里决策权始终在“当前运行的那个叶节点状态”手里。父状态负责的是“我属于哪个大阶段”子状态负责的是“这个大阶段里我具体在做什么”。举个例子角色倒地这个父状态下子状态机可能在“倒地硬直”“倒地挣扎”“倒地起身中间态”之间切换父状态不需要感知具体是哪个它只知道“我处于倒地大阶段”并且可以被技能打断强制起身。这种抽象让打断行为的转换逻辑变得很简单强制起身往回跳转时不再需要准确穿越叶节点层级只要在顶层关闭倒地父状态即可子状态机被整体回收。3.2 转换优先级与默认子状态子状态机的转换逻辑和顶层状态机完全一致但它有个额外概念叫“优先级”。同一时刻转换条件可能同时满足多个例如“血量低于30%”和“玩家后撤超过五米”同时为真其中一个可能是要求立即停止追击进入防御的紧急转换。普通FSM一般靠配置顺序解决但HFSM里我建议给转换加上显式的优先级字段数值越高越先被检查。优先级只在条件交集出现时才有意义大多数日常转换并不相交。为了不让每张转换配置表都变成一场数字排序的口水战我的经验是只给特殊转换标优先级常见的普通转换统一用默认优先级。这就避免了你肉眼比较两个“没啥区别”的数字大小。除了优先级之外需要处理的还有转换周期问题。是每帧检查所有转换条件还是每0.1秒检查一次每帧检查必然引入性能开销尤其当条件里面包含路径计算或者场景查询时一帧一查会让CPU冒烟。我的做法是给条件配置自己的检查周期高频条件受击中断、死亡判断每帧检查低频条件目标丢失、检视距离每0.2秒检查一次。条件计时的实现很简单在条件接口里加入一个可选的评估间隔字段即可。3.3 历史状态与全局事件的取舍分层之外还有两个经常在HFSM里同时出现的概念一个是历史状态一个是全局事件。历史状态的意思是当父状态被临时踢出比如被一个高优先级的受伤状态覆盖下次再回到同一个父状态时是回到默认子状态还是回到上次被打断时的那个子状态前者实现简单行为固定后者会增加一点状态机的“记忆”能力但会把行为变得不那么可预测。我的取舍是默认不使用历史状态除非某个玩法的反馈明确要求“恢复场景”比如角色被击飞后落地应该回到倒地前的移动模式。实现上也很轻量CompositeState在onExit时多写一个变量记录当前子状态再次onEnter时优先恢复该记录。全局事件是处理跨层通知的利器。比如“玩家按下了闪避键”这个信息理论上应该让任何层级任何状态都能感知而不能要求它在某一个子状态才有效。处理方式有两种一种是在黑板里设置一个瞬时事件标记任何状态在onUpdate里都能读到另一种是给状态机注册一个事件通道事件发布后由各状态自行订阅。前者写起来更简单后者在需要带参数传递时更灵活。我的框架是两者都支持但黑板事件标记只用于无参布尔事态复杂数据还是走事件通道。4. 实操搭建一个角色战斗AI的HFSM实现理论说太多容易飘直接来一个能用的例子。下面演示一个动作游戏角色的战斗AI需求不算复杂但足够说明分层怎么用。4.1 需求分析与顶层状态划分需求描述一个近战角色在关卡里待机、巡逻发现敌人后进入追击与敌人距离合适时进入战斗。战斗中会根据距离和冷却时间切换接近、攻击、防御、后撤四个子行为。被命中且血量低于危险线时战斗优先变成防御状态。敌人死亡后回到巡逻。顶层状态量不大就三个待机、巡逻、战斗。这里战斗就是一个典型CompositeState它的内部子状态机是独立的一整套系统。class IdleState implements IState { onEnter() { agent.animator.Play(idle); } onUpdate(deltaTime: number) { // 待机时周期性扫视不做移动 agent.ScanSurrounding(1.5); } onExit() { agent.animator.Stop(idle); } } class PatrolState implements IState { onEnter() { agent.patrolPath.Reset(); } onUpdate(deltaTime: number) { // 沿路点移动到点后进入下一点 agent.MoveTo(agent.patrolPath.Current()); if (agent.Arrived()) agent.patrolPath.Next(); } onExit() { agent.patrolPath.Clear(); } } class CombatState extends CompositeState { onEnter() { // 进入战斗初始子状态为追击 this.subMachine.InitialState(new AttackApproachState(agent)); } }顶层转换条件就三个地方需要关注发现敌人待机或巡逻 - 战斗、敌人丢失战斗 - 巡逻、击杀完成战斗 - 巡逻。传统FSM里你需要在每个子行为上都配一遍“击杀完成”的转换在HFSM里这个转换只在顶层配一次战斗内部子状态机根本不需要知道自己外面发生了什么。4.2 战斗子状态机的搭建现在看战斗子状态机内部怎么设计。四个子状态接近、攻击、防御、后撤。接近状态负责保持攻击距离它朝向敌人移动满足距离小于攻击半径时切向攻击。攻击状态的内部又有一个小的“技能执行”子状态机里面是前摇、命中帧、后摇三个节点这就是第二层嵌套。防御状态负责按键式格挡和被动减伤当玩家集中输出时可进入。后撤状态用于拉开失控距离通常在被连续命中或技能CD真空期启用。子状态机代码和顶层结构完全一致复用的是同一套框架只是切入点不同class CombatSubMachine extends StateMachine { constructor(agent: Agent) { super(); this.AddTransition(new DistanceTransition(agent, 2.4, AttackStateName), attackApproach); this.AddTransition(new CooldownExpiredTransition(agent.skill), attackApproach, skill_cd_end); this.AddTransition(new HealthLowTransition(agent, 0.25), anyState, defendState); } }DistanceTransition属于可复用条件类它在构造函数里接收一个agent引用和阈值读取黑板上缓存的敌人距离返回是否小于阈值。任何需要用距离做判断的状态切换都可以复用它。这是前面说“条件独立成类”的直接收益。4.3 黑板数据与条件复用整个系统里的角色共享一个黑板实例里面放这些字段class Blackboard { enemyPosition: Vector3; selfPosition: Vector3; selfHp: number; skillCooldown: number; isUnderAttack: boolean; }条件实现只需要从黑板读取。比如DefenceCondition它判断isUnderAttack并且selfHp低于某个阈值时返回真。这个条件在顶层和子层都能使用因为黑板的数据是统一的条件类也不关心自己在第几层。这个特征做久了之后会很舒服因为你不需要针对层级写两套条件逻辑。4.4 数据驱动配置的思路框架搭建稳定之后有些项目会进一步把状态和转换做成配置表用脚本或JSON定义AI行为代码只提供状态类库。这是数据驱动的重要一步好处是不动代码就能调AI行为。缺点是需要设计一套配置格式并且要处理“运行时动态生成状态”的生命周期问题。我的建议是中小项目不急着上配置表先把框架和状态类写清楚等状态量突破二十个再考虑配置化。配置化的核心不是把代码翻译成JSON而是把转换关系从代码中解耦出来。例如“眩晕状态下无法执行任何移动类子状态”这类规则放在配置里的可读性远高于代码里的一个个if判断。如果你有编辑器或可视化工具的需求再把状态类用反射注册成可序列化的对象配置表的成本可控。5. 踩坑实录常见问题与排查技巧框架用久了坑遇到得多了反而积累出一套排查心法。这里整理我实际项目中碰到的高频问题每一个都附了定位思路。5.1 状态切不回去也要找回不到的原因症状角色从战斗退出后回到待机状态却一动不动。排查步骤先看onExit是否触发。如果战斗状态退出时没有停下来攻击动画也没有清空移动目标回到待机状态的表现当然就不正常。更隐蔽的情况是战斗子状态机里的某个子状态比如后撤持有对移动组件的持续引用退出时忘记释放导致虽然顶层状态机切到了待机但底层组件里还有一个残留指令在驱动角色移动。这类问题本质上都是生命周期没执行干净。我的排查思路是在状态机的基类里打日志记录每次onEnter和onExit的上下文对比异常状态的进入退出时间线。框架层级多的时候日志里能直接看到“战斗父状态退出时子状态机是否被正确清空”。5.2 转换条件互相打架与优先级震荡症状角色在两个状态之间疯狂抖动走两步切攻击攻击没放完又切回接近来回跳跃看起来像得了帕金森。原因往往是两个转换条件在一帧内同时为真且两个条件又刚好是互斥关系的两难判断。例如“距离小于三米”和“距离大于两米”的条件在距离正好落在二到三米的重叠区间内时会同时成立如果没有优先级设置状态就会反复跳转。对策是两条一是设计条件时尽量避免重叠区间或者在重叠处增加迟滞带。例如接近-攻击的阈值是三米攻击-接近的阈值设成一米两个方向的条件分别使用不同的阈值。这么做虽然会让“状态判断不够灵敏”但换来的是极强的稳定性。二是给转换加显式优先级确保打架时谁赢是确定的没有灰色地带。5.3 子状态泄漏与父状态退不干净症状父状态退出后子状态机还在跑。典型表现是角色已切到巡逻但攻击动作依然在播放或角色仍受战斗中断的移动指令影响。这个和第二个问题不一样第二个问题出在顶层这个出在父子关联。排查要点是确认CompositeState的onExit是否正确调用了它的子状态机exit方法。我见过不止一次因为父状态没有转发onExit子状态机还停留在子状态上没有任何清理行为。经验做法是在框架层强制规定CompositeState的onExit必须显式调用子状态机的Shutdown()。如果你不希望每次写CombatState都要记得这个约定那就在基类里封装一个默认行为CompositeState的onExit如果写的是super.onExit()框架就自动清空子状态机如果子类明确不调用super那你必须自己在代码里处理。这个选项设计成显式优于隐式可以少埋一半的雷。5.4 调试与可视化HFSM的调试量比普通FSM高出不少。单层状态出问题看几个日志就好多层嵌套的情况光靠打日志是灾难因为它会产生大量噪声日志。我的方案有两个。第一个是在框架层面加运行态路径打印。状态机每一帧维护一个“当前运行链”例如 [战斗 - 攻击 - 前摇]。这个运行链在编辑器里实时显示排查状态切换问题时一眼就知道当前执行到哪一层。第二个是给每个条件加一个“最近判定结果”的缓存并在调试面板上展示条件结果。这样你看到状态没切不用猜到底是条件没满足还是条件满足了但转换没生效。性能问题在调试阶段往往不明显等角色数量多到几十个时每帧的Update开销就会被放大。最耗的部分是条件检查。一个角色身上静态配置上百个转换条件每帧全check一遍几十个角色就是几千次条件调用。优化手段前面提过分频检查与条件短路。另外条件检查顺序也值得打磨把计算成本极低的布尔判断放在前面路径计算这类开销大的放在最后一旦低成本条件不满足就直接短路跳过省下的计算量很可观。6. HFSM和行为树怎么选在游戏AI圈聊状态机迟早会被问到“你为什么不用行为树”这句话。这俩不是互为替代关系它们解决的问题层次不一样但在实际项目中经常被放在一起比较。6.1 两者的本质区别行为树的本质是“决策树 任务节点”。它每帧从根节点开始自上而下地评估优先级选择一条分支执行。决策发生在遍历树的瞬间决策结果是一次性的选择每次执行都重新评估。HFSM的本质是“带有记忆的控制器”。当前状态会持续影响行为直到某个明确的条件把它转移走。这是一个“保持型”系统而行为树是“选择型”系统。这个区别会产生三种实际影响。第一状态连续性HFSM天生支持“我处于攻击状态”这种持续语境而行为树每次遍历都在重新问“接下来该做什么”如果不额外加记忆节点行为树很难表达“我这一刀已经挥到一半不能因为敌人跑出攻击范围就瞬间取消”HFSM的当前状态天然继承了这个信息。第二转换逻辑HFSM的转换定义在状态之间行为树的优先级定义在选择分支上二者各有优点。第三可维护性行为树的“可读性非常好”指的是决策层的可见性但树的深度一旦复杂调试起来并不比HFSM轻松两者都需要专门的工具支撑。6.2 实际项目里的混合用法大型项目里用得最多的方案不是二选一而是混合行为树负责高层决策目标选择、策略权衡HFSM负责底层行为表现具体动作的维持与切换。这个架构通常被称为“决策/表现分离”。决策层用行为树判断“当前应该追击还是防守”得到一个目标意图把它写入黑板。表现层用HFSM根据这些意图执行具体的身体动作保持状态连续性。战斗攻击动作作为CompositeState挂在表现层既不会被行为树的每帧重评估打断又可以通过决策层传达的新意图来打断退出。这么拆的好处是决策层可以随便调整策略优先级不会干扰到底层状态的稳定执行表现层可以安心优化动作衔接不必每帧去关心“我现在该不该换目标”。所以选型时我的判断标准很简单如果你需要的是“持续的状态流动”比如脚踩地面、攻击前摇、倒地恢复选HFSM。如果你是做“结构化决策”比如敌人类型、威胁等级、地形优势的综合权衡选行为树。两者不冲突甚至可以说是黄金搭档。最后再分享一个我个人的实操习惯不管用HFSM还是行为树都不要急着把所有逻辑都塞进框架里。先把角色AI的“状态边界”定义清楚再谈具体是分层还是决策树。状态边界才是整个系统最核心的资产框架只是把这份资产的价值放大出来的外壳。我见过很多人状态边界都没想明白换个框架照样踩坑代码一样乱。先把边界切对再讨论用HFSM还是用别的你的AI系统会走得更远。
