1. 项目概述为什么状态模式是Unity开发者的必修课在Unity项目里尤其是游戏开发中你有没有遇到过这样的场景一个角色有“待机”、“行走”、“攻击”、“受伤”、“死亡”等多种行为。新手最常见的做法是在Update里写一个巨大的switch或者一堆if-else来判断当前应该执行哪个行为。代码写着写着Update函数就变成了几百行的“意大利面条”增加一个新状态比如“跳跃”或者修改一个旧状态比如“攻击”要增加蓄力判定都变得战战兢兢生怕牵一发而动全身。这种代码的维护成本会随着项目规模呈指数级增长。这正是状态模式State Pattern要解决的核心问题。它不是什么高深莫测的“黑科技”而是一种经过时间检验的、用来管理对象行为随其内部状态改变而改变的优雅设计模式。简单来说状态模式的核心思想是“将状态抽象为对象”。不再是使用枚举或标志位在控制器里硬编码逻辑而是为每一种状态都创建一个独立的类。当对象的状态改变时它仅仅是切换到自己持有的另一个状态对象的引用然后由这个新的状态对象来决定接下来该做什么。对于C#和Unity开发者而言掌握状态模式几乎是进阶的必经之路。Unity的Animator控制器本质上就是一个可视化的有限状态机FSM而状态模式是构建复杂、可维护的FSM的代码基石。无论是角色的AI行为、UI界面的切换如主菜单、设置、游戏内界面、还是游戏流程的管理加载、运行、暂停、结束状态模式都能让代码结构变得清晰、可扩展。理解了它你就能写出更健壮、更易协作的代码告别“屎山”拥抱“优雅”。2. 状态模式的核心思想与结构拆解2.1 从“过程判断”到“对象委托”的思维转变要理解状态模式首先要跳出“用条件语句控制状态”的思维定式。我们通过一个简单的玩家控制器例子来对比。传统做法过程判断public class BadPlayerController : MonoBehaviour { public enum PlayerState { Idle, Walking, Attacking } public PlayerState currentState; void Update() { switch (currentState) { case PlayerState.Idle: // 检测输入切换到Walking // 播放待机动画 break; case PlayerState.Walking: // 处理移动逻辑 // 检测输入切换到Attacking或Idle // 播放行走动画 break; case PlayerState.Attacking: // 播放攻击动画 // 检测伤害框 // 动画结束后切换回Idle break; } } }这段代码的问题显而易见所有状态的逻辑都挤在同一个类的一个方法里。增加“跳跃”状态你得在enum里加枚举在switch里加case可能还要修改其他case里的转换条件。逻辑耦合严重Update方法会越来越臃肿。状态模式做法对象委托状态模式将每个case里的逻辑抽离成一个独立的类。我们定义一个所有状态类的共同接口或抽象类约定它们都必须实现“进入状态”、“状态更新”、“离开状态”等方法。原来的控制器称为Context不再关心具体逻辑它只持有一个当前状态对象的引用并把Update等Unity消息委托给这个状态对象去执行。当需要切换状态时控制器只是简单地更换这个引用。2.2 状态模式的经典UML结构与C#实现状态模式通常包含三个核心角色Context上下文定义客户端感兴趣的接口。它维护一个ConcreteState子类的实例这个实例定义了当前状态。State状态抽象定义一个接口用以封装与Context的一个特定状态相关的行为。ConcreteState具体状态每一个子类实现一个与Context的一个状态相关的行为。用C#代码来体现这个结构// 1. State 抽象状态接口 public interface IPlayerState { void Enter(PlayerController player); // 进入该状态 void Execute(PlayerController player); // 状态更新相当于Update void Exit(PlayerController player); // 退出该状态 } // 2. ConcreteState 具体状态类 public class IdleState : IPlayerState { public void Enter(PlayerController player) { Debug.Log(进入待机状态); player.animator.Play(Idle); } public void Execute(PlayerController player) { // 在Update中判断如果有移动输入则切换到WalkState if (Input.GetAxisRaw(Horizontal) ! 0) { player.ChangeState(new WalkState()); } } public void Exit(PlayerController player) { Debug.Log(退出待机状态); } } public class WalkState : IPlayerState { public void Enter(PlayerController player) { /* ... */ } public void Execute(PlayerController player) { // 处理移动 float move Input.GetAxisRaw(Horizontal) * player.moveSpeed; player.rigidbody2D.velocity new Vector2(move, player.rigidbody2D.velocity.y); // 状态转换判断 if (move 0) player.ChangeState(new IdleState()); if (Input.GetButtonDown(Fire1)) player.ChangeState(new AttackState()); } public void Exit(PlayerController player) { /* ... */ } } // 3. Context 上下文类 public class PlayerController : MonoBehaviour { private IPlayerState _currentState; public Animator animator; public Rigidbody2D rigidbody2D; public float moveSpeed 5f; void Start() { // 初始状态 _currentState new IdleState(); _currentState.Enter(this); } void Update() { // 将Update委托给当前状态对象 _currentState?.Execute(this); } // 状态切换方法 public void ChangeState(IPlayerState newState) { _currentState?.Exit(this); _currentState newState; _currentState?.Enter(this); } }注意上面的示例中状态转换的判断逻辑写在具体状态的Execute方法里。这是一种常见做法但有时会导致状态类之间产生依赖例如WalkState需要知道IdleState和AttackState的存在。更解耦的做法是让ContextPlayerController来管理转换规则或者使用一个专门的“状态转换表”。我们会在后续章节详细讨论。2.3 状态模式与有限状态机FSM的关系很多人会混淆状态模式和有限状态机。你可以这样理解状态模式是实现有限状态机的一种优雅的面向对象编程方法。有限状态机是一个数学模型它包含一组状态、一组触发状态转换的事件/条件、以及状态转换时执行的动作。Unity的Animator就是一个典型的FSM。当我们用代码实现FSM时状态模式提供了一种将每个“状态”及其“进入/退出动作”、“更新逻辑”封装成独立类的优秀架构使得FSM的代码结构清晰、易于扩展。没有状态模式你当然也能用enum和switch实现一个FSM但代码的可维护性会差很多。状态模式是让FSM代码“工业级”、“可维护”的关键。3. 在Unity中实现状态模式的四种实战策略了解了基础结构我们来看看在Unity工程中具体如何应用。根据项目复杂度和团队习惯有几种不同的实现策略。3.1 策略一基础接口实现适合简单场景这就是我们上面示例代码所用的方法。定义一个IState接口所有具体状态类实现它。Context类通常是MonoBehaviour持有当前状态引用。优点结构简单直观易于理解。状态逻辑完全隔离符合单一职责原则。缺点与注意事项状态转换耦合如之前所述如果状态类自己决定下一个状态是什么在Execute里调用player.ChangeState那么WalkState类就需要引用IdleState和AttackState。这增加了状态类之间的编译依赖。对于小型项目没问题但状态很多时修改一个状态类可能会引发广泛的重新编译。状态实例管理每次切换状态都new一个新的状态对象如new IdleState()。如果状态对象无状态即没有成员变量且创建开销小这没问题。但如果状态初始化复杂或者状态本身需要保存一些数据比如“攻击状态”需要记录连击次数频繁创建销毁可能带来性能或逻辑问题。此时可以考虑使用对象池或让状态成为单例如果状态无实例数据。3.2 策略二使用抽象基类与Unity生命周期集成在Unity中我们经常需要用到Start、Update、FixedUpdate、OnTriggerEnter等消息方法。我们可以创建一个抽象的MonoState基类它继承自MonoBehaviour这样每个状态都可以直接挂载到GameObject上并能接收Unity消息。public abstract class MonoState : MonoBehaviour { protected PlayerController context; // 持有上下文引用 public virtual void Init(PlayerController context) { this.context context; } public abstract void Enter(); public abstract void Execute(); public abstract void Exit(); // 可以在这里添加 OnTriggerEnter2D, OnCollisionEnter 等虚方法子状态按需重写 } public class PlayerController : MonoBehaviour { private MonoState _currentState; public void ChangeState(MonoState newState) { _currentState?.Exit(); _currentState newState; _currentState.Init(this); _currentState.Enter(); } void Update() { _currentState?.Execute(); } }优点状态类可以方便地使用Unity的所有功能包括协程Coroutine、物理回调等。状态可以作为Prefab或组件进行可视化编辑和管理。缺点每个状态都是一个MonoBehaviour会带来一定的运行时开销虽然很小。状态切换时需要处理GameObject的启用/禁用或组件enabled属性的切换逻辑稍显复杂。3.3 策略三泛型状态机增强类型安全与上下文绑定这是一种更高级、更类型安全的实现。我们创建一个泛型状态机类它绑定了特定的上下文类型。同时状态类也通过泛型参数知道它属于哪个上下文。// 泛型状态接口 public interface IStateT where T : class { void Enter(T entity); void Execute(T entity); void Exit(T entity); } // 泛型状态机 public class StateMachineT where T : class { private T _owner; private IStateT _currentState; private IStateT _previousState; // 可选记录上一个状态方便回退 public StateMachine(T owner) { _owner owner; } public void ChangeState(IStateT newState) { _previousState _currentState; _currentState?.Exit(_owner); _currentState newState; _currentState?.Enter(_owner); } public void Update() { _currentState?.Execute(_owner); } public IStateT CurrentState _currentState; public IStateT PreviousState _previousState; } // 使用示例 public class Enemy : MonoBehaviour { public StateMachineEnemy stateMachine; void Start() { stateMachine new StateMachineEnemy(this); stateMachine.ChangeState(new PatrolState()); } void Update() { stateMachine.Update(); } } public class PatrolState : IStateEnemy { public void Enter(Enemy enemy) { /* ... */ } public void Execute(Enemy enemy) { // 巡逻逻辑 // 可以直接访问enemy的成员如 enemy.transform, enemy.PlayerInSight() if (enemy.PlayerInSight()) { enemy.stateMachine.ChangeState(new ChaseState()); } } public void Exit(Enemy enemy) { /* ... */ } }优点极强的类型安全PatrolState的Execute方法明确接收一个Enemy类型的参数你可以安全地调用enemy的所有公共方法无需类型转换。复用性高StateMachineT是一个完全通用的类可以用于任何需要状态机的实体玩家、敌人、UI管理器、游戏管理器等。上下文清晰每个状态都知道自己在为谁工作代码意图明确。缺点泛型语法对初学者可能稍有门槛。状态转换逻辑仍然写在状态内部耦合问题依旧存在。3.4 策略四基于ScriptableObject的数据驱动状态高级架构这是Unity中一种非常强大且优雅的模式尤其适合大型项目或需要策划/设计师参与状态配置的情况。其核心思想是将状态逻辑Enter,Execute,Exit仍然写在普通的C#类中但将状态之间的转换规则、条件判断等“数据”剥离出来创建为ScriptableObject资产。创建状态SO基类public abstract class StateSO : ScriptableObject { public abstract void Enter(Character character); public abstract void Execute(Character character); public abstract void Exit(Character character); }创建具体状态SO[CreateAssetMenu(fileName IdleState, menuName Character States/Idle)] public class IdleStateSO : StateSO { public float someConfigValue; // 可以在Inspector中配置的参数 public override void Enter(Character character) { /* ... */ } public override void Execute(Character character) { // 执行逻辑但**不直接决定下一个状态** } public override void Exit(Character character) { /* ... */ } }创建状态转换SO[CreateAssetMenu(fileName Transition, menuName Character States/Transition)] public class StateTransitionSO : ScriptableObject { public StateSO fromState; public StateSO toState; public ConditionSO condition; // 条件也是一个SO如“按键按下”、“距离小于X” }在Character中管理public class Character : MonoBehaviour { public StateSO currentState; public ListStateTransitionSO transitions; // 所有可能的转换 void Update() { currentState.Execute(this); // 遍历transitions找到从currentState出发且条件满足的转换 foreach(var trans in transitions) { if(trans.fromState currentState trans.condition.IsMet(this)) { currentState.Exit(this); currentState trans.toState; currentState.Enter(this); break; } } } }优点高度可配置策划可以在Unity编辑器中拖拽配置状态和转换无需修改代码。热重载友好修改ScriptableObject的数据在Play模式下可以立即生效。逻辑与数据分离状态逻辑代码和转换规则数据清晰分离架构干净。缺点架构复杂度最高需要预先设计好ConditionSO等系统。运行时状态切换的性能开销可能略高于纯代码方式需要遍历列表查找但对于大多数游戏来说可以接受。实操心得对于中小型项目或原型开发从**策略一基础接口或策略三泛型状态机**开始是最快最有效的。当项目规模扩大状态逻辑变得复杂且需要非程序员参与调整时**策略四ScriptableObject驱动**的优势将无可比拟。我个人的项目演进路径通常是策略一 - 策略三 - 策略四。4. 状态模式在Unity中的高级应用与性能优化4.1 管理复杂状态转换状态转换表与条件解耦在基础实现中状态转换逻辑散落在各个状态的Execute方法里这被称作“分布式状态转换”。它的缺点是状态类之间相互了解耦合度高。一个更集中的方法是使用状态转换表State Transition Table。我们可以在Context如PlayerController中维护一个字典或列表定义所有合法的状态转换及其条件。public class PlayerController : MonoBehaviour { private IPlayerState _currentState; private DictionarySystem.Type, ListTransition _transitions new DictionarySystem.Type, ListTransition(); void Start() { // 初始化转换表 RegisterTransition(typeof(IdleState), typeof(WalkState), () Input.GetAxisRaw(Horizontal) ! 0); RegisterTransition(typeof(WalkState), typeof(IdleState), () Input.GetAxisRaw(Horizontal) 0); RegisterTransition(typeof(WalkState), typeof(AttackState), () Input.GetButtonDown(Fire1)); RegisterTransition(typeof(AttackState), typeof(IdleState), () _attackAnimationFinished); // ... 注册更多转换 _currentState new IdleState(); _currentState.Enter(this); } void Update() { _currentState.Execute(this); // 集中处理转换 CheckForTransitions(); } private void CheckForTransitions() { var currentStateType _currentState.GetType(); if (_transitions.TryGetValue(currentStateType, out var possibleTransitions)) { foreach (var trans in possibleTransitions) { if (trans.condition()) { ChangeState(trans.toState); break; } } } } private void RegisterTransition(System.Type from, System.Type to, System.Funcbool condition) { if (!_transitions.ContainsKey(from)) _transitions[from] new ListTransition(); _transitions[from].Add(new Transition { toState to, condition condition }); } private class Transition { public System.Type toState; public System.Funcbool condition; } }这样具体状态类如IdleState的Execute方法就只需要专注于“在待机状态下该做什么”而无需关心“什么时候、为什么切换到行走状态”。转换逻辑被集中管理修改和调试都更加方便。条件Funcbool可以使用Lambda表达式也可以封装成独立的Condition类实现更复杂的判断逻辑。4.2 状态模式与Unity动画系统的深度集成Unity的Animator本身就是一个状态机。我们完全可以将代码逻辑状态与动画状态机绑定实现“代码驱动动画动画反馈代码”的闭环。代码状态同步到Animator参数在每个状态类的Enter方法中设置对应的Animator参数Trigger、Bool等触发动画状态切换。public class AttackState : IPlayerState { public void Enter(PlayerController player) { player.animator.SetTrigger(Attack); // 触发动画状态机中的Attack过渡 } }使用动画事件Animation Events反馈给代码在攻击动画的特定帧如武器挥到最高点时添加动画事件调用PlayerController上的一个方法。这个方法可以触发伤害判定、播放音效甚至触发状态转换例如动画结束后自动切回Idle。// 在Animation Event中调用的方法 public void OnAttackAnimationEnd() { // 可以在这里直接切换状态或者设置一个标志位在状态的Execute中检查 _attackAnimationFinished true; }使用Animator State Machine Behaviours这是一个更强大的集成方式。你可以创建一个继承自StateMachineBehaviour的脚本挂载到Animator的某个动画状态上。这个脚本可以重写OnStateEnter、OnStateUpdate、OnStateExit等方法它们会在动画状态进入、更新、退出时被调用。你可以在这里面调用PlayerController的逻辑实现动画与游戏逻辑的强关联。4.3 性能考量与优化技巧状态模式本身带来的性能开销微乎其微主要是虚方法调用和对象引用切换。性能瓶颈通常出现在不恰当的实现上。避免在状态类的Execute中每帧进行昂贵的计算或查找例如在PatrolState中不要每帧都用Physics2D.OverlapCircle来寻找玩家。应该使用协程Coroutine或定时器每隔几秒检查一次。public class PatrolState : IStateEnemy { private Coroutine _checkPlayerCoroutine; public void Enter(Enemy enemy) { _checkPlayerCoroutine enemy.StartCoroutine(CheckForPlayer(enemy)); } IEnumerator CheckForPlayer(Enemy enemy) { while(true) { if (Physics2D.OverlapCircle(enemy.transform.position, enemy.sightRange, enemy.playerLayer)) { enemy.stateMachine.ChangeState(new ChaseState()); yield break; // 发现玩家结束协程 } yield return new WaitForSeconds(0.5f); // 每0.5秒检查一次而不是每帧 } } public void Exit(Enemy enemy) { if(_checkPlayerCoroutine ! null) enemy.StopCoroutine(_checkPlayerCoroutine); } }状态对象的创建与缓存如果状态类是无状态的没有成员变量可以将其实现为单例避免频繁的new操作。public class IdleState : IPlayerState { // 静态实例 public static readonly IdleState Instance new IdleState(); // 私有构造函数防止外部new private IdleState() {} public void Enter(PlayerController player) { /* ... */ } public void Execute(PlayerController player) { /* ... */ } public void Exit(PlayerController player) { /* ... */ } } // 使用时 player.ChangeState(IdleState.Instance);如果状态类需要持有数据例如AttackState需要记录连击数则不能使用单例此时可以考虑简单的对象池来复用状态对象。减少状态转换频率频繁的状态转换比如每帧在Idle和Walk之间快速切换可能带来不必要的开销调用Enter/Exit。可以通过增加转换条件缓冲Hysteresis来解决。例如从Walk切换到Idle的条件不是“速度0”而是“速度持续小于0.1f超过0.2秒”。5. 实战构建一个完整的敌人AI有限状态机让我们综合运用以上知识构建一个经典的敌人AI它会在巡逻点之间巡逻发现玩家后追击进入攻击范围后攻击丢失玩家视线后返回巡逻。5.1 定义状态与上下文首先定义状态接口和敌人上下文。// IEnemyState.cs public interface IEnemyState { void Enter(EnemyAI enemy); void Execute(EnemyAI enemy); void Exit(EnemyAI enemy); } // EnemyAI.cs (Context) public class EnemyAI : MonoBehaviour { public StateMachineEnemyAI StateMachine { get; private set; } public Animator Animator { get; private set; } public Transform Player { get; set; } // 通过其他系统如触发器赋值 public Transform[] PatrolPoints; public float ChaseSpeed 6f; public float PatrolSpeed 2f; public float AttackRange 1.5f; public float SightRange 10f; private int _currentPatrolIndex 0; void Start() { Animator GetComponentAnimator(); StateMachine new StateMachineEnemyAI(this); StateMachine.ChangeState(PatrolState.Instance); // 初始化为巡逻状态 } void Update() { StateMachine.Update(); } // 辅助方法获取下一个巡逻点 public Transform GetNextPatrolPoint() { _currentPatrolIndex (_currentPatrolIndex 1) % PatrolPoints.Length; return PatrolPoints[_currentPatrolIndex]; } public Transform GetCurrentPatrolPoint() PatrolPoints[_currentPatrolIndex]; }5.2 实现具体状态类巡逻状态 (PatrolState):public class PatrolState : IEnemyState { public static PatrolState Instance new PatrolState(); private PatrolState() {} private Transform _targetPoint; public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入巡逻状态); enemy.Animator.SetBool(IsWalking, true); _targetPoint enemy.GetCurrentPatrolPoint(); } public void Execute(EnemyAI enemy) { // 1. 巡逻移动逻辑 Vector2 direction (_targetPoint.position - enemy.transform.position).normalized; enemy.transform.position (Vector3)direction * enemy.PatrolSpeed * Time.deltaTime; // 到达巡逻点附近切换下一个点 if (Vector2.Distance(enemy.transform.position, _targetPoint.position) 0.5f) { _targetPoint enemy.GetNextPatrolPoint(); } // 2. 状态转换判断发现玩家 if (enemy.Player ! null Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { enemy.StateMachine.ChangeState(ChaseState.Instance); } } public void Exit(EnemyAI enemy) { enemy.Animator.SetBool(IsWalking, false); } }追击状态 (ChaseState):public class ChaseState : IEnemyState { public static ChaseState Instance new ChaseState(); private ChaseState() {} public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入追击状态); enemy.Animator.SetBool(IsRunning, true); } public void Execute(EnemyAI enemy) { if (enemy.Player null) { enemy.StateMachine.ChangeState(PatrolState.Instance); return; } // 向玩家移动 Vector2 direction (enemy.Player.position - enemy.transform.position).normalized; enemy.transform.position (Vector3)direction * enemy.ChaseSpeed * Time.deltaTime; // 转换判断1进入攻击范围 if (Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.AttackRange) { enemy.StateMachine.ChangeState(AttackState.Instance); } // 转换判断2丢失玩家玩家跑出视线范围 else if (Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { enemy.Player null; // 清空目标 enemy.StateMachine.ChangeState(PatrolState.Instance); } } public void Exit(EnemyAI enemy) { enemy.Animator.SetBool(IsRunning, false); } }攻击状态 (AttackState):public class AttackState : IEnemyState { public static AttackState Instance new AttackState(); private AttackState() {} private float _attackCooldown 2f; private float _lastAttackTime; public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入攻击状态); enemy.Animator.SetTrigger(Attack); _lastAttackTime Time.time; // 立即执行一次攻击逻辑 TryAttack(enemy); } public void Execute(EnemyAI enemy) { // 攻击冷却判断 if (Time.time - _lastAttackTime _attackCooldown) { TryAttack(enemy); } // 状态转换玩家是否还在攻击范围内 if (enemy.Player null || Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.AttackRange) { if (enemy.Player ! null Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { // 玩家还在视线内但跑出了攻击范围切回追击 enemy.StateMachine.ChangeState(ChaseState.Instance); } else { // 玩家完全丢失切回巡逻 enemy.Player null; enemy.StateMachine.ChangeState(PatrolState.Instance); } } } private void TryAttack(EnemyAI enemy) { if (enemy.Player ! null) { // 这里执行攻击伤害判定例如调用 enemy.Player.GetComponentHealth().TakeDamage(10); Debug.Log($Enemy 攻击了玩家); _lastAttackTime Time.time; enemy.Animator.SetTrigger(Attack); // 再次触发攻击动画 } } public void Exit(EnemyAI enemy) { // 清理工作 } }5.3 添加玩家检测触发器为了让敌人“发现”玩家我们通常使用触发器Trigger或射线检测Raycast。这里用一个简单的触发器示例public class EnemySightTrigger : MonoBehaviour { public EnemyAI enemyAI; void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag(Player)) { enemyAI.Player other.transform; } } void OnTriggerExit2D(Collider2D other) { if (other.CompareTag(Player)) { // 注意不在触发器内不代表丢失视线追击状态会自己判断距离。 // 这里可以不做处理或者设置一个标志。 } } }将这个脚本挂到敌人身上一个较大的圆形触发器上并赋值enemyAI引用。当玩家进入触发器EnemyAI的Player属性被赋值巡逻状态检测到后就会切换到追击状态。6. 常见陷阱、调试技巧与扩展方向6.1 新手常踩的坑与解决方案状态循环或状态爆炸问题在A状态的Execute里无条件切换到B状态B状态的Execute里又无条件切回A状态导致每帧都在两个状态间疯狂切换。解决确保状态转换条件是有明确逻辑的并且通常需要某种“延迟”或“条件不满足的持续判断”。例如从“攻击”切回“待机”需要等待“攻击动画播放完毕”这个事件而不是在攻击状态的第一帧就判断。忘记调用Exit或Enter方法问题在ChangeState时只设置了新状态忘了调用旧状态的Exit和新状态的Enter。这会导致状态清理和初始化逻辑丢失比如动画参数没重置、协程没停止。解决将状态切换逻辑封装在一个方法里如我们一直做的ChangeState并严格遵守“先Exit旧状态再Enter新状态”的顺序。在状态类的Execute中处理所有输入问题在AttackState的Execute里还检测跳跃按键导致角色在攻击时也能跳起来这可能不符合设计。解决明确每个状态能响应的输入。通常输入检测可以放在Context的Update里然后根据当前状态决定是否处理。或者在每个状态的Execute里只检测与本状态相关的、能触发状态转换的输入。状态类持有对Context的非法引用问题在状态类的Enter方法中将Context的引用保存到一个静态变量或全局变量中导致状态机混乱。解决状态类只应通过Context参数访问它需要的数据。生命周期应和Context绑定避免产生游离的引用。6.2 状态机的调试与可视化调试状态机时最需要知道的就是“当前是什么状态”。有几种方法在Inspector中显示在Context的OnGUI或自定义Editor脚本中显示当前状态名。void OnGUI() { GUI.Label(new Rect(10, 10, 200, 20), $当前状态: {StateMachine.CurrentState?.GetType().Name}); }使用Unity的Debug.Log在每个状态的Enter和Exit方法中加入日志。自定义编辑器窗口创建一个EditorWindow遍历场景中所有状态机实体以树状图或列表形式展示其状态栈和转换条件。这对于调试复杂AI非常有用。6.3 状态模式的扩展层次状态机与下推自动机基础状态机有时不够用可以考虑更高级的变体层次状态机Hierarchical State Machine, HSM允许状态有父子关系。子状态可以继承并覆盖父状态的行为。例如可以有一个“移动”父状态包含“行走”、“奔跑”、“蹲走”等子状态。所有子状态共享“移动”的公共逻辑如应用重力但又有自己的特殊逻辑。这能极大减少重复代码。下推自动机Pushdown Automaton状态机带有一个栈。当你进入一个新状态时不是替换当前状态而是将其“压入”栈顶。当新状态退出时它被“弹出”状态机恢复到之前栈顶的状态。这对于实现“菜单系统”打开子菜单后能返回上级或“角色被打断”从任何状态进入“受伤”状态受伤结束后回到之前的状态非常完美。实现这些高级状态机超出了本文的范围但网上有众多优秀的开源实现如UnityHSM、PushdownAutomaton等。当你发现基础状态模式写起来开始重复或别扭时就是考虑引入它们的时候了。状态模式不是银弹但它为管理复杂的行为逻辑提供了一个坚实、清晰的框架。在Unity开发中从简单的角色控制到复杂的游戏管理器它都是不可或缺的设计工具。花时间理解和实践它你的代码质量和开发效率都会获得显著的提升。
Unity状态模式实战：告别if-else，构建可维护的游戏AI与角色控制
1. 项目概述为什么状态模式是Unity开发者的必修课在Unity项目里尤其是游戏开发中你有没有遇到过这样的场景一个角色有“待机”、“行走”、“攻击”、“受伤”、“死亡”等多种行为。新手最常见的做法是在Update里写一个巨大的switch或者一堆if-else来判断当前应该执行哪个行为。代码写着写着Update函数就变成了几百行的“意大利面条”增加一个新状态比如“跳跃”或者修改一个旧状态比如“攻击”要增加蓄力判定都变得战战兢兢生怕牵一发而动全身。这种代码的维护成本会随着项目规模呈指数级增长。这正是状态模式State Pattern要解决的核心问题。它不是什么高深莫测的“黑科技”而是一种经过时间检验的、用来管理对象行为随其内部状态改变而改变的优雅设计模式。简单来说状态模式的核心思想是“将状态抽象为对象”。不再是使用枚举或标志位在控制器里硬编码逻辑而是为每一种状态都创建一个独立的类。当对象的状态改变时它仅仅是切换到自己持有的另一个状态对象的引用然后由这个新的状态对象来决定接下来该做什么。对于C#和Unity开发者而言掌握状态模式几乎是进阶的必经之路。Unity的Animator控制器本质上就是一个可视化的有限状态机FSM而状态模式是构建复杂、可维护的FSM的代码基石。无论是角色的AI行为、UI界面的切换如主菜单、设置、游戏内界面、还是游戏流程的管理加载、运行、暂停、结束状态模式都能让代码结构变得清晰、可扩展。理解了它你就能写出更健壮、更易协作的代码告别“屎山”拥抱“优雅”。2. 状态模式的核心思想与结构拆解2.1 从“过程判断”到“对象委托”的思维转变要理解状态模式首先要跳出“用条件语句控制状态”的思维定式。我们通过一个简单的玩家控制器例子来对比。传统做法过程判断public class BadPlayerController : MonoBehaviour { public enum PlayerState { Idle, Walking, Attacking } public PlayerState currentState; void Update() { switch (currentState) { case PlayerState.Idle: // 检测输入切换到Walking // 播放待机动画 break; case PlayerState.Walking: // 处理移动逻辑 // 检测输入切换到Attacking或Idle // 播放行走动画 break; case PlayerState.Attacking: // 播放攻击动画 // 检测伤害框 // 动画结束后切换回Idle break; } } }这段代码的问题显而易见所有状态的逻辑都挤在同一个类的一个方法里。增加“跳跃”状态你得在enum里加枚举在switch里加case可能还要修改其他case里的转换条件。逻辑耦合严重Update方法会越来越臃肿。状态模式做法对象委托状态模式将每个case里的逻辑抽离成一个独立的类。我们定义一个所有状态类的共同接口或抽象类约定它们都必须实现“进入状态”、“状态更新”、“离开状态”等方法。原来的控制器称为Context不再关心具体逻辑它只持有一个当前状态对象的引用并把Update等Unity消息委托给这个状态对象去执行。当需要切换状态时控制器只是简单地更换这个引用。2.2 状态模式的经典UML结构与C#实现状态模式通常包含三个核心角色Context上下文定义客户端感兴趣的接口。它维护一个ConcreteState子类的实例这个实例定义了当前状态。State状态抽象定义一个接口用以封装与Context的一个特定状态相关的行为。ConcreteState具体状态每一个子类实现一个与Context的一个状态相关的行为。用C#代码来体现这个结构// 1. State 抽象状态接口 public interface IPlayerState { void Enter(PlayerController player); // 进入该状态 void Execute(PlayerController player); // 状态更新相当于Update void Exit(PlayerController player); // 退出该状态 } // 2. ConcreteState 具体状态类 public class IdleState : IPlayerState { public void Enter(PlayerController player) { Debug.Log(进入待机状态); player.animator.Play(Idle); } public void Execute(PlayerController player) { // 在Update中判断如果有移动输入则切换到WalkState if (Input.GetAxisRaw(Horizontal) ! 0) { player.ChangeState(new WalkState()); } } public void Exit(PlayerController player) { Debug.Log(退出待机状态); } } public class WalkState : IPlayerState { public void Enter(PlayerController player) { /* ... */ } public void Execute(PlayerController player) { // 处理移动 float move Input.GetAxisRaw(Horizontal) * player.moveSpeed; player.rigidbody2D.velocity new Vector2(move, player.rigidbody2D.velocity.y); // 状态转换判断 if (move 0) player.ChangeState(new IdleState()); if (Input.GetButtonDown(Fire1)) player.ChangeState(new AttackState()); } public void Exit(PlayerController player) { /* ... */ } } // 3. Context 上下文类 public class PlayerController : MonoBehaviour { private IPlayerState _currentState; public Animator animator; public Rigidbody2D rigidbody2D; public float moveSpeed 5f; void Start() { // 初始状态 _currentState new IdleState(); _currentState.Enter(this); } void Update() { // 将Update委托给当前状态对象 _currentState?.Execute(this); } // 状态切换方法 public void ChangeState(IPlayerState newState) { _currentState?.Exit(this); _currentState newState; _currentState?.Enter(this); } }注意上面的示例中状态转换的判断逻辑写在具体状态的Execute方法里。这是一种常见做法但有时会导致状态类之间产生依赖例如WalkState需要知道IdleState和AttackState的存在。更解耦的做法是让ContextPlayerController来管理转换规则或者使用一个专门的“状态转换表”。我们会在后续章节详细讨论。2.3 状态模式与有限状态机FSM的关系很多人会混淆状态模式和有限状态机。你可以这样理解状态模式是实现有限状态机的一种优雅的面向对象编程方法。有限状态机是一个数学模型它包含一组状态、一组触发状态转换的事件/条件、以及状态转换时执行的动作。Unity的Animator就是一个典型的FSM。当我们用代码实现FSM时状态模式提供了一种将每个“状态”及其“进入/退出动作”、“更新逻辑”封装成独立类的优秀架构使得FSM的代码结构清晰、易于扩展。没有状态模式你当然也能用enum和switch实现一个FSM但代码的可维护性会差很多。状态模式是让FSM代码“工业级”、“可维护”的关键。3. 在Unity中实现状态模式的四种实战策略了解了基础结构我们来看看在Unity工程中具体如何应用。根据项目复杂度和团队习惯有几种不同的实现策略。3.1 策略一基础接口实现适合简单场景这就是我们上面示例代码所用的方法。定义一个IState接口所有具体状态类实现它。Context类通常是MonoBehaviour持有当前状态引用。优点结构简单直观易于理解。状态逻辑完全隔离符合单一职责原则。缺点与注意事项状态转换耦合如之前所述如果状态类自己决定下一个状态是什么在Execute里调用player.ChangeState那么WalkState类就需要引用IdleState和AttackState。这增加了状态类之间的编译依赖。对于小型项目没问题但状态很多时修改一个状态类可能会引发广泛的重新编译。状态实例管理每次切换状态都new一个新的状态对象如new IdleState()。如果状态对象无状态即没有成员变量且创建开销小这没问题。但如果状态初始化复杂或者状态本身需要保存一些数据比如“攻击状态”需要记录连击次数频繁创建销毁可能带来性能或逻辑问题。此时可以考虑使用对象池或让状态成为单例如果状态无实例数据。3.2 策略二使用抽象基类与Unity生命周期集成在Unity中我们经常需要用到Start、Update、FixedUpdate、OnTriggerEnter等消息方法。我们可以创建一个抽象的MonoState基类它继承自MonoBehaviour这样每个状态都可以直接挂载到GameObject上并能接收Unity消息。public abstract class MonoState : MonoBehaviour { protected PlayerController context; // 持有上下文引用 public virtual void Init(PlayerController context) { this.context context; } public abstract void Enter(); public abstract void Execute(); public abstract void Exit(); // 可以在这里添加 OnTriggerEnter2D, OnCollisionEnter 等虚方法子状态按需重写 } public class PlayerController : MonoBehaviour { private MonoState _currentState; public void ChangeState(MonoState newState) { _currentState?.Exit(); _currentState newState; _currentState.Init(this); _currentState.Enter(); } void Update() { _currentState?.Execute(); } }优点状态类可以方便地使用Unity的所有功能包括协程Coroutine、物理回调等。状态可以作为Prefab或组件进行可视化编辑和管理。缺点每个状态都是一个MonoBehaviour会带来一定的运行时开销虽然很小。状态切换时需要处理GameObject的启用/禁用或组件enabled属性的切换逻辑稍显复杂。3.3 策略三泛型状态机增强类型安全与上下文绑定这是一种更高级、更类型安全的实现。我们创建一个泛型状态机类它绑定了特定的上下文类型。同时状态类也通过泛型参数知道它属于哪个上下文。// 泛型状态接口 public interface IStateT where T : class { void Enter(T entity); void Execute(T entity); void Exit(T entity); } // 泛型状态机 public class StateMachineT where T : class { private T _owner; private IStateT _currentState; private IStateT _previousState; // 可选记录上一个状态方便回退 public StateMachine(T owner) { _owner owner; } public void ChangeState(IStateT newState) { _previousState _currentState; _currentState?.Exit(_owner); _currentState newState; _currentState?.Enter(_owner); } public void Update() { _currentState?.Execute(_owner); } public IStateT CurrentState _currentState; public IStateT PreviousState _previousState; } // 使用示例 public class Enemy : MonoBehaviour { public StateMachineEnemy stateMachine; void Start() { stateMachine new StateMachineEnemy(this); stateMachine.ChangeState(new PatrolState()); } void Update() { stateMachine.Update(); } } public class PatrolState : IStateEnemy { public void Enter(Enemy enemy) { /* ... */ } public void Execute(Enemy enemy) { // 巡逻逻辑 // 可以直接访问enemy的成员如 enemy.transform, enemy.PlayerInSight() if (enemy.PlayerInSight()) { enemy.stateMachine.ChangeState(new ChaseState()); } } public void Exit(Enemy enemy) { /* ... */ } }优点极强的类型安全PatrolState的Execute方法明确接收一个Enemy类型的参数你可以安全地调用enemy的所有公共方法无需类型转换。复用性高StateMachineT是一个完全通用的类可以用于任何需要状态机的实体玩家、敌人、UI管理器、游戏管理器等。上下文清晰每个状态都知道自己在为谁工作代码意图明确。缺点泛型语法对初学者可能稍有门槛。状态转换逻辑仍然写在状态内部耦合问题依旧存在。3.4 策略四基于ScriptableObject的数据驱动状态高级架构这是Unity中一种非常强大且优雅的模式尤其适合大型项目或需要策划/设计师参与状态配置的情况。其核心思想是将状态逻辑Enter,Execute,Exit仍然写在普通的C#类中但将状态之间的转换规则、条件判断等“数据”剥离出来创建为ScriptableObject资产。创建状态SO基类public abstract class StateSO : ScriptableObject { public abstract void Enter(Character character); public abstract void Execute(Character character); public abstract void Exit(Character character); }创建具体状态SO[CreateAssetMenu(fileName IdleState, menuName Character States/Idle)] public class IdleStateSO : StateSO { public float someConfigValue; // 可以在Inspector中配置的参数 public override void Enter(Character character) { /* ... */ } public override void Execute(Character character) { // 执行逻辑但**不直接决定下一个状态** } public override void Exit(Character character) { /* ... */ } }创建状态转换SO[CreateAssetMenu(fileName Transition, menuName Character States/Transition)] public class StateTransitionSO : ScriptableObject { public StateSO fromState; public StateSO toState; public ConditionSO condition; // 条件也是一个SO如“按键按下”、“距离小于X” }在Character中管理public class Character : MonoBehaviour { public StateSO currentState; public ListStateTransitionSO transitions; // 所有可能的转换 void Update() { currentState.Execute(this); // 遍历transitions找到从currentState出发且条件满足的转换 foreach(var trans in transitions) { if(trans.fromState currentState trans.condition.IsMet(this)) { currentState.Exit(this); currentState trans.toState; currentState.Enter(this); break; } } } }优点高度可配置策划可以在Unity编辑器中拖拽配置状态和转换无需修改代码。热重载友好修改ScriptableObject的数据在Play模式下可以立即生效。逻辑与数据分离状态逻辑代码和转换规则数据清晰分离架构干净。缺点架构复杂度最高需要预先设计好ConditionSO等系统。运行时状态切换的性能开销可能略高于纯代码方式需要遍历列表查找但对于大多数游戏来说可以接受。实操心得对于中小型项目或原型开发从**策略一基础接口或策略三泛型状态机**开始是最快最有效的。当项目规模扩大状态逻辑变得复杂且需要非程序员参与调整时**策略四ScriptableObject驱动**的优势将无可比拟。我个人的项目演进路径通常是策略一 - 策略三 - 策略四。4. 状态模式在Unity中的高级应用与性能优化4.1 管理复杂状态转换状态转换表与条件解耦在基础实现中状态转换逻辑散落在各个状态的Execute方法里这被称作“分布式状态转换”。它的缺点是状态类之间相互了解耦合度高。一个更集中的方法是使用状态转换表State Transition Table。我们可以在Context如PlayerController中维护一个字典或列表定义所有合法的状态转换及其条件。public class PlayerController : MonoBehaviour { private IPlayerState _currentState; private DictionarySystem.Type, ListTransition _transitions new DictionarySystem.Type, ListTransition(); void Start() { // 初始化转换表 RegisterTransition(typeof(IdleState), typeof(WalkState), () Input.GetAxisRaw(Horizontal) ! 0); RegisterTransition(typeof(WalkState), typeof(IdleState), () Input.GetAxisRaw(Horizontal) 0); RegisterTransition(typeof(WalkState), typeof(AttackState), () Input.GetButtonDown(Fire1)); RegisterTransition(typeof(AttackState), typeof(IdleState), () _attackAnimationFinished); // ... 注册更多转换 _currentState new IdleState(); _currentState.Enter(this); } void Update() { _currentState.Execute(this); // 集中处理转换 CheckForTransitions(); } private void CheckForTransitions() { var currentStateType _currentState.GetType(); if (_transitions.TryGetValue(currentStateType, out var possibleTransitions)) { foreach (var trans in possibleTransitions) { if (trans.condition()) { ChangeState(trans.toState); break; } } } } private void RegisterTransition(System.Type from, System.Type to, System.Funcbool condition) { if (!_transitions.ContainsKey(from)) _transitions[from] new ListTransition(); _transitions[from].Add(new Transition { toState to, condition condition }); } private class Transition { public System.Type toState; public System.Funcbool condition; } }这样具体状态类如IdleState的Execute方法就只需要专注于“在待机状态下该做什么”而无需关心“什么时候、为什么切换到行走状态”。转换逻辑被集中管理修改和调试都更加方便。条件Funcbool可以使用Lambda表达式也可以封装成独立的Condition类实现更复杂的判断逻辑。4.2 状态模式与Unity动画系统的深度集成Unity的Animator本身就是一个状态机。我们完全可以将代码逻辑状态与动画状态机绑定实现“代码驱动动画动画反馈代码”的闭环。代码状态同步到Animator参数在每个状态类的Enter方法中设置对应的Animator参数Trigger、Bool等触发动画状态切换。public class AttackState : IPlayerState { public void Enter(PlayerController player) { player.animator.SetTrigger(Attack); // 触发动画状态机中的Attack过渡 } }使用动画事件Animation Events反馈给代码在攻击动画的特定帧如武器挥到最高点时添加动画事件调用PlayerController上的一个方法。这个方法可以触发伤害判定、播放音效甚至触发状态转换例如动画结束后自动切回Idle。// 在Animation Event中调用的方法 public void OnAttackAnimationEnd() { // 可以在这里直接切换状态或者设置一个标志位在状态的Execute中检查 _attackAnimationFinished true; }使用Animator State Machine Behaviours这是一个更强大的集成方式。你可以创建一个继承自StateMachineBehaviour的脚本挂载到Animator的某个动画状态上。这个脚本可以重写OnStateEnter、OnStateUpdate、OnStateExit等方法它们会在动画状态进入、更新、退出时被调用。你可以在这里面调用PlayerController的逻辑实现动画与游戏逻辑的强关联。4.3 性能考量与优化技巧状态模式本身带来的性能开销微乎其微主要是虚方法调用和对象引用切换。性能瓶颈通常出现在不恰当的实现上。避免在状态类的Execute中每帧进行昂贵的计算或查找例如在PatrolState中不要每帧都用Physics2D.OverlapCircle来寻找玩家。应该使用协程Coroutine或定时器每隔几秒检查一次。public class PatrolState : IStateEnemy { private Coroutine _checkPlayerCoroutine; public void Enter(Enemy enemy) { _checkPlayerCoroutine enemy.StartCoroutine(CheckForPlayer(enemy)); } IEnumerator CheckForPlayer(Enemy enemy) { while(true) { if (Physics2D.OverlapCircle(enemy.transform.position, enemy.sightRange, enemy.playerLayer)) { enemy.stateMachine.ChangeState(new ChaseState()); yield break; // 发现玩家结束协程 } yield return new WaitForSeconds(0.5f); // 每0.5秒检查一次而不是每帧 } } public void Exit(Enemy enemy) { if(_checkPlayerCoroutine ! null) enemy.StopCoroutine(_checkPlayerCoroutine); } }状态对象的创建与缓存如果状态类是无状态的没有成员变量可以将其实现为单例避免频繁的new操作。public class IdleState : IPlayerState { // 静态实例 public static readonly IdleState Instance new IdleState(); // 私有构造函数防止外部new private IdleState() {} public void Enter(PlayerController player) { /* ... */ } public void Execute(PlayerController player) { /* ... */ } public void Exit(PlayerController player) { /* ... */ } } // 使用时 player.ChangeState(IdleState.Instance);如果状态类需要持有数据例如AttackState需要记录连击数则不能使用单例此时可以考虑简单的对象池来复用状态对象。减少状态转换频率频繁的状态转换比如每帧在Idle和Walk之间快速切换可能带来不必要的开销调用Enter/Exit。可以通过增加转换条件缓冲Hysteresis来解决。例如从Walk切换到Idle的条件不是“速度0”而是“速度持续小于0.1f超过0.2秒”。5. 实战构建一个完整的敌人AI有限状态机让我们综合运用以上知识构建一个经典的敌人AI它会在巡逻点之间巡逻发现玩家后追击进入攻击范围后攻击丢失玩家视线后返回巡逻。5.1 定义状态与上下文首先定义状态接口和敌人上下文。// IEnemyState.cs public interface IEnemyState { void Enter(EnemyAI enemy); void Execute(EnemyAI enemy); void Exit(EnemyAI enemy); } // EnemyAI.cs (Context) public class EnemyAI : MonoBehaviour { public StateMachineEnemyAI StateMachine { get; private set; } public Animator Animator { get; private set; } public Transform Player { get; set; } // 通过其他系统如触发器赋值 public Transform[] PatrolPoints; public float ChaseSpeed 6f; public float PatrolSpeed 2f; public float AttackRange 1.5f; public float SightRange 10f; private int _currentPatrolIndex 0; void Start() { Animator GetComponentAnimator(); StateMachine new StateMachineEnemyAI(this); StateMachine.ChangeState(PatrolState.Instance); // 初始化为巡逻状态 } void Update() { StateMachine.Update(); } // 辅助方法获取下一个巡逻点 public Transform GetNextPatrolPoint() { _currentPatrolIndex (_currentPatrolIndex 1) % PatrolPoints.Length; return PatrolPoints[_currentPatrolIndex]; } public Transform GetCurrentPatrolPoint() PatrolPoints[_currentPatrolIndex]; }5.2 实现具体状态类巡逻状态 (PatrolState):public class PatrolState : IEnemyState { public static PatrolState Instance new PatrolState(); private PatrolState() {} private Transform _targetPoint; public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入巡逻状态); enemy.Animator.SetBool(IsWalking, true); _targetPoint enemy.GetCurrentPatrolPoint(); } public void Execute(EnemyAI enemy) { // 1. 巡逻移动逻辑 Vector2 direction (_targetPoint.position - enemy.transform.position).normalized; enemy.transform.position (Vector3)direction * enemy.PatrolSpeed * Time.deltaTime; // 到达巡逻点附近切换下一个点 if (Vector2.Distance(enemy.transform.position, _targetPoint.position) 0.5f) { _targetPoint enemy.GetNextPatrolPoint(); } // 2. 状态转换判断发现玩家 if (enemy.Player ! null Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { enemy.StateMachine.ChangeState(ChaseState.Instance); } } public void Exit(EnemyAI enemy) { enemy.Animator.SetBool(IsWalking, false); } }追击状态 (ChaseState):public class ChaseState : IEnemyState { public static ChaseState Instance new ChaseState(); private ChaseState() {} public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入追击状态); enemy.Animator.SetBool(IsRunning, true); } public void Execute(EnemyAI enemy) { if (enemy.Player null) { enemy.StateMachine.ChangeState(PatrolState.Instance); return; } // 向玩家移动 Vector2 direction (enemy.Player.position - enemy.transform.position).normalized; enemy.transform.position (Vector3)direction * enemy.ChaseSpeed * Time.deltaTime; // 转换判断1进入攻击范围 if (Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.AttackRange) { enemy.StateMachine.ChangeState(AttackState.Instance); } // 转换判断2丢失玩家玩家跑出视线范围 else if (Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { enemy.Player null; // 清空目标 enemy.StateMachine.ChangeState(PatrolState.Instance); } } public void Exit(EnemyAI enemy) { enemy.Animator.SetBool(IsRunning, false); } }攻击状态 (AttackState):public class AttackState : IEnemyState { public static AttackState Instance new AttackState(); private AttackState() {} private float _attackCooldown 2f; private float _lastAttackTime; public void Enter(EnemyAI enemy) { Debug.Log(Enemy: 进入攻击状态); enemy.Animator.SetTrigger(Attack); _lastAttackTime Time.time; // 立即执行一次攻击逻辑 TryAttack(enemy); } public void Execute(EnemyAI enemy) { // 攻击冷却判断 if (Time.time - _lastAttackTime _attackCooldown) { TryAttack(enemy); } // 状态转换玩家是否还在攻击范围内 if (enemy.Player null || Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.AttackRange) { if (enemy.Player ! null Vector2.Distance(enemy.transform.position, enemy.Player.position) enemy.SightRange) { // 玩家还在视线内但跑出了攻击范围切回追击 enemy.StateMachine.ChangeState(ChaseState.Instance); } else { // 玩家完全丢失切回巡逻 enemy.Player null; enemy.StateMachine.ChangeState(PatrolState.Instance); } } } private void TryAttack(EnemyAI enemy) { if (enemy.Player ! null) { // 这里执行攻击伤害判定例如调用 enemy.Player.GetComponentHealth().TakeDamage(10); Debug.Log($Enemy 攻击了玩家); _lastAttackTime Time.time; enemy.Animator.SetTrigger(Attack); // 再次触发攻击动画 } } public void Exit(EnemyAI enemy) { // 清理工作 } }5.3 添加玩家检测触发器为了让敌人“发现”玩家我们通常使用触发器Trigger或射线检测Raycast。这里用一个简单的触发器示例public class EnemySightTrigger : MonoBehaviour { public EnemyAI enemyAI; void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag(Player)) { enemyAI.Player other.transform; } } void OnTriggerExit2D(Collider2D other) { if (other.CompareTag(Player)) { // 注意不在触发器内不代表丢失视线追击状态会自己判断距离。 // 这里可以不做处理或者设置一个标志。 } } }将这个脚本挂到敌人身上一个较大的圆形触发器上并赋值enemyAI引用。当玩家进入触发器EnemyAI的Player属性被赋值巡逻状态检测到后就会切换到追击状态。6. 常见陷阱、调试技巧与扩展方向6.1 新手常踩的坑与解决方案状态循环或状态爆炸问题在A状态的Execute里无条件切换到B状态B状态的Execute里又无条件切回A状态导致每帧都在两个状态间疯狂切换。解决确保状态转换条件是有明确逻辑的并且通常需要某种“延迟”或“条件不满足的持续判断”。例如从“攻击”切回“待机”需要等待“攻击动画播放完毕”这个事件而不是在攻击状态的第一帧就判断。忘记调用Exit或Enter方法问题在ChangeState时只设置了新状态忘了调用旧状态的Exit和新状态的Enter。这会导致状态清理和初始化逻辑丢失比如动画参数没重置、协程没停止。解决将状态切换逻辑封装在一个方法里如我们一直做的ChangeState并严格遵守“先Exit旧状态再Enter新状态”的顺序。在状态类的Execute中处理所有输入问题在AttackState的Execute里还检测跳跃按键导致角色在攻击时也能跳起来这可能不符合设计。解决明确每个状态能响应的输入。通常输入检测可以放在Context的Update里然后根据当前状态决定是否处理。或者在每个状态的Execute里只检测与本状态相关的、能触发状态转换的输入。状态类持有对Context的非法引用问题在状态类的Enter方法中将Context的引用保存到一个静态变量或全局变量中导致状态机混乱。解决状态类只应通过Context参数访问它需要的数据。生命周期应和Context绑定避免产生游离的引用。6.2 状态机的调试与可视化调试状态机时最需要知道的就是“当前是什么状态”。有几种方法在Inspector中显示在Context的OnGUI或自定义Editor脚本中显示当前状态名。void OnGUI() { GUI.Label(new Rect(10, 10, 200, 20), $当前状态: {StateMachine.CurrentState?.GetType().Name}); }使用Unity的Debug.Log在每个状态的Enter和Exit方法中加入日志。自定义编辑器窗口创建一个EditorWindow遍历场景中所有状态机实体以树状图或列表形式展示其状态栈和转换条件。这对于调试复杂AI非常有用。6.3 状态模式的扩展层次状态机与下推自动机基础状态机有时不够用可以考虑更高级的变体层次状态机Hierarchical State Machine, HSM允许状态有父子关系。子状态可以继承并覆盖父状态的行为。例如可以有一个“移动”父状态包含“行走”、“奔跑”、“蹲走”等子状态。所有子状态共享“移动”的公共逻辑如应用重力但又有自己的特殊逻辑。这能极大减少重复代码。下推自动机Pushdown Automaton状态机带有一个栈。当你进入一个新状态时不是替换当前状态而是将其“压入”栈顶。当新状态退出时它被“弹出”状态机恢复到之前栈顶的状态。这对于实现“菜单系统”打开子菜单后能返回上级或“角色被打断”从任何状态进入“受伤”状态受伤结束后回到之前的状态非常完美。实现这些高级状态机超出了本文的范围但网上有众多优秀的开源实现如UnityHSM、PushdownAutomaton等。当你发现基础状态模式写起来开始重复或别扭时就是考虑引入它们的时候了。状态模式不是银弹但它为管理复杂的行为逻辑提供了一个坚实、清晰的框架。在Unity开发中从简单的角色控制到复杂的游戏管理器它都是不可或缺的设计工具。花时间理解和实践它你的代码质量和开发效率都会获得显著的提升。
