1. 项目概述为什么你的Unity项目需要一个FSM在Unity里做项目尤其是涉及到角色控制、UI流程、AI行为这些有明确“状态”切换逻辑的部分你是不是经常写出这样的代码一堆if-else或者switch-case散落在Update里判断条件越来越复杂加一个新状态就得小心翼翼地在各个地方修改生怕哪里漏了或者冲突了。代码越写越乱逻辑越来越难维护这就是典型的“面条式”状态管理。FSM有限状态机就是来解决这个问题的。它不是什么高深莫测的黑科技而是一种极其经典、有效的设计模式。你可以把它想象成一个智能的“状态切换器”。一个角色比如游戏里的敌人它有“巡逻”、“追击”、“攻击”、“死亡”这几个状态。FSM的核心思想就是在任意时刻这个敌人只处于一个确定的状态每个状态都定义了在这个状态下能做什么进入、更新、退出状态之间的切换则由明确的“条件”来触发。这次我们要做的就是从零开始在Unity里搭建一个轻量、清晰、易用的FSM框架。这个框架不依赖任何第三方库完全由我们自己实现目的是让你彻底理解FSM的运作原理并能把它灵活地应用到你的项目中去无论是控制一个Boss的复杂行为链还是管理一个登录界面的弹窗流程都能让代码结构变得清爽。2. FSM核心架构设计与思路拆解一个完整的FSM框架核心就是三个部分状态State、状态机StateMachine和状态转换条件Transition。我们的设计目标是高内聚、低耦合、易扩展。2.1 状态State基类设计状态不应该只是一个枚举值而应该是一个拥有行为的对象。我们定义一个抽象的StateBase基类任何具体状态如IdleState, RunState都继承自它。// StateBase.cs using UnityEngine; public abstract class StateBase { // 状态ID用于唯一标识和快速比较通常用枚举或字符串 public int StateID { get; protected set; } // 所属的状态机引用 protected StateMachine stateMachine; // 构造函数注入状态机 public StateBase(int id, StateMachine machine) { StateID id; stateMachine machine; } // 当进入此状态时调用 public virtual void OnEnter() { } // 每帧更新时调用相当于MonoBehaviour的Update public virtual void OnUpdate(float deltaTime) { } // 当退出此状态时调用 public virtual void OnExit() { } // 可选固定时间步更新相当于FixedUpdate public virtual void OnFixedUpdate() { } // 可选后更新相当于LateUpdate public virtual void OnLateUpdate() { } }设计思路解析虚方法Virtual MethodsOnEnter,OnUpdate,OnExit等设计为虚方法而不是抽象方法。这意味着具体状态类可以只重写它关心的方法。比如一个纯粹的过渡动画状态可能只需要OnEnter和OnExit而不需要OnUpdate。这提供了更大的灵活性。状态机引用每个状态都持有其所属状态机的引用。这很关键因为状态在执行逻辑时经常需要查询状态机管理的其他数据如拥有者对象、共享参数或者在条件满足时请求状态机切换到另一个状态。DeltaTimeOnUpdate方法传入deltaTime这是为了与Unity的帧率解耦确保状态逻辑在不同帧率下的表现一致。2.2 状态机StateMachine控制器设计状态机是FSM的大脑它负责管理所有状态的注册、存储当前状态、驱动状态更新、并处理状态切换。// StateMachine.cs using System.Collections.Generic; using UnityEngine; public class StateMachine { // 状态字典以状态ID为键快速查找 private Dictionaryint, StateBase _states new Dictionaryint, StateBase(); // 当前状态 private StateBase _currentState; public StateBase CurrentState _currentState; // 状态机拥有者例如一个PlayerController或EnemyAI组件 public GameObject Owner { get; private set; } // 一个共享的参数字典用于在不同状态间传递数据 private Dictionarystring, object _blackboard new Dictionarystring, object(); public StateMachine(GameObject owner) { Owner owner; } // 注册一个状态到状态机 public void RegisterState(StateBase state) { if (_states.ContainsKey(state.StateID)) { Debug.LogWarning($State {state.StateID} is already registered.); return; } _states.Add(state.StateID, state); } // 切换到指定状态 public void ChangeState(int stateID) { if (!_states.ContainsKey(stateID)) { Debug.LogError($State {stateID} is not registered.); return; } StateBase targetState _states[stateID]; // 如果目标状态就是当前状态不做任何事除非你希望重新进入 if (_currentState ! null _currentState.StateID stateID) { // Debug.Log($Already in state {stateID}.); return; } // 1. 退出当前状态 _currentState?.OnExit(); // 2. 切换状态引用 StateBase previousState _currentState; _currentState targetState; // 3. 进入新状态 _currentState.OnEnter(); // 可以在这里触发一个状态切换事件方便其他系统监听 // OnStateChanged?.Invoke(previousState?.StateID, _currentState.StateID); } // 状态机更新驱动需要在MonoBehaviour的Update中调用 public void OnUpdate(float deltaTime) { _currentState?.OnUpdate(deltaTime); } public void OnFixedUpdate() { _currentState?.OnFixedUpdate(); } public void OnLateUpdate() { _currentState?.OnLateUpdate(); } // 黑板Blackboard相关方法用于状态间数据共享 public void SetBlackboardValueT(string key, T value) { _blackboard[key] value; } public T GetBlackboardValueT(string key, T defaultValue default) { if (_blackboard.TryGetValue(key, out object value) value is T) { return (T)value; } return defaultValue; } public bool HasBlackboardValue(string key) { return _blackboard.ContainsKey(key); } }设计思路解析字典存储状态使用Dictionaryint, StateBase来存储状态以状态ID为键。这比用List遍历查找要高效得多尤其是在状态数量较多时。明确的切换流程ChangeState方法严格遵循“退出旧状态 - 切换引用 - 进入新状态”的流程。这个顺序非常重要确保了状态生命周期管理的正确性。黑板系统Blackboard这是一个非常实用的设计。状态之间经常需要通信比如“巡逻状态”发现玩家后需要告诉“追击状态”玩家的位置。通过一个共享的Dictionary状态可以安全地读写数据避免了状态类之间直接的、混乱的引用。这大大降低了耦合度。驱动更新状态机本身不继承MonoBehaviour它只是一个普通的C#类。它的更新需要外部的MonoBehaviour比如一个StateMachineRunner组件来驱动。这样设计更灵活状态机可以存在于任何地方而不必绑定在游戏对象上。2.3 状态转换条件Transition的抽象简单的状态机直接在状态类的OnUpdate里判断条件并调用ChangeState。但对于复杂的状态机转换逻辑可能很复杂且一个状态可能有多条转换路径。我们可以将“转换条件”也抽象出来。// TransitionBase.cs public abstract class TransitionBase { public int FromStateID { get; protected set; } public int ToStateID { get; protected set; } protected StateMachine stateMachine; public TransitionBase(int fromState, int toState, StateMachine machine) { FromStateID fromState; ToStateID toState; stateMachine machine; } // 核心方法检查转换条件是否满足 public abstract bool CheckCondition(); // 当转换即将发生时调用在OnExit之后OnEnter之前 public virtual void OnTransition() { } } // 示例一个基于距离的转换条件 public class DistanceTransition : TransitionBase { private Transform _ownerTransform; private Transform _targetTransform; private float _triggerDistance; private bool _greaterThan; // true表示大于阈值时触发false表示小于时触发 public DistanceTransition(int fromState, int toState, StateMachine machine, Transform owner, Transform target, float distance, bool greaterThan true) : base(fromState, toState, machine) { _ownerTransform owner; _targetTransform target; _triggerDistance distance; _greaterThan greaterThan; } public override bool CheckCondition() { if (_ownerTransform null || _targetTransform null) return false; float distance Vector3.Distance(_ownerTransform.position, _targetTransform.position); if (_greaterThan) { return distance _triggerDistance; } else { return distance _triggerDistance; } } }设计思路解析分离关注点将“状态行为”和“状态转换逻辑”分离。状态类只关心“我在这个状态下做什么”而转换条件类只关心“什么时候从A状态切换到B状态”。这使得两者都可以独立变化和复用。可组合的复杂条件你可以创建AndTransition、OrTransition、NotTransition这样的组合条件类将简单的条件组合成复杂的逻辑树极大地增强了表达能力。状态机集成转换条件需要由状态机在每帧更新时进行检查。我们可以在状态机里维护一个ListTransitionBase然后在OnUpdate中遍历检查。如果某个条件的FromStateID匹配当前状态且CheckCondition()返回true则执行状态切换。3. 核心细节解析与实操要点3.1 状态ID的定义与管理状态ID是状态机的“钥匙”。如何定义它很有讲究。方案一使用枚举Enum这是最直观、类型安全的方式。public enum EPlayerState { Idle 0, Run, Jump, Attack, Hurt, Die }优点编译时检查智能提示好代码可读性高。缺点枚举是值类型在作为字典键时没问题但如果你需要动态创建状态比如从配置表读取枚举就不太方便。而且枚举定义在一个地方如果状态种类非常多比如几十种维护起来可能有点乱。方案二使用字符串Stringstring stateId “Player_Idle”;优点非常灵活可以动态生成易于序列化和配置比如从JSON读取。缺点容易拼写错误且查找效率略低于整型虽然对于游戏状态数量来说可以忽略不计。需要自己管理命名规范避免冲突。方案三使用整型常量int Constpublic static class StateIDs { public const int Player_Idle 1001; public const int Player_Run 1002; // ... public const int Enemy_Patrol 2001; public const int Enemy_Chase 2002; }优点兼具枚举的类型安全在常量层面和整型的效率。可以通过数值范围对不同模块的状态进行分组如1000系列是玩家2000系列是敌人。缺点需要手动维护一个常量类分配ID不能重复。我的建议对于中小型项目优先使用枚举。它的清晰度和安全性是最高的。只有当你的状态需要高度动态化、可配置时才考虑使用字符串或整型常量。3.2 状态机的驱动与生命周期状态机本身没有MonoBehaviour的生命周期所以我们需要一个“跑步者Runner”来驱动它。通常我们会创建一个StateMachineComponent脚本挂载在需要使用状态机的游戏对象上。// StateMachineComponent.cs using UnityEngine; public class StateMachineComponent : MonoBehaviour { public StateMachine StateMachine { get; private set; } void Awake() { // 初始化状态机传入拥有者这个GameObject StateMachine new StateMachine(gameObject); // 在这里注册所有状态 InitializeStates(); // 设置初始状态 StateMachine.ChangeState((int)EPlayerState.Idle); } void Update() { // 驱动状态机更新 StateMachine?.OnUpdate(Time.deltaTime); } void FixedUpdate() { StateMachine?.OnFixedUpdate(); } void LateUpdate() { StateMachine?.OnLateUpdate(); } void InitializeStates() { // 创建并注册状态实例 StateMachine.RegisterState(new PlayerIdleState((int)EPlayerState.Idle, StateMachine)); StateMachine.RegisterState(new PlayerRunState((int)EPlayerState.Run, StateMachine)); // ... 注册其他状态 } }关键点驱动时机一定要在Awake中初始化状态机和状态而不是Start。因为Start的执行顺序可能晚于其他脚本的Update如果其他脚本在Start里访问状态机可能它还没初始化。初始状态在Awake的最后或Start的开头调用ChangeState设置初始状态。确保所有状态注册完毕后再切换。多状态机一个复杂的游戏对象比如一个拥有技能、移动、情绪等多个维度的RPG角色可能需要多个状态机来管理不同层面的逻辑。这时你可以创建多个StateMachine实例分别由不同的StateMachineComponent或同一个组件中的不同字段来管理。3.3 黑板Blackboard系统的深入使用黑板是状态间通信的桥梁用好它能极大提升框架的灵活性。典型使用场景传递目标信息巡逻状态发现敌人后将敌人的Transform或位置存入黑板SetBlackboardValue(“TargetEnemy”, enemyTransform)。追击状态和攻击状态都可以读取这个值GetBlackboardValueTransform(“TargetEnemy”)。共享计时器一个“冷却”状态结束后在黑板设置一个“SkillACooldownOver”true。技能释放状态在OnUpdate中检查这个标志为真时才允许释放技能。配置参数可以从外部如策划配置表读取一些参数移动速度、视野范围存入黑板所有状态都从这里读取实现配置与逻辑分离。注意事项键名管理和状态ID一样黑板键名也建议用常量或枚举来管理避免魔法字符串。public static class BlackboardKeys { public const string TargetPosition “TargetPosition”; public const string IsPlayerInSight “IsPlayerInSight”; }类型安全GetBlackboardValueT提供了泛型参数和默认值使用起来比较安全。但要注意如果你存入的是UnityEngine.Object类型如GameObject,Transform在对象被销毁后取出来的值可能是一个“Missing”的引用需要做空值判断。清理当状态机重置或拥有者被销毁时记得清空黑板_blackboard.Clear()防止旧数据干扰新的逻辑。4. 实操过程与核心环节实现一个敌人AI的完整示例让我们用一个经典的敌人AI巡逻 - 追击 - 攻击 - 返回巡逻来串联整个框架的使用。我们会定义状态、转换条件并组装成一个可运行的状态机。4.1 步骤一定义状态枚举和黑板键// EnemyState.cs public enum EEnemyState { Patrol 0, Chase, Attack, Return, Hurt } public static class EnemyBlackboardKeys { public const string TargetPlayer “TargetPlayer”; public const string LastPatrolPosition “LastPatrolPosition”; public const string AttackCooldown “AttackCooldown”; }4.2 步骤二实现具体状态类PatrolState巡逻状态public class EnemyPatrolState : StateBase { private Transform _enemyTransform; private float _patrolSpeed; private Vector3[] _waypoints; private int _currentWaypointIndex 0; private float _waypointThreshold 0.5f; public EnemyPatrolState(int id, StateMachine machine) : base(id, machine) { _enemyTransform stateMachine.Owner.transform; // 可以从配置或黑板读取参数 _patrolSpeed 3.0f; // 简单示例设置两个巡逻点 _waypoints new Vector3[] { new Vector3(-5, 0, 0), new Vector3(5, 0, 0) }; } public override void OnEnter() { Debug.Log($“Enemy [{stateMachine.Owner.name}] enters Patrol State.”); // 进入巡逻状态时记录当前位置作为“返回点” stateMachine.SetBlackboardValue(EnemyBlackboardKeys.LastPatrolPosition, _enemyTransform.position); } public override void OnUpdate(float deltaTime) { // 1. 巡逻逻辑向当前路点移动 Vector3 targetPos _waypoints[_currentWaypointIndex]; Vector3 moveDir (targetPos - _enemyTransform.position).normalized; _enemyTransform.position moveDir * _patrolSpeed * deltaTime; // 检查是否到达路点 if (Vector3.Distance(_enemyTransform.position, targetPos) _waypointThreshold) { _currentWaypointIndex (_currentWaypointIndex 1) % _waypoints.Length; } // 2. 转换条件检查发现玩家 // 这里为了示例我们简单用距离判断。实际项目中会用视野锥、射线检测等。 GameObject player GameObject.FindGameObjectWithTag(“Player”); if (player ! null) { float distToPlayer Vector3.Distance(_enemyTransform.position, player.transform.position); if (distToPlayer 10f) // 发现距离 { // 将玩家信息存入黑板 stateMachine.SetBlackboardValue(EnemyBlackboardKeys.TargetPlayer, player.transform); // 请求切换到追击状态 stateMachine.ChangeState((int)EEnemyState.Chase); return; // 注意切换状态后当前帧的OnUpdate应该立即停止执行 } } } public override void OnExit() { Debug.Log($“Enemy [{stateMachine.Owner.name}] exits Patrol State.”); } }ChaseState追击状态public class EnemyChaseState : StateBase { private Transform _enemyTransform; private float _chaseSpeed; private Transform _targetPlayer; public EnemyChaseState(int id, StateMachine machine) : base(id, machine) { _enemyTransform stateMachine.Owner.transform; _chaseSpeed 5.0f; } public override void OnEnter() { Debug.Log($“Enemy [{stateMachine.Owner.name}] enters Chase State.”); // 从黑板获取目标玩家 _targetPlayer stateMachine.GetBlackboardValueTransform(EnemyBlackboardKeys.TargetPlayer); if (_targetPlayer null) { // 如果没有目标直接退回巡逻 stateMachine.ChangeState((int)EEnemyState.Patrol); } } public override void OnUpdate(float deltaTime) { if (_targetPlayer null) { stateMachine.ChangeState((int)EEnemyState.Patrol); return; } // 向玩家移动 Vector3 moveDir (_targetPlayer.position - _enemyTransform.position).normalized; _enemyTransform.position moveDir * _chaseSpeed * deltaTime; // 检查转换条件 float distToPlayer Vector3.Distance(_enemyTransform.position, _targetPlayer.position); // 条件1进入攻击范围 - 切换到攻击状态 if (distToPlayer 2f) { stateMachine.ChangeState((int)EEnemyState.Attack); return; } // 条件2玩家超出追击距离 - 切换到返回状态 if (distToPlayer 15f) { // 清除黑板中的目标因为丢失了 stateMachine.SetBlackboardValueTransform(EnemyBlackboardKeys.TargetPlayer, null); stateMachine.ChangeState((int)EEnemyState.Return); return; } } }AttackState攻击状态与 ReturnState返回状态的实现逻辑类似分别是播放攻击动画/造成伤害以及向LastPatrolPosition移动到达后切回PatrolState。这里篇幅所限不再赘述完整代码但核心结构是一致的。4.3 步骤三创建敌人AI控制器并组装状态机// EnemyAIController.cs using UnityEngine; public class EnemyAIController : MonoBehaviour { private StateMachine _stateMachine; void Awake() { _stateMachine new StateMachine(gameObject); InitializeStates(); // 初始状态为巡逻 _stateMachine.ChangeState((int)EEnemyState.Patrol); } void Update() { _stateMachine.OnUpdate(Time.deltaTime); } void InitializeStates() { _stateMachine.RegisterState(new EnemyPatrolState((int)EEnemyState.Patrol, _stateMachine)); _stateMachine.RegisterState(new EnemyChaseState((int)EEnemyState.Chase, _stateMachine)); _stateMachine.RegisterState(new EnemyAttackState((int)EEnemyState.Attack, _stateMachine)); _stateMachine.RegisterState(new EnemyReturnState((int)EEnemyState.Return, _stateMachine)); // 可以继续注册 Hurt 状态等 } // 提供一个外部接口例如被玩家攻击时调用强制切换到受伤状态 public void TakeDamage() { _stateMachine.ChangeState((int)EEnemyState.Hurt); } }将这个脚本挂载到一个敌人GameObject上运行游戏你就能看到一个具备基本AI行为的敌人在场景中运作。它会在两个点之间巡逻发现玩家后追击进入范围则攻击玩家跑远则返回巡逻点。5. 常见问题与排查技巧实录在实际使用自建FSM框架时你肯定会遇到一些坑。下面是我总结的几个最常见的问题和解决方法。5.1 问题一状态切换后旧状态的逻辑还在执行现象从A状态切换到B状态后控制台还在持续打印A状态的日志或者A状态的移动等效果没有停止。原因这是最经典的问题。在状态A的OnUpdate方法中你检查了切换条件并调用了stateMachine.ChangeState()。但是ChangeState方法并不会立即中断当前OnUpdate方法的执行。状态机会在ChangeState内部先调用A状态的OnExit然后切换当前状态引用为B再调用B状态的OnEnter。但此时A状态的OnUpdate方法还在继续执行它ChangeState调用之后的代码。解决方案在状态类的OnUpdate中每次调用ChangeState后必须立即return。public override void OnUpdate(float deltaTime) { // ... 一些逻辑 if (someCondition) { stateMachine.ChangeState(nextStateId); return; // 关键立即返回避免执行后续代码 } // ... 其他逻辑切换状态后不会执行到这里 }5.2 问题二状态机在切换状态时抛出空引用异常现象在ChangeState方法中调用_currentState?.OnExit()时如果_currentState为null没问题。但如果在OnExit或OnEnter方法内部访问了状态机或拥有者的某些未初始化的组件就会报错。原因状态的生命周期方法OnEnter,OnExit中访问了不安全的资源。比如在OnEnter里试图获取一个可能还未被Awake初始化的组件。解决方案惰性初始化在状态类中对需要的组件采用GetComponent缓存但做好空值检查。private Rigidbody _rb; private Rigidbody MyRigidbody { get { if (_rb null) _rb stateMachine.Owner.GetComponentRigidbody(); return _rb; } } // 使用时MyRigidbody.AddForce(...);确保依赖就绪在状态机初始化Awake时就确保所有状态依赖的核心组件已经准备就绪。复杂的依赖可以考虑使用依赖注入框架但对于简单的FSM在状态构造函数或一个专门的Initialize方法里传递必要参数更直接。5.3 问题三多个转换条件同时满足状态切换不稳定现象一帧内有多个转换条件同时为真状态可能发生多次切换或者切换到非预期的状态。原因状态机在每帧遍历所有转换条件时没有定义优先级或者条件检查的顺序有误。解决方案定义转换优先级在TransitionBase基类中增加一个Priority属性。状态机在检查转换时先按优先级排序只执行优先级最高且条件满足的转换。顺序检查在状态类内部管理转换时比如在OnUpdate里写多个if将最特殊、范围最小的条件放在前面判断。例如“在攻击范围内”比“看到玩家”更特殊应该先判断。如果先判断“看到玩家”就切到追击那么即使进入了攻击范围也因为已经不在巡逻状态的OnUpdate里而无法切换到攻击。使用状态转换图工具对于非常复杂的状态机可以考虑在编辑器里绘制状态转换图并明确每条边的优先级然后通过工具生成代码。这能从根本上避免逻辑冲突。5.4 问题四黑板数据管理混乱现象不同的状态往黑板里存了同名但类型不同的数据导致取用时类型转换失败或者状态结束后忘记清理数据干扰了后续逻辑。解决方案严格的键名管理如前所述使用静态类定义所有可能的键名。类型安全的存取方法我们的GetBlackboardValueT已经做了基础的类型检查。可以进一步加强在Set时也记录类型在Get时进行更严格的类型匹配。状态生命周期绑定清理可以考虑在状态的OnExit方法中清理掉由本状态创建的黑板数据。但这需要谨慎设计因为有些数据可能是为下一个状态准备的。一个更清晰的做法是约定数据的生产者负责清理。或者将黑板的生命周期与状态机绑定状态机重置时清空所有数据。5.5 性能优化小贴士避免每帧Find和GetComponent在状态的OnEnter或构造函数中缓存需要的引用Transform、Rigidbody、Animator等而不是在OnUpdate里频繁调用GetComponent或GameObject.Find。转换条件检查的优化不是所有转换条件都需要每帧检查。例如“冷却时间是否结束”这种条件可以用协程或计时器触发而不是每帧去读Time.time。对于距离判断可以每N帧检查一次而不是每帧。状态对象的复用如果状态是无状态的即不保存随时间变化的成员变量或者可以很容易地重置那么可以考虑使用对象池来复用状态实例避免频繁的GC Alloc。但对于大多数游戏状态数量有限这点优化收益不大优先保证代码清晰。从零搭建一个FSM框架的过程本身就是对状态模式最深刻的学习。它强迫你去思考状态如何划分、如何通信、如何优雅地切换。当你亲手实现并调试通过后再去使用Asset Store里那些功能强大的FSM插件如PlayMaker、NodeCanvas时你会更清楚它们底层在做什么也能更好地利用它们。这个自建的轻量框架足以应对项目中80%的状态管理需求并且因为完全受你控制调试和扩展都极其方便。下次当你的Update里又开始出现一堆控制状态的bool标志时不妨停下来想想是不是该请出FSM这位老朋友了。
1. 项目概述为什么你的Unity项目需要一个FSM在Unity里做项目尤其是涉及到角色控制、UI流程、AI行为这些有明确“状态”切换逻辑的部分你是不是经常写出这样的代码一堆if-else或者switch-case散落在Update里判断条件越来越复杂加一个新状态就得小心翼翼地在各个地方修改生怕哪里漏了或者冲突了。代码越写越乱逻辑越来越难维护这就是典型的“面条式”状态管理。FSM有限状态机就是来解决这个问题的。它不是什么高深莫测的黑科技而是一种极其经典、有效的设计模式。你可以把它想象成一个智能的“状态切换器”。一个角色比如游戏里的敌人它有“巡逻”、“追击”、“攻击”、“死亡”这几个状态。FSM的核心思想就是在任意时刻这个敌人只处于一个确定的状态每个状态都定义了在这个状态下能做什么进入、更新、退出状态之间的切换则由明确的“条件”来触发。这次我们要做的就是从零开始在Unity里搭建一个轻量、清晰、易用的FSM框架。这个框架不依赖任何第三方库完全由我们自己实现目的是让你彻底理解FSM的运作原理并能把它灵活地应用到你的项目中去无论是控制一个Boss的复杂行为链还是管理一个登录界面的弹窗流程都能让代码结构变得清爽。2. FSM核心架构设计与思路拆解一个完整的FSM框架核心就是三个部分状态State、状态机StateMachine和状态转换条件Transition。我们的设计目标是高内聚、低耦合、易扩展。2.1 状态State基类设计状态不应该只是一个枚举值而应该是一个拥有行为的对象。我们定义一个抽象的StateBase基类任何具体状态如IdleState, RunState都继承自它。// StateBase.cs using UnityEngine; public abstract class StateBase { // 状态ID用于唯一标识和快速比较通常用枚举或字符串 public int StateID { get; protected set; } // 所属的状态机引用 protected StateMachine stateMachine; // 构造函数注入状态机 public StateBase(int id, StateMachine machine) { StateID id; stateMachine machine; } // 当进入此状态时调用 public virtual void OnEnter() { } // 每帧更新时调用相当于MonoBehaviour的Update public virtual void OnUpdate(float deltaTime) { } // 当退出此状态时调用 public virtual void OnExit() { } // 可选固定时间步更新相当于FixedUpdate public virtual void OnFixedUpdate() { } // 可选后更新相当于LateUpdate public virtual void OnLateUpdate() { } }设计思路解析虚方法Virtual MethodsOnEnter,OnUpdate,OnExit等设计为虚方法而不是抽象方法。这意味着具体状态类可以只重写它关心的方法。比如一个纯粹的过渡动画状态可能只需要OnEnter和OnExit而不需要OnUpdate。这提供了更大的灵活性。状态机引用每个状态都持有其所属状态机的引用。这很关键因为状态在执行逻辑时经常需要查询状态机管理的其他数据如拥有者对象、共享参数或者在条件满足时请求状态机切换到另一个状态。DeltaTimeOnUpdate方法传入deltaTime这是为了与Unity的帧率解耦确保状态逻辑在不同帧率下的表现一致。2.2 状态机StateMachine控制器设计状态机是FSM的大脑它负责管理所有状态的注册、存储当前状态、驱动状态更新、并处理状态切换。// StateMachine.cs using System.Collections.Generic; using UnityEngine; public class StateMachine { // 状态字典以状态ID为键快速查找 private Dictionaryint, StateBase _states new Dictionaryint, StateBase(); // 当前状态 private StateBase _currentState; public StateBase CurrentState _currentState; // 状态机拥有者例如一个PlayerController或EnemyAI组件 public GameObject Owner { get; private set; } // 一个共享的参数字典用于在不同状态间传递数据 private Dictionarystring, object _blackboard new Dictionarystring, object(); public StateMachine(GameObject owner) { Owner owner; } // 注册一个状态到状态机 public void RegisterState(StateBase state) { if (_states.ContainsKey(state.StateID)) { Debug.LogWarning($State {state.StateID} is already registered.); return; } _states.Add(state.StateID, state); } // 切换到指定状态 public void ChangeState(int stateID) { if (!_states.ContainsKey(stateID)) { Debug.LogError($State {stateID} is not registered.); return; } StateBase targetState _states[stateID]; // 如果目标状态就是当前状态不做任何事除非你希望重新进入 if (_currentState ! null _currentState.StateID stateID) { // Debug.Log($Already in state {stateID}.); return; } // 1. 退出当前状态 _currentState?.OnExit(); // 2. 切换状态引用 StateBase previousState _currentState; _currentState targetState; // 3. 进入新状态 _currentState.OnEnter(); // 可以在这里触发一个状态切换事件方便其他系统监听 // OnStateChanged?.Invoke(previousState?.StateID, _currentState.StateID); } // 状态机更新驱动需要在MonoBehaviour的Update中调用 public void OnUpdate(float deltaTime) { _currentState?.OnUpdate(deltaTime); } public void OnFixedUpdate() { _currentState?.OnFixedUpdate(); } public void OnLateUpdate() { _currentState?.OnLateUpdate(); } // 黑板Blackboard相关方法用于状态间数据共享 public void SetBlackboardValueT(string key, T value) { _blackboard[key] value; } public T GetBlackboardValueT(string key, T defaultValue default) { if (_blackboard.TryGetValue(key, out object value) value is T) { return (T)value; } return defaultValue; } public bool HasBlackboardValue(string key) { return _blackboard.ContainsKey(key); } }设计思路解析字典存储状态使用Dictionaryint, StateBase来存储状态以状态ID为键。这比用List遍历查找要高效得多尤其是在状态数量较多时。明确的切换流程ChangeState方法严格遵循“退出旧状态 - 切换引用 - 进入新状态”的流程。这个顺序非常重要确保了状态生命周期管理的正确性。黑板系统Blackboard这是一个非常实用的设计。状态之间经常需要通信比如“巡逻状态”发现玩家后需要告诉“追击状态”玩家的位置。通过一个共享的Dictionary状态可以安全地读写数据避免了状态类之间直接的、混乱的引用。这大大降低了耦合度。驱动更新状态机本身不继承MonoBehaviour它只是一个普通的C#类。它的更新需要外部的MonoBehaviour比如一个StateMachineRunner组件来驱动。这样设计更灵活状态机可以存在于任何地方而不必绑定在游戏对象上。2.3 状态转换条件Transition的抽象简单的状态机直接在状态类的OnUpdate里判断条件并调用ChangeState。但对于复杂的状态机转换逻辑可能很复杂且一个状态可能有多条转换路径。我们可以将“转换条件”也抽象出来。// TransitionBase.cs public abstract class TransitionBase { public int FromStateID { get; protected set; } public int ToStateID { get; protected set; } protected StateMachine stateMachine; public TransitionBase(int fromState, int toState, StateMachine machine) { FromStateID fromState; ToStateID toState; stateMachine machine; } // 核心方法检查转换条件是否满足 public abstract bool CheckCondition(); // 当转换即将发生时调用在OnExit之后OnEnter之前 public virtual void OnTransition() { } } // 示例一个基于距离的转换条件 public class DistanceTransition : TransitionBase { private Transform _ownerTransform; private Transform _targetTransform; private float _triggerDistance; private bool _greaterThan; // true表示大于阈值时触发false表示小于时触发 public DistanceTransition(int fromState, int toState, StateMachine machine, Transform owner, Transform target, float distance, bool greaterThan true) : base(fromState, toState, machine) { _ownerTransform owner; _targetTransform target; _triggerDistance distance; _greaterThan greaterThan; } public override bool CheckCondition() { if (_ownerTransform null || _targetTransform null) return false; float distance Vector3.Distance(_ownerTransform.position, _targetTransform.position); if (_greaterThan) { return distance _triggerDistance; } else { return distance _triggerDistance; } } }设计思路解析分离关注点将“状态行为”和“状态转换逻辑”分离。状态类只关心“我在这个状态下做什么”而转换条件类只关心“什么时候从A状态切换到B状态”。这使得两者都可以独立变化和复用。可组合的复杂条件你可以创建AndTransition、OrTransition、NotTransition这样的组合条件类将简单的条件组合成复杂的逻辑树极大地增强了表达能力。状态机集成转换条件需要由状态机在每帧更新时进行检查。我们可以在状态机里维护一个ListTransitionBase然后在OnUpdate中遍历检查。如果某个条件的FromStateID匹配当前状态且CheckCondition()返回true则执行状态切换。3. 核心细节解析与实操要点3.1 状态ID的定义与管理状态ID是状态机的“钥匙”。如何定义它很有讲究。方案一使用枚举Enum这是最直观、类型安全的方式。public enum EPlayerState { Idle 0, Run, Jump, Attack, Hurt, Die }优点编译时检查智能提示好代码可读性高。缺点枚举是值类型在作为字典键时没问题但如果你需要动态创建状态比如从配置表读取枚举就不太方便。而且枚举定义在一个地方如果状态种类非常多比如几十种维护起来可能有点乱。方案二使用字符串Stringstring stateId “Player_Idle”;优点非常灵活可以动态生成易于序列化和配置比如从JSON读取。缺点容易拼写错误且查找效率略低于整型虽然对于游戏状态数量来说可以忽略不计。需要自己管理命名规范避免冲突。方案三使用整型常量int Constpublic static class StateIDs { public const int Player_Idle 1001; public const int Player_Run 1002; // ... public const int Enemy_Patrol 2001; public const int Enemy_Chase 2002; }优点兼具枚举的类型安全在常量层面和整型的效率。可以通过数值范围对不同模块的状态进行分组如1000系列是玩家2000系列是敌人。缺点需要手动维护一个常量类分配ID不能重复。我的建议对于中小型项目优先使用枚举。它的清晰度和安全性是最高的。只有当你的状态需要高度动态化、可配置时才考虑使用字符串或整型常量。3.2 状态机的驱动与生命周期状态机本身没有MonoBehaviour的生命周期所以我们需要一个“跑步者Runner”来驱动它。通常我们会创建一个StateMachineComponent脚本挂载在需要使用状态机的游戏对象上。// StateMachineComponent.cs using UnityEngine; public class StateMachineComponent : MonoBehaviour { public StateMachine StateMachine { get; private set; } void Awake() { // 初始化状态机传入拥有者这个GameObject StateMachine new StateMachine(gameObject); // 在这里注册所有状态 InitializeStates(); // 设置初始状态 StateMachine.ChangeState((int)EPlayerState.Idle); } void Update() { // 驱动状态机更新 StateMachine?.OnUpdate(Time.deltaTime); } void FixedUpdate() { StateMachine?.OnFixedUpdate(); } void LateUpdate() { StateMachine?.OnLateUpdate(); } void InitializeStates() { // 创建并注册状态实例 StateMachine.RegisterState(new PlayerIdleState((int)EPlayerState.Idle, StateMachine)); StateMachine.RegisterState(new PlayerRunState((int)EPlayerState.Run, StateMachine)); // ... 注册其他状态 } }关键点驱动时机一定要在Awake中初始化状态机和状态而不是Start。因为Start的执行顺序可能晚于其他脚本的Update如果其他脚本在Start里访问状态机可能它还没初始化。初始状态在Awake的最后或Start的开头调用ChangeState设置初始状态。确保所有状态注册完毕后再切换。多状态机一个复杂的游戏对象比如一个拥有技能、移动、情绪等多个维度的RPG角色可能需要多个状态机来管理不同层面的逻辑。这时你可以创建多个StateMachine实例分别由不同的StateMachineComponent或同一个组件中的不同字段来管理。3.3 黑板Blackboard系统的深入使用黑板是状态间通信的桥梁用好它能极大提升框架的灵活性。典型使用场景传递目标信息巡逻状态发现敌人后将敌人的Transform或位置存入黑板SetBlackboardValue(“TargetEnemy”, enemyTransform)。追击状态和攻击状态都可以读取这个值GetBlackboardValueTransform(“TargetEnemy”)。共享计时器一个“冷却”状态结束后在黑板设置一个“SkillACooldownOver”true。技能释放状态在OnUpdate中检查这个标志为真时才允许释放技能。配置参数可以从外部如策划配置表读取一些参数移动速度、视野范围存入黑板所有状态都从这里读取实现配置与逻辑分离。注意事项键名管理和状态ID一样黑板键名也建议用常量或枚举来管理避免魔法字符串。public static class BlackboardKeys { public const string TargetPosition “TargetPosition”; public const string IsPlayerInSight “IsPlayerInSight”; }类型安全GetBlackboardValueT提供了泛型参数和默认值使用起来比较安全。但要注意如果你存入的是UnityEngine.Object类型如GameObject,Transform在对象被销毁后取出来的值可能是一个“Missing”的引用需要做空值判断。清理当状态机重置或拥有者被销毁时记得清空黑板_blackboard.Clear()防止旧数据干扰新的逻辑。4. 实操过程与核心环节实现一个敌人AI的完整示例让我们用一个经典的敌人AI巡逻 - 追击 - 攻击 - 返回巡逻来串联整个框架的使用。我们会定义状态、转换条件并组装成一个可运行的状态机。4.1 步骤一定义状态枚举和黑板键// EnemyState.cs public enum EEnemyState { Patrol 0, Chase, Attack, Return, Hurt } public static class EnemyBlackboardKeys { public const string TargetPlayer “TargetPlayer”; public const string LastPatrolPosition “LastPatrolPosition”; public const string AttackCooldown “AttackCooldown”; }4.2 步骤二实现具体状态类PatrolState巡逻状态public class EnemyPatrolState : StateBase { private Transform _enemyTransform; private float _patrolSpeed; private Vector3[] _waypoints; private int _currentWaypointIndex 0; private float _waypointThreshold 0.5f; public EnemyPatrolState(int id, StateMachine machine) : base(id, machine) { _enemyTransform stateMachine.Owner.transform; // 可以从配置或黑板读取参数 _patrolSpeed 3.0f; // 简单示例设置两个巡逻点 _waypoints new Vector3[] { new Vector3(-5, 0, 0), new Vector3(5, 0, 0) }; } public override void OnEnter() { Debug.Log($“Enemy [{stateMachine.Owner.name}] enters Patrol State.”); // 进入巡逻状态时记录当前位置作为“返回点” stateMachine.SetBlackboardValue(EnemyBlackboardKeys.LastPatrolPosition, _enemyTransform.position); } public override void OnUpdate(float deltaTime) { // 1. 巡逻逻辑向当前路点移动 Vector3 targetPos _waypoints[_currentWaypointIndex]; Vector3 moveDir (targetPos - _enemyTransform.position).normalized; _enemyTransform.position moveDir * _patrolSpeed * deltaTime; // 检查是否到达路点 if (Vector3.Distance(_enemyTransform.position, targetPos) _waypointThreshold) { _currentWaypointIndex (_currentWaypointIndex 1) % _waypoints.Length; } // 2. 转换条件检查发现玩家 // 这里为了示例我们简单用距离判断。实际项目中会用视野锥、射线检测等。 GameObject player GameObject.FindGameObjectWithTag(“Player”); if (player ! null) { float distToPlayer Vector3.Distance(_enemyTransform.position, player.transform.position); if (distToPlayer 10f) // 发现距离 { // 将玩家信息存入黑板 stateMachine.SetBlackboardValue(EnemyBlackboardKeys.TargetPlayer, player.transform); // 请求切换到追击状态 stateMachine.ChangeState((int)EEnemyState.Chase); return; // 注意切换状态后当前帧的OnUpdate应该立即停止执行 } } } public override void OnExit() { Debug.Log($“Enemy [{stateMachine.Owner.name}] exits Patrol State.”); } }ChaseState追击状态public class EnemyChaseState : StateBase { private Transform _enemyTransform; private float _chaseSpeed; private Transform _targetPlayer; public EnemyChaseState(int id, StateMachine machine) : base(id, machine) { _enemyTransform stateMachine.Owner.transform; _chaseSpeed 5.0f; } public override void OnEnter() { Debug.Log($“Enemy [{stateMachine.Owner.name}] enters Chase State.”); // 从黑板获取目标玩家 _targetPlayer stateMachine.GetBlackboardValueTransform(EnemyBlackboardKeys.TargetPlayer); if (_targetPlayer null) { // 如果没有目标直接退回巡逻 stateMachine.ChangeState((int)EEnemyState.Patrol); } } public override void OnUpdate(float deltaTime) { if (_targetPlayer null) { stateMachine.ChangeState((int)EEnemyState.Patrol); return; } // 向玩家移动 Vector3 moveDir (_targetPlayer.position - _enemyTransform.position).normalized; _enemyTransform.position moveDir * _chaseSpeed * deltaTime; // 检查转换条件 float distToPlayer Vector3.Distance(_enemyTransform.position, _targetPlayer.position); // 条件1进入攻击范围 - 切换到攻击状态 if (distToPlayer 2f) { stateMachine.ChangeState((int)EEnemyState.Attack); return; } // 条件2玩家超出追击距离 - 切换到返回状态 if (distToPlayer 15f) { // 清除黑板中的目标因为丢失了 stateMachine.SetBlackboardValueTransform(EnemyBlackboardKeys.TargetPlayer, null); stateMachine.ChangeState((int)EEnemyState.Return); return; } } }AttackState攻击状态与 ReturnState返回状态的实现逻辑类似分别是播放攻击动画/造成伤害以及向LastPatrolPosition移动到达后切回PatrolState。这里篇幅所限不再赘述完整代码但核心结构是一致的。4.3 步骤三创建敌人AI控制器并组装状态机// EnemyAIController.cs using UnityEngine; public class EnemyAIController : MonoBehaviour { private StateMachine _stateMachine; void Awake() { _stateMachine new StateMachine(gameObject); InitializeStates(); // 初始状态为巡逻 _stateMachine.ChangeState((int)EEnemyState.Patrol); } void Update() { _stateMachine.OnUpdate(Time.deltaTime); } void InitializeStates() { _stateMachine.RegisterState(new EnemyPatrolState((int)EEnemyState.Patrol, _stateMachine)); _stateMachine.RegisterState(new EnemyChaseState((int)EEnemyState.Chase, _stateMachine)); _stateMachine.RegisterState(new EnemyAttackState((int)EEnemyState.Attack, _stateMachine)); _stateMachine.RegisterState(new EnemyReturnState((int)EEnemyState.Return, _stateMachine)); // 可以继续注册 Hurt 状态等 } // 提供一个外部接口例如被玩家攻击时调用强制切换到受伤状态 public void TakeDamage() { _stateMachine.ChangeState((int)EEnemyState.Hurt); } }将这个脚本挂载到一个敌人GameObject上运行游戏你就能看到一个具备基本AI行为的敌人在场景中运作。它会在两个点之间巡逻发现玩家后追击进入范围则攻击玩家跑远则返回巡逻点。5. 常见问题与排查技巧实录在实际使用自建FSM框架时你肯定会遇到一些坑。下面是我总结的几个最常见的问题和解决方法。5.1 问题一状态切换后旧状态的逻辑还在执行现象从A状态切换到B状态后控制台还在持续打印A状态的日志或者A状态的移动等效果没有停止。原因这是最经典的问题。在状态A的OnUpdate方法中你检查了切换条件并调用了stateMachine.ChangeState()。但是ChangeState方法并不会立即中断当前OnUpdate方法的执行。状态机会在ChangeState内部先调用A状态的OnExit然后切换当前状态引用为B再调用B状态的OnEnter。但此时A状态的OnUpdate方法还在继续执行它ChangeState调用之后的代码。解决方案在状态类的OnUpdate中每次调用ChangeState后必须立即return。public override void OnUpdate(float deltaTime) { // ... 一些逻辑 if (someCondition) { stateMachine.ChangeState(nextStateId); return; // 关键立即返回避免执行后续代码 } // ... 其他逻辑切换状态后不会执行到这里 }5.2 问题二状态机在切换状态时抛出空引用异常现象在ChangeState方法中调用_currentState?.OnExit()时如果_currentState为null没问题。但如果在OnExit或OnEnter方法内部访问了状态机或拥有者的某些未初始化的组件就会报错。原因状态的生命周期方法OnEnter,OnExit中访问了不安全的资源。比如在OnEnter里试图获取一个可能还未被Awake初始化的组件。解决方案惰性初始化在状态类中对需要的组件采用GetComponent缓存但做好空值检查。private Rigidbody _rb; private Rigidbody MyRigidbody { get { if (_rb null) _rb stateMachine.Owner.GetComponentRigidbody(); return _rb; } } // 使用时MyRigidbody.AddForce(...);确保依赖就绪在状态机初始化Awake时就确保所有状态依赖的核心组件已经准备就绪。复杂的依赖可以考虑使用依赖注入框架但对于简单的FSM在状态构造函数或一个专门的Initialize方法里传递必要参数更直接。5.3 问题三多个转换条件同时满足状态切换不稳定现象一帧内有多个转换条件同时为真状态可能发生多次切换或者切换到非预期的状态。原因状态机在每帧遍历所有转换条件时没有定义优先级或者条件检查的顺序有误。解决方案定义转换优先级在TransitionBase基类中增加一个Priority属性。状态机在检查转换时先按优先级排序只执行优先级最高且条件满足的转换。顺序检查在状态类内部管理转换时比如在OnUpdate里写多个if将最特殊、范围最小的条件放在前面判断。例如“在攻击范围内”比“看到玩家”更特殊应该先判断。如果先判断“看到玩家”就切到追击那么即使进入了攻击范围也因为已经不在巡逻状态的OnUpdate里而无法切换到攻击。使用状态转换图工具对于非常复杂的状态机可以考虑在编辑器里绘制状态转换图并明确每条边的优先级然后通过工具生成代码。这能从根本上避免逻辑冲突。5.4 问题四黑板数据管理混乱现象不同的状态往黑板里存了同名但类型不同的数据导致取用时类型转换失败或者状态结束后忘记清理数据干扰了后续逻辑。解决方案严格的键名管理如前所述使用静态类定义所有可能的键名。类型安全的存取方法我们的GetBlackboardValueT已经做了基础的类型检查。可以进一步加强在Set时也记录类型在Get时进行更严格的类型匹配。状态生命周期绑定清理可以考虑在状态的OnExit方法中清理掉由本状态创建的黑板数据。但这需要谨慎设计因为有些数据可能是为下一个状态准备的。一个更清晰的做法是约定数据的生产者负责清理。或者将黑板的生命周期与状态机绑定状态机重置时清空所有数据。5.5 性能优化小贴士避免每帧Find和GetComponent在状态的OnEnter或构造函数中缓存需要的引用Transform、Rigidbody、Animator等而不是在OnUpdate里频繁调用GetComponent或GameObject.Find。转换条件检查的优化不是所有转换条件都需要每帧检查。例如“冷却时间是否结束”这种条件可以用协程或计时器触发而不是每帧去读Time.time。对于距离判断可以每N帧检查一次而不是每帧。状态对象的复用如果状态是无状态的即不保存随时间变化的成员变量或者可以很容易地重置那么可以考虑使用对象池来复用状态实例避免频繁的GC Alloc。但对于大多数游戏状态数量有限这点优化收益不大优先保证代码清晰。从零搭建一个FSM框架的过程本身就是对状态模式最深刻的学习。它强迫你去思考状态如何划分、如何通信、如何优雅地切换。当你亲手实现并调试通过后再去使用Asset Store里那些功能强大的FSM插件如PlayMaker、NodeCanvas时你会更清楚它们底层在做什么也能更好地利用它们。这个自建的轻量框架足以应对项目中80%的状态管理需求并且因为完全受你控制调试和扩展都极其方便。下次当你的Update里又开始出现一堆控制状态的bool标志时不妨停下来想想是不是该请出FSM这位老朋友了。
