對於遊戲開發中的動作狀態管理，我的一些看法

業務痛點：我遇到的動作狀態覆蓋 Bug

最近我加入了一個剛起步不久的團隊，在幫他們梳理戰鬥系統和表現層邏輯時，我遇到了一起 非常經典且令人頭疼 的 Bug。

具體場景是這樣的： 角色被施加了一個持續 5 秒的「冰凍」 Debuff，此時動作切換為 【冰凍】 （角色被凍結在原地，表現為僵直發抖）。在第 2 秒時，角色受到了敵人的帶有眩暈效果的重擊，觸發了一個持續 2 秒的 【眩暈】 動作（角色抱頭暈眩）。

真正的問題發生在眩暈動作結束之後： 當 2 秒的眩暈表現結束後，按照底層邏輯，角色身上依然還有 1 秒的「冰凍」 Debuff。但實際上，角色的動作並沒有恢復到 【冰凍】 狀態，而是直接掉回了預設的 【待機】 狀態。這導致玩家看到角色明明站著在正常呼吸待機，搖桿卻無法控制移動（因為底層邏輯還在冰凍中），角色的表現與底層邏輯出現了 嚴重的割裂 。

經過代碼排查，我發現原因很簡單：團隊之前的狀態控制系統是 觸發式 的。眩暈觸發時，強行讓 Animator 播放眩暈；眩暈結束時，又簡單粗暴地讓 Animator 恢復預設狀態，完全沒有考慮其他正在持續的邏輯效果。

狀態管理的普遍性與傳統方案的局限

我個人認為這個問題在遊戲開發中具有 極高的普遍性 。只要你的遊戲存在複雜的 Buff 系統、多狀態疊加的技能效果，就必然會面臨動作狀態互相頂替與恢復的問題。

很多團隊在初期為了快速出效果，往往會採用以下兩種存在巨大隱患的做法，這也是我在實戰中比較反對的：

隱患 A：各系統直接操控 Animator 變數

各個系統（Buff 系統、技能系統、受傷系統）直接去呼叫 animator.SetBool("isFrozen", true)。當系統變龐大後，你根本不知道是哪段代碼在什麼時候把 Bool 設回了 false，導致狀態機狀態混亂，極其難以 Debug。

隱患 B：濫用 Unity Mecanim 的連線網絡

Unity 的 Animator 視窗在連線少的時候很直觀，但如果把業務邏輯綁定在連線上，設定一堆諸如 Speed > 0, isFrozen == true 的連線條件，最後狀態機會變成一張密密麻麻的蜘蛛網。一旦增加一個新狀態，就需要連接無數條線，後期維護成本呈 指數級上升 。

我的破局思路：活躍狀態池與優先級動態評估

為了解決狀態互相頂替、無法正確恢復以及耦合度過高的問題，我向團隊引入了一種思路： 活躍狀態池 (Active State Pool) 與優先級動態評估 機制。

它的核心思想就一點： 狀態的請求與狀態的表現徹底分離 。

業務層（Buff 或技能系統）只負責 註冊 和 註銷 自己想要的動作狀態，而由一個統一的 AnimationStateManager 來決定當前這一幀，到底該向 Animator 下發什麼動作指令。

核心機制流程圖：

Loading diagram...

在這個架構下，當優先級 100 的「眩暈」結束並反註冊後，管理器再次評估，發現池子裡剩下的最高優先級是 50 的「冰凍」，於是自動命令 Animator 切回 【冰凍】 動作。先前的 Bug 自然就解開了。

Unity 落地實戰：讓 Animator 回歸純粹

在應用了上述架構後，我認為 Unity 的 Animator 使用方式也需要隨之改變。我們可以拋棄複雜的連線和 Trigger/Bool 條件，讓 Animator 退化為一個純粹的 動作播放器 。

在 Unity 的 Animator Controller 中，你只需要把所有動作的 State 拖進去， 不需要連任何線 （或者全部從 AnyState 連接，且不設條件）。在代碼層面，使用 Animator.CrossFade() 或 Animator.Play() 直接透過代碼驅動狀態切換即可。

核心管理器偽代碼示例：

// 1. 定義動作狀態資料結構
public class AnimStateRequest
{
    public string StateName; // Animator中的狀態名
    public int Priority;     // 優先級
    public object Source;    // 來源（用於反註冊時校驗，比如傳入特定的Buff實例）
}

// 2. 統一管理器
public class AnimationStateManager : MonoBehaviour
{
    private Animator _animator;
    private List<AnimStateRequest> _activeStates = new List<AnimStateRequest>();
    private string _currentPlayingState;

    // 註冊狀態
    public void AddStateRequest(string stateName, int priority, object source)
    {
        _activeStates.Add(new AnimStateRequest { StateName = stateName, Priority = priority, Source = source });
        EvaluateHighestPriorityState();
    }

    // 反註冊狀態
    public void RemoveStateRequest(object source)
    {
        _activeStates.RemoveAll(req => req.Source == source);
        EvaluateHighestPriorityState();
    }

    // 動態評估當前最高優先級狀態
    private void EvaluateHighestPriorityState()
    {
        if (_activeStates.Count == 0)
        {
            PlayAnimation("Idle"); // 預設狀態
            return;
        }

        // 找出優先級最高的請求
        _activeStates.Sort((a, b) => b.Priority.CompareTo(a.Priority));
        string targetState = _activeStates[0].StateName;

        if (_currentPlayingState != targetState)
        {
            PlayAnimation(targetState);
        }
    }

    // 驅動 Unity Animator
    private void PlayAnimation(string stateName)
    {
        _currentPlayingState = stateName;
        // 使用 CrossFade 實現平滑過渡，0.1f 為過渡時間
        _animator.CrossFade(stateName, 0.1f); 
    }
}

架構延伸：對更複雜動作系統的一些設想

這套 活躍池與優先級評估 的架構為遊戲後續的複雜化提供了不錯的擴展性。在後續的開發中，我還考慮了以下幾點延伸：

1. 同優先級衝突處理 ：如果同時存在兩個優先級為 50 的動作請求，可以拓展評估邏輯，比如設定為 後入池的優先 ，或者 剩餘持續時間長的優先 。
2. 部位遮罩 (Avatar Mask) 的獨立管理 ：在 3D 遊戲中，常常需要上半身開槍，下半身受擊或跑動。可以建立兩個獨立的 Manager（分別對應 UpperBodyPool 和 LowerBodyPool），分別評估最高優先級，然後通過 CrossFade 傳遞不同的 Layer 索引，實現上下半身的解耦。
3. 擁抱 Playable API ：對於有嚴謹前後搖的技能動作，直接使用 Animator 可能會面臨狀態機更新延遲的問題。此時可以將這套狀態管理器與 Unity 底層的 Playable Graph 深度結合，在 C# 端直接混排 AnimationClip。

以上就是我在實際專案開發中，對於動作狀態管理的一些思路和總結。就事論事地說，這套方案解決了我們團隊當前的痛點，但也未必是完美的銀彈，實際應用中還需要根據具體的遊戲類型進行調整。我的見解可能存在局限性，如果大家有更好的方案或者在實現上發現我有考慮不周的地方，非常歡迎交流，如果有誤敬請指正。

---

• 本文由 iknowabit 團隊原創。技術支持：基於 Unity 引擎與 C# 高級架構模式探索。 *