省流總結
趕時間的朋友依舊看這裏 (๑¯◡¯๑)：
爲什麼精英怪"什麼都會"？ 不是數值高，而是底層架構讓它能同時幹很多事——而且隨時能中斷當前行爲，切到更緊急的事。
FSM 改一個行爲要連 10 條線，行爲樹只需要插一個樹枝。 狀態越多，這個差距越恐怖。
但別盲目上行爲樹。 AI 只有 5 個狀態？用行爲樹是殺雞用牛刀。
想知道《最後生還者》的 Hunter 是怎麼"不做蠢事"的？《光環 2》怎麼用樹形結構第一次在 3A 遊戲裏證明有效性？《全境封鎖》怎麼靠行爲樹管理 55 種 NPC 變體？
往下翻，答案都在後面。
引子
上一篇我們聊了有限狀態機（FSM）——從喫豆人的四個幽靈，到合金裝備的守衛 AI，再到魂系 Boss 的套路循環。FSM 在簡單場景下確實好用，但當狀態數超過某個閾值後，"狀態爆炸"會讓系統變得沒法維護。
如果你還沒看過第一篇，建議先補課——本篇會直接沿用 FSM 的基本概念（狀態、轉移、動作），不再重複解釋。
今天這篇，來看看 FSM 遇到瓶頸之後，業界是怎麼破局的。
你遇到過那種讓你血壓飆升的精英怪嗎？
不是因爲它數值高，而是因爲它什麼都會Σ( ° △ °|||)︴
你剛躲進掩體喘口氣，它切槍包抄你側翼。你拉開距離想狙擊，它三槍點射然後縮回去。你把它打殘了，它一邊丟煙霧彈一邊往掩體後跑，追都追不上。
這一刻你心裏冒出的念頭不是"這傢伙好聰明"，而是："它怎麼同時幹這麼多事的？它到底在想什麼？"
要理解這種"同時幹很多事"的能力從何而來，我們可以從設計者的角度換個思路——
想象一下你在給一個按部就班的管家寫"待辦清單"。但問題是，一個"看起來聰明"的管家，背後需要的判斷條件，可能比你能想到的所有情況加起來還多。
我們來感受一下這個問題的規模。
你需要教會笨蛋管家處理以下情況：日常打掃、發現漏水、修理水管、準備晚餐、有客人到訪、寵物生病、火警響起、停電後恢復、打掃完成後彙報……
用 FSM 來實現的話，你需要畫一張狀態圖：每個行爲是一個狀態，狀態之間用轉移線連接。
9 個狀態，最多 72 條轉移線。15 個狀態，最多 210 條。30 個狀態？快 1000 條了。
這不是壓縮毛巾，這是狀態爆炸
這還沒完。你想加一個"被閃光彈致盲"的新狀態？你需要從每一個已有狀態畫一條轉移到新狀態的線，還要考慮被致盲後恢復到哪個狀態。
每加一個新狀態，維護成本都在漲。
這就是所謂的"狀態爆炸"（State Explosion）——狀態數量線性增長，轉移線數量呈平方級增長。改一個狀態，牽動整個網絡。
第一章：《最後生還者》
狀態機的最佳實踐與限制
上篇聊過《光環 2》裏 Bungie 是怎麼用 Objective Tree（目標樹）應對狀態爆炸的。而在 Bungie 之後約十年，Naughty Dog 選擇了另一條路：把成熟的架構通過工程實踐打磨到工業級水準。
如果說 FSM/HFSM 有一個"工業級最佳實踐"，那 Naughty Dog 在《最後生還者》（The Last of Us, 2013）中實現的 Hunter AI 絕對是這個方向的代表作。
2014 年，Naughty Dog 的 AI 程序員 Travis McIntosh 在 GDC 上做了一個演講，題爲 《The Last of Us: Human Enemy AI》。 這個演講之所以能成爲經典，不是因爲它展示了什麼新技術——恰恰相反，它展示的是如何把一套成熟的系統通過大量工程調優做到 3A 級別的水準。
Skills Priority Stack + Behaviours 兩層架構
Naughty Dog 的 Hunter AI 並非傳統意義上的 HFSM，而是採用了一種技能優先級堆棧（Skills Priority Stack）+ Behaviours的分層架構。
核心思想很簡單：把決策分成兩層，上層決定"做什麼"，下層決定"怎麼做"。
Skills（技能 / 高層決策）： 這是 AI 的"戰術層"。它決定 Hunter 當前應該採取什麼策略——追擊玩家、在掩體後等待、搜索擾動來源、包抄玩家側翼，還是撤退。這些 Skills 通過一個優先級堆棧（Priority Stack）管理，每個 Skill 有自己的啓用/禁用條件，堆棧決定了哪些 Skill 可以中斷哪些 Skill。
Behaviours（行爲 / 底層執行）： 這是 AI 的"執行層"。它負責把高層意圖落地——怎麼移動、怎麼瞄準、怎麼射擊、怎麼播放動畫。Behaviours 通過一個Behaviour Stack管理，負責改變動畫狀態和尋路系統。
Post Selectors（位置選擇器）： 用於選擇掩體、開放位置等，這些選擇器的條件定義使用LISP 腳本編寫。
注意： TLOU 的系統更接近一個"帶優先級的任務調度器"，而不是傳統 HFSM 的"狀態機 + 子狀態機"模型。傳統 HFSM 中，子狀態之間的切換仍然需要顯式編寫轉移線；而 TLOU 的架構中，系統通過優先級堆棧自動選擇最高分的 Skill，不需要手動編寫 Skill 之間的轉移關係。
這種架構的好處是解耦。
一個 Hunter 可以有"追擊"這個 Skill，但具體怎麼追擊——是跑步追擊還是蹲伏追擊——由 Behaviour 層決定。
不同敵人可以共用同一套 Behaviours，只需要配置不同的 Skills。同一套"走路"和"射擊"的底層代碼，普通士兵和精英士兵都能用，區別只在於高層決策不同。
感知系統：視覺視錐 + 音頻傳感器
Hunter AI 之所以"看起來聰明"，很大程度上歸功於它的感知系統。
這個系統由兩部分組成：
視覺視錐（View Cones）： 每個 Hunter 有一個扇形的視野區域。在這個區域內的玩家會被"看到"，區域外的則不會。視錐的角度和距離會根據難度和情境動態調整。
音頻傳感器（Audio Sensors）： 玩家在環境中發出的聲音（腳步聲、槍聲、碰倒物品）會被 Hunter "聽到"。聲音傳播的距離和方向決定了 Hunter 的反應——聽到遠處槍聲可能只是"警覺"，聽到身邊腳步聲則直接進入"搜索"狀態。
感知系統和決策系統的分離，是《最後生還者》AI 設計的另一個精妙之處。 感知系統輸出"玩家可能在附近"這樣的模糊信息，決策系統再根據這些信息選擇對應的 Skill。
核心設計理念："讓角色不做蠢事"
Travis McIntosh 在演講中提到了一句非常經典的話，也是整個 Hunter AI 設計的核心理念：
"讓角色不做蠢事比讓角色變聰明更重要。"
（"Making sure characters don't do stupid things is more important than making them do smart things."）
這句話的含義是：玩家對一個 AI 的"聰明度"感知，很大程度上取決於它什麼時候不犯錯。 一個 AI 如果在玩家已經躲進掩體後還在原地站着不動，玩家會覺得它"蠢"。但如果它能在玩家消失後主動搜索、包抄或者等待，玩家就會覺得它"聰明"——哪怕它的行爲邏輯本質上還是 if-else 判斷。
所以《最後生還者》的 AI 團隊花了很多精力在防止 AI 做蠢事上：
避免 Hunter 在開闊地帶暴露
避免多個 Hunter 擠在同一個掩體後
避免 Hunter 在玩家已經繞到身後時還面朝前方 這些"不蠢"的行爲，比"聰明"的行爲更能提升玩家的遊戲體驗。
FSM/HFSM 的侷限性
在給出侷限性之前，先說句公允話：HFSM 確實緩解了狀態爆炸問題。 通過把狀態組織成層級，子狀態內部的轉移不需要與外部狀態一一連接。一個"戰鬥"子狀態機內部可以有 10 個狀態，但對外只表現爲一個"戰鬥"狀態——這大幅減少了頂層狀態之間的轉移線數量。
但 HFSM 也有它的結構性侷限：
子狀態間的轉移仍然需要顯式定義。 同一層級內的子狀態切換，仍然需要編寫轉移線和條件。新增一個子狀態，仍然需要考慮它和同層級其他狀態之間的所有轉移關係。
不能天然實現優先級搶佔。 如果一個 Hunter 正在"追擊"玩家，突然聽到手雷飛來——在 HFSM 中，需要從"追擊"狀態顯式寫一條轉移到"躲避"狀態的線，並在躲避完成後寫恢復邏輯。而在行爲樹中，這隻需靠 Selector 的排列順序隱式表達。
跨層級通信成本高。 底層 Behaviour 需要向頂層 Skill 報告執行結果，頂層需要向底層傳遞意圖參數。隨着層級加深，通信開銷增長。
Naughty Dog 用工程上的匠心克服了這些侷限——通過精心設計的優先級堆棧和 LISP 規則腳本，讓 Hunter AI 實現了接近行爲樹的優先級搶佔效果。 但這種方式依賴大量手動調優和規則編寫，而不是架構本身的優勢。 有沒有一種架構，能從根本上減少這些維護成本？
有。而且它已經在一款 2004 年的遊戲中被證明有效。
第二章：行爲樹的核心概念
從"改不動"到"搭積木"
在聊 Bungie 的選擇之前，我們需要先回答一個根本問題：
行爲樹到底解決了 FSM 的什麼痛點？
FSM 的三個根本矛盾
上一篇中我們詳細拆解了 FSM 的三大矛盾，這裏簡要回顧一下
改不動（狀態爆炸）： 所有狀態攤在一個平面上。加一個新行爲，需要考慮它和每一個已有狀態的轉移關係。N 個狀態加 1 個新狀態，可能需要新增 N 條轉移線。狀態越多，修改成本越高。
走不遠（行爲組合困難）： FSM 一次只能在一個狀態裏。想讓 AI"一邊後退一邊射擊一邊扔手雷"？你得新建一個"後退 + 射擊 + 扔手雷"的組合狀態。組合的數量隨行爲數量指數級增長。
看不懂（調試困難）： 看到 AI 在做什麼容易（它當前在哪個狀態），但它爲什麼選了這個狀態不容易。狀態圖越大，理解"爲什麼 AI 此刻在做這件事"就越需要追蹤一大片轉移線。
行爲樹用一個根本不同的思路來解決這些問題。(~￣▽￣)~
行爲樹的核心概念——一家公司的決策體系
行爲樹把決策組織成一棵樹。 從根節點開始，沿着優先級從高到低的路徑一路走，找到第一個"當前應該執行的行爲"。 每幀從頭重新評估（Tick），確保 AI 永遠能響應最新的遊戲狀態。
在講解行爲樹的核心機制前，讓我們先請各位總裁來安排一家公司的決策體系：
打卡機（Root 節點）： 每天準時啓動這家公司，但從不參與任何決策——"簽到成功"
部門總監（Selector 節點）： 每天開無數次例會，從左到右檢查手裏的項目——"先看看項目 A 能不能推進？不能？那項目 B 呢？"
項目經理（Sequence 節點）： 按步驟推進——"需求評審做完沒？好了？那進入開發階段……"
質檢員（Condition 節點）： 只檢查不幹活——"預算批了嗎？批了，放行。沒批，打回去。"
基層員工（Action 節點）： 真正動手幹活的——搓代碼、做設計、跑測試。
並行項目組（Parallel 節點）： 同時推進兩個獨立任務——"營銷和開發同時開發，互不干擾。"
這套層級體系的精妙之處在於：每一層只關心自己該管的事，不越級。 打卡機不會去管員工代碼寫得怎麼樣——他只負責開啓美好的一天。 項目經理只管按步驟推進，不問"爲什麼要做這個項目"。 每個節點只關注自己的職責範圍，決策路徑清晰可追溯。
Running 狀態：行爲樹"可中斷性"的關鍵錨點
當一個節點返回 Running，父節點不會跳過它——但也不會被它"鎖死"。 如果父節點是一個 Selector，而更高優先級的兄弟節點的條件在下一幀變成了真，那麼當前 Running 節點會被搶佔（中止），高優分支啓動。
我們可以用打電話佔線來理解： 家長（父節點）在打電話（Running）。
如果有急事（高優先級事件）找家長，電話會被強行掛斷（Abort），家長去處理急事。
如果沒有急事，家長就繼續打他的電話。
搶佔的運作邏輯：
這就意味着：不需要顯式寫"中斷當前行爲"的轉移線，優先級由 Selector 的排列順序隱式表達。 後續的"現場改需求"章節會演示這個機制如何讓修改成本從"重構整個狀態圖"降爲"插一個新分支"ε(*′･∀･｀)зﾞ。
中止策略（Abort）：行爲樹搶佔機制的工程實現
上節提到"高優先級條件成立時，低優行爲會被自動中止"——但"自動中止"這個描述在工程實現上需要額外的機制來支撐。 這就是 Abort（中止策略） 的概念。
爲什麼需要 Abort？
考慮一個場景：AI 正在執行"走到掩體後"的動作（返回 Running），這時玩家突然從側面衝出來。 如果沒有 Abort，即使"射擊玩家"這個高優條件已經成立，AI 還是會堅持把"走到掩體後"這個動作執行完——這就產生了一個"遲鈍"的時間窗口。
Abort 讓行爲樹能在高優先級條件滿足時，同一幀內立即中斷當前正在運行的低優先級分支。 它不是等到"下一幀 Selector 重新評估"時才切換，而是即時響應。
三種 Abort 類型
在現代行爲樹引擎（如 Unreal Engine）中，Abort 有三種策略：
Self（自中止）： 當前節點檢查自己的條件。如果條件不再滿足，自行中止。
示例：AI 正在"追擊玩家"，但玩家超出了追擊距離——Self Abort 會立即終止追擊。
Lower Priority（低優先級中止）： 當前節點運行時，如果有更高優先級的兄弟節點的條件變爲真，則中止當前節點。
示例：AI 正在"巡邏"，突然檢測到"手雷飛來"——高優先級的"躲避手雷"分支觸發 Abort，立即中斷巡邏。
Both（兩者兼有）： 同時啓用 Self 和 Lower Priority。這是 Unreal Engine 中 Selector 節點的默認 Abort 策略。
Observer Abort：更高效的實現
樸素的 Abort 實現需要每幀檢查所有節點的條件，這在高深度行爲樹中開銷不小。 Observer Abort（觀察者中止） 是一種優化策略：
當一個節點開始執行時，它會"註冊觀察"自己關心的條件變量（如"玩家距離"、"是否有手雷"）。
只有當這些條件變量發生變化時，纔會觸發重新評估和可能的 Abort。
這避免了每幀遍歷所有條件的冗餘計算。
小結： Abort 策略是行爲樹"可中斷性"的工程基石。後續的"改需求"章節中，"插入一個新手雷躲避分支"之所以不影響已有行爲，正是得益於 Abort 機制的自動優先級裁決 (๑´`๑)。
Selector 與 Sequence：兩種組合邏輯（Memory 版本）
Selector（選擇器）和 Sequence（順序器）是行爲樹中最核心的兩種組合節點。
說明： 以下展示的是 Memory Selector / Memory Sequence 的行爲——這是現代遊戲引擎（如 Unreal Engine）的默認實現方式。標準 Selector/Sequence 在每一幀會從頭嘗試，而 Memory 版本會"記住"上次運行的子節點位置，下一幀從該位置繼續，避免重複執行已成功的子節點。兩者的核心邏輯一致，差異僅在於是否需要保留執行狀態。
Selector 的邏輯是"選一個能幹的"： 從左到右嘗試子節點，停在第一個返回 Success 或 Running 的那一個。如果子節點返回 Failure，則繼續嘗試右邊下一個。
Selector
Sequence 的邏輯是"按步驟走完"： 從左到右依次執行子節點，遇到 Failure 立即停止，全部 Success 纔算整體成功。
Selector 管優先級 / 選擇性（選哪個方案），Sequence 管步驟 / 順序性（方案內的步驟怎麼走）。兩者組合使用，就構成了一棵完整的決策樹。
耄耄沒有地方放了
不過行爲樹不是在所有方面都比 FSM 好。 如果你的 AI 只有 5 個狀態，FSM 寫起來更快、跑起來更快、調試起來更簡單。 但當狀態數超過 15 個、行爲需要靈活組合、開發過程中需求頻繁變更時，行爲樹的結構性優勢就會顯著體現出來(≧∀≦)ゞ。
第三章：《光環 2》
第一次在 3A 遊戲裏證明"樹形結構"有效
2004 年，《光環 2》發售。 2005 年，Bungie Studios 的 AI 程序員 Damian Isla 在 GDC 上發表了一個演講：《Handling Complexity in the Halo 2 AI》。
這個演講能成爲遊戲 AI 領域的經典文獻，不是因爲它介紹了什麼全新的學術理論——而是因爲它第一次在 3A 遊戲裏大規模展示了樹形優先級決策結構的實際效果。
嚴格來說，《光環 2》用的不是現代意義上標準化的行爲樹（缺少 Tick / 返回狀態等標準機制），而是一種叫做 Objective Tree（目標樹） 的架構。 這是 Damian Isla 在 GDC 2005 演講中使用的正式術語。 它運行在 HFSM（分層有限狀態機）框架內，是一種聲明式的樹形結構，用來管理 AI 目標的優先級和複用。 它是行爲樹概念的前身和早期變體，第一次在商業遊戲裏證明了"樹形優先級結構"的有效性，直接啓發了後來行爲樹在遊戲開發中的廣泛採用。
Covenant 敵人的戰術行爲
在《光環 2》中，Covenant 陣營的敵人（精英戰士 Elite、咕嚕人 Grunt、豺狼人 Jackal 等）展現出了讓人印象深刻的戰術行爲。
先看進攻和撤退——敵人會根據戰況判斷是該衝上來打，還是退回去找掩體。 不是固定腳本，而是根據當下情況自己做決定。
再看團隊配合。多個敵人會協同行動：有的正面吸引火力，有的繞到玩家側翼包抄。 這不是預先編排的動畫，而是每個敵人獨立決策的結果。
還有一些細節也很到位：
投擲手雷不是盲目亂扔，而是會考慮落點和玩家的掩體位置。
不同兵種有不同風格：Elite 更主動攻擊，Grunt 更容易恐慌逃跑，Jackal 更擅長用能量盾防守。
這些行爲在玩家看來非常"智能"，但底層邏輯其實並不複雜： 樹形優先級結構讓每個敵人都能根據當前環境條件，自主決定最合適的行爲。
Tick 機制在《光環 2》中的實際體現
雖然《光環 2》的架構不完全等同於現代行爲樹，但它已經包含了 Tick 機制的核心思想： 每幀重新評估戰術優先級。
這意味着敵人的決策不是一次性做出的。
它不是在"追擊"狀態裏一路追到底。 而是每一幀都在問自己："我現在應該繼續追擊嗎？還是該找掩體？還是該扔手雷？"
如果戰況變化（比如玩家繞到了側翼），AI 在下一幀就能調整行爲。
這種"每幀重新評估"的機制，是讓 AI 看起來"靈活"和"聰明"的關鍵。 玩家感覺敵人"會根據戰況調整策略"，本質上是因爲敵人的決策樹在每一幀都在重新運行。
Selector / Sequence 的實際應用
在《光環 2》的行爲架構中，優先級裁決和步驟執行的邏輯已經初具雛形。
優先級裁決（類似 Selector）： 敵人先檢查"有沒有手雷飛來？"（高優）。有的話執行"躲避"。沒有則檢查"能不能攻擊玩家？"（中優）。能的話執行"攻擊"。不能的話檢查"該不該找掩體？"（低優）。
這種優先級結構天然支持搶佔——高優條件成立時，低優行爲會被自動中止。
步驟執行（類似 Sequence）： 當決定"投擲手雷"時，敵人需要按步驟執行：拾起手雷 → 瞄準 → 投擲 → 返回戰鬥。
任何一個步驟失敗（比如手雷被玩家打掉），整個序列就終止，AI 回到優先級裁決重新選擇行爲。
Objective Tree 的行爲複用機制
《光環 2》架構中另一個值得注意的設計是 Objective Tree 的共享節點引用機制。
在傳統 FSM 中，每個狀態是獨立的，行爲不能複用。"找掩體"這個行爲如果被"躲避手雷"和"尋找戰術位置"兩個場景需要，就得寫兩份代碼。
在 Objective Tree 中，行爲可以作爲子節點被多個父節點引用。 "找掩體"行爲只寫一次，可以被"躲避"、"進攻"、"撤退"等多個分支調用。 這就減少了代碼重複，也讓行爲修改（比如優化"找掩體"的算法）能同時惠及所有調用它的分支。
Objective Tree 的共享節點引用是實現行爲複用的早期方案。 現代行爲樹引擎（如 Unreal Engine 的 Behavior Tree）通過不同的機制（如 Compound 節點、子樹引用）實現了類似的可複用性。
第四章：《全境封鎖》
"改需求"時的行爲樹優勢
如果說《光環 2》證明了行爲樹"能做複雜 AI"，那麼 Massive Entertainment 在《全境封鎖》（Tom Clancy's The Division, 2016）中的實現則證明了它"能在大規模 NPC 開發中管理複雜度"。 發售時《全境封鎖》的 AI 表現中規中矩，但其行爲樹工具鏈和架構設計在 GDC 演講中得到了業界的認可，尤其在多模板、多派閥的行爲管理方面提供了有價值的實踐經驗。
2016 年，Massive Entertainment 的 Philip Dunstan 和 Drew Rechner 在 GDC 上發表了演講：《Blending Autonomy and Control: Creating NPCs for Tom Clancy's The Division》。
這個演講的核心主題不是行爲樹的技術細節——而是如何用行爲樹來管理大規模、多派閥、多模板的 NPC 行爲開發。
11 種 AI 模板 + 4 個派閥
《全境封鎖》的 NPC 系統規模相當龐大：
11 種 AI 模板： Assault（突擊）、Rusher（衝鋒）、Sniper（狙擊）、Thrower（投擲）、Controller（控制）、Heavy Weapons（重武器）、Tank（坦克）、Leader（領袖）、Support（支援）、Special（特殊）等。
4 個派閥： Rioters（暴徒）、Cleaners（淨化者）、Rikers（瑞克幫）、Last Man Battalion（最後營）。其中 LMB 有標準和高強度兩種配置，所以 4 個派閥合計 5 種 AI 變體。
每個派閥有自己的特色行爲：
Rioters 更像暴民——衝動、喜歡近戰、容易恐慌。
Cleaners 則是軍事化組織——配合默契、善於利用掩體、會使用火焰武器。
Rikers 喜歡用毒氣和近戰。
LMB 則是訓練有素的士兵——包抄、壓制、戰術撤退樣樣精通。
如果要用 FSM 來實現這套系統，每個派閥 × 每個模板都需要獨立的狀態圖。 11 模板 × 5 派閥 = 55 個變體。 每個變體如果有 15 個狀態，就是 800 多個狀態定義。 狀態之間的轉移線？上千條。 維護成本可想而知( >﹏<。)。
行爲樹如何解決規模問題
行爲樹的解決方案是模塊化組合：
基礎行爲（找掩體、移動、瞄準、射擊）寫一次，所有模板和派閥共用。
派閥特色通過不同的行爲樹配置實現：Rioter 的行爲樹裏"近戰衝鋒"的優先級更高，LMB 的行爲樹裏"包抄"的優先級更高。
模板特色通過參數調整實現：Sniper 的"射擊距離"參數更大，Tank 的"血量閾值"參數更高。
這種架構的核心優勢是： 新增一個模板不需要重寫已有代碼，只需要種一棵新的行爲樹（或調整已有行爲樹的參數）。
可視化編輯器 + 運行時調試工具
Massive Entertainment 搞了一套專有的行爲樹可視化編輯器，讓設計師（不僅僅是程序員）可以創建和修改 NPC 行爲。
編輯器支持：
拖拽節點構建行爲樹
實時預覽行爲樹執行流程
運行時調試：在遊戲運行過程中觀察 AI 當前執行到樹的哪個節點
這套工具鏈是行爲樹在實際項目裏落地的重要保障。 沒有可視化工具，行爲樹的"可讀性"優勢就大打折扣——設計師需要看代碼才能理解 AI 的邏輯。 有了工具，設計師可以直接在編輯器裏看到"AI 正在執行哪個行爲"、"爲什麼 AI 選了這條分支而不是那條"。
FSM vs 行爲樹：現場改需求的工作量對比
這是最能體現行爲樹價值的場景。
假設開發進行到中期，策劃提出了一個新需求： "當玩家在掩體後超過 5 秒時，敵人應該投擲手雷把玩家逼出來。"
用 FSM 實現這個需求：
新增一個"投擲手雷"狀態。
從每一個可能進入"戰鬥"的狀態（巡邏→發現玩家→追擊→戰鬥→躲掩體→……）畫一條轉移到"投擲手雷"的線。假設涉及 5 個已有狀態，就是 5 條新轉移線。
在每條轉移線上寫條件："玩家在掩體後 > 5 秒"。
考慮"投擲手雷"完成後的轉移：回到戰鬥？回到追擊？回到躲掩體？
考慮併發問題：如果"投擲手雷"和"被手雷炸"同時觸發，誰優先？
測試：確保每條新轉移線在所有場景下都能正確觸發，不會和已有轉移線衝突。
過於複雜實在畫不出來了
用行爲樹實現這個需求：
在 Selector 的"戰鬥"分支下，插入一個新的 Sequence 子節點。
這個 Sequence 包含兩個子節點：Condition（"玩家在掩體後 > 5 秒？"）→ Action（"投擲手雷"）。
完成。0 個已有節點被修改。
這個多清爽
這就是爲什麼 Massive Entertainment 選擇了行爲樹——不是因爲 FSM 做不出《全境封鎖》的 AI 效果。 而是因爲在大規模、多模板、多派閥的開發過程中，行爲樹的修改成本遠低於 FSM(u‿ฺu )。
第五章：《F.E.A.R.》
兩種思路，一個選擇
上一篇中我們簡要提到了 GOAP，說它用"三個狀態 + 一個規劃器"的架構把 FSM 壓縮到了極致。 這裏展開詳述——因爲 GOAP 是行爲樹之外，另一條解決 FSM 侷限性的有效路徑。
在討論遊戲 AI 時，如果不提《F.E.A.R.》（First Encounter Assault Recon, 2005），那就像講操作系統不提 Linux 一樣不完整。
Monolith Productions 的 AI 程序員 Jeff Orkin 在 GDC 2006 上發表了演講：《Three States and a Plan: The A.I. of F.E.A.R.》。 這個演講介紹了一種完全不同於 FSM 和行爲樹的 AI 架構： GOAP（Goal-Oriented Action Planning，面向目標的動作規劃）。
而這套系統之所以讓人印象深刻，不是因爲它用了什麼高深的算法——恰恰相反，它的狀態機部分只有三個狀態： Jeff Orkin 在演講中使用的命名是 Goto / Animate / Use Smart Object：
Goto（移動）： 移動到目標位置。
Animate（動畫）： 執行具體動作（射擊、換彈、翻越掩體、投擲手雷等）。
Use Smart Object（使用場景物體）： 與環境中的智能對象交互。
Jeff Orkin 在演講中提到，Use Smart Object本質上是 Animate 的一個特化版本——所以在某些實現中，底層狀態機實際上只有兩個狀態。 是的，三個狀態。
但就是這個看起來"過於簡單"的狀態機，驅動了遊戲中那些讓無數玩家驚呼"這 AI 也太聰明瞭吧"的敵人行爲。
GOAP 的核心思想：規劃器 + 原子動作
GOAP 的魔法不在於狀態機，而在於它背後的規劃器（Planner）。
規劃器的工作原理是這樣的：
定義目標（Goal）： 比如"消滅玩家"、"找到掩體"、"換彈夾"。
定義原子動作（Action）： 每個動作有前置條件（Precondition）和後置效果（Effect）。比如"射擊"的前置條件是"槍裏有子彈 and 能看到玩家"，後置效果是"玩家受傷"。
規劃（Plan）： 規劃器從當前狀態出發，搜索一條動作序列，使得執行完這條序列後能達到目標。這本質上是一個搜索問題。
執行（Execute）： 將規劃出的動作序列交給狀態機逐個執行。如果執行過程中環境變化導致規劃失效，重新規劃。
舉個具體例子。假設敵人的目標是"消滅玩家"，但槍裏沒有子彈了：
當前狀態：槍裏沒子彈，玩家在掩體後
目標：消滅玩家(҂‾ ▵‾)︻デ═一
規劃結果：
找掩體（前置條件：附近有掩體 → 效果：在掩體後）
換彈夾（前置條件：在掩體後 and 有備用彈夾 → 效果：槍裏有子彈）
從掩體後射擊（前置條件：槍裏有子彈 and 能看到玩家 → 效果：玩家受傷）
如果換彈夾的過程中玩家繞到了側面，規劃器會重新規劃： 也許變成"扔手雷"而不是"射擊"，因爲前置條件滿足了（手雷在包裏 and 玩家在投擲範圍內）。
爲什麼 F.E.A.R. 的敵人給人感覺"極其聰明"
F.E.A.R. 的敵人之所以給玩家留下深刻印象，有幾個關鍵原因：
動態規劃帶來不可預測性。 敵人不是按照預設的腳本行動，而是根據當前環境實時規劃。同樣的初始狀態，如果玩家的走位不同，敵人的應對策略也可能不同。這種"不可預測但合理"的行爲，最接近玩家對"智能"的定義。
環境利用能力。 GOAP 的原子動作可以引用環境信息——"附近有掩體"、"有手雷可用"、"有高臺可以佔據"。規劃器會自動選擇利用這些環境要素的動作序列。玩家覺得敵人"會用環境"，其實是因爲規劃器搜索出了利用環境的最優路徑。
團隊配合的幻覺。 多個敵人使用相同的 GOAP 系統，它們會根據各自的環境條件做出不同的規劃。一個敵人正面射擊吸引注意力，另一個敵人繞到側翼——這在玩家看來是"團隊配合"，但本質上只是兩個獨立的規劃器各自做出了當前最優的決策。
補充： 網上有一些文章把《中土世界：暗影魔多》中的"湧現式敘事"歸因於 GOAP，這是不準確的。Nemesis System（宿敵系統）的核心是一套角色關係追蹤 + 動態敘事生成系統，與 GOAP 的規劃機制不同。GOAP 擅長的是單個 AI 的行爲規劃，湧現式敘事則需要額外的系統來追蹤角色間的關係和事件歷史。
GOAP 與 行爲樹對比
GOAP 是給 AI 裝了個大腦，讓它自己想（靈活但難控）。 行爲樹則是給了 AI 一本操作手冊，讓它照着做（死板但穩定）。
GOAP 爲什麼沒有成爲主流？
GOAP 看起來很香，但它有幾個實質性的侷限：
性能開銷大。 規劃是一個搜索問題。當動作數量多、環境條件複雜時，規劃可能需要顯著的計算時間。不過，業界已有多種優化方案——包括分層規劃、增量規劃、以及規劃結果緩存。在合理的優化下，GOAP 的性能開銷是可以接受的。
調試困難。 當 AI 做出"蠢行爲"時，你需要理解規劃器爲什麼選擇了這條動作序列——是前置條件定義有誤？還是搜索算法找到了次優路徑？這比行爲樹的"這個分支爲什麼沒走到"難定位得多。這是 GOAP 最實際的障礙。
行爲不可控。 規劃器可能組合出設計師沒有預料到的行爲序列——其中有些可能是 bug。行爲樹中，AI 只能做樹裏定義好的事。對於需要精確控制難度曲線的遊戲（如魂系），這一點尤其關鍵。
環境建模複雜。 每個動作都需要精確定義前置條件和後置效果。維護一套完整的"動作-條件-效果"知識庫本身就是一項大工程。
正是因爲這些侷限，GOAP 在實際商業遊戲中的採用率遠不如行爲樹。 但這不意味着 GOAP 沒有價值——在需要高度自適應行爲的場景（如沙盒遊戲、模擬類遊戲）中，GOAP 的規劃能力是行爲樹難以替代的。
遊戲 AI 的首要任務不是"變聰明"，而是"爲玩家提供有趣的挑戰"——這通常需要精確控制 AI 的行爲範圍和強度，而這正是行爲樹的優勢領域┐(´д`)┌。
第六章：《恥辱 2》
爲什麼沉浸式模擬遊戲不用行爲樹？
沉浸式模擬遊戲（Immersive Sim）對 AI 的要求，幾乎是所有遊戲類型中最極端的。
爲什麼？ 因爲沉浸式模擬遊戲的核心設計理念是"給玩家提供多種解決問題的方式"。
在《恥辱 2》（Dishonored 2, 2016）中：
玩家可以正面突突突
可以潛行繞過所有敵人
可以用超能力瞬移到敵人身後暗殺
可以把敵人引到一起讓他們互相誤傷
可以黑入敵人的通訊系統讓他們自相殘殺……
玩家的玩法是不可預測的。 AI 系統必須能應對設計師自己都可能沒有想到的玩家行爲組合。
2017 年，Arkane Studios 的 Laurent Couvidou 和 Xavier Sadoulet 在 GDC 上發了演講：《Taking Back What's Ours: The AI of Dishonored 2》。 這個演講展示了一個面對極端玩家行爲時，AI 系統是怎麼設計和演進的。
規則引擎 vs 行爲樹：Arkane 的選擇
GDC 2017 演講原文顯示，Arkane 的《恥辱 2》AI 決策核心是規則引擎（Rule System）而非行爲樹。
爲什麼沉浸式模擬遊戲選擇了規則引擎？ 因爲沉浸式模擬需要"去中心化"的響應機制。
規則引擎的核心特徵是：
規則可以獨立定義、獨立評估、獨立觸發。
不需要像行爲樹那樣受限於固定的樹形結構。
當玩家做出完全出乎意料的行爲時，規則系統可以通過新增規則來應對，而不需要重構整棵樹。
這正是《恥辱 2》面對"不可預測的玩家"時的最佳選擇。
應對"不可預測的玩家"
《恥辱 2》的 AI 面臨的最大挑戰是玩家超能力的不可預測性。 玩家可能同時使用"時間減速 + 瞬移 + 附身"的組合，也可能把整個場景的物品都變成炸彈。 AI 需要在完全無法預料玩家行爲的前提下，仍然做出合理的反應。
Arkane 的解決方案是基於規則引擎的決策系統：
總共約 6000 條規則： GDC 2017 演講原文列出了 5 組數據（4609、373、596、204、246 條），加起來差不多 6000 條，涵蓋 NPC 行爲、戰鬥策略、對話動畫等多個方面。
數據驅動配置： 這些規則不是硬編碼的——它們是數據驅動的。規則作爲配置數據存在，規則引擎根據當前情境評估並選擇最合適的行爲。這意味着設計師可以在不修改代碼的情況下調整 AI 的行爲。
小隊成員間的情報共享
《恥辱 2》的敵人小隊有一個精妙的設計：情報共享系統。
當一個小隊成員發現玩家時，它不會獨自追擊——它會把玩家的位置信息分享給小隊其他成員。 其他成員收到信息後，會根據各自的位置和狀態做出響應：有的從正面壓制，有的從側翼包抄，有的呼叫增援ᕕ( ᐛ )ᕗ。
這套系統的核心是數據共享機制——規則引擎的每條規則都可以讀取和寫入共享的情報數據。 當一個成員寫入"玩家位置：X, Y, Z"時，其他成員的規則在下一輪評估時就能讀取到這個信息並觸發響應。 這與行爲樹中的"黑板"（Blackboard）概念類似，但實現方式更靈活——規則引擎不需要固定的樹形結構來組織數據讀寫。
複雜系統的"暗坑"
但 Arkane 在實現過程中也發現了一些"暗坑"——那些在理論上很美好、在實踐中卻很棘手的問題：
規則數量爆炸。 6000+ 條規則聽起來很壯觀，但每一條規則都需要測試、驗證、調試。當規則之間存在衝突或優先級不明確時，AI 可能做出不合理的行爲。規則越多，衝突的可能性越大。
決策深度控制。 規則系統可以無限複雜地嵌套——規則引用規則，條件疊加條件……深度超過 5 層後，系統的可讀性急劇下降。調試一個 10 層深的規則鏈，和理解一個 50 個狀態的狀態圖一樣痛苦。
性能優化。 《恥辱 2》的規則評估系統開銷不小——尤其是當場景中有大量 NPC 時。Arkane 需要實現優先級裁剪（低優先級規則在特定條件下跳過評估）、評估頻率調整（不同 NPC 以不同頻率評估規則）、以及觀察者模式（只有情境數據變化時才重新評估相關規則）等優化手段。
數據驅動的雙刃劍。 規則作爲配置數據雖然靈活，但也意味着 bug 可能不在代碼裏而在數據裏。"AI 爲什麼不躲避"可能不是因爲規則邏輯有 bug，而是因爲某條規則的優先級配錯了。這類 bug 往往更難定位。
這些"暗坑"不是某個特定架構的根本缺陷，而是任何複雜系統都會面臨的工程挑戰。 無論是行爲樹、規則引擎還是 GOAP，框架之上仍然需要精心的工程實踐來保證系統的穩定性和可維護性(;´д`)。
第七章：行爲樹的陷阱
那些暗坑
行爲樹不是銀彈。
No Silver Bullet. ——Fred Brooks
有銀彈也不代表能殺掉吸血鬼
你在文檔裏看到的都是"行爲樹多麼優雅、多麼好擴展"——但實際項目中，行爲樹有自己的調試地獄。
這裏單闢一小節，討論行爲樹在工業實踐中最常遇到的三個"暗坑"。
暗坑一：條件抖動（Condition Jitter）
當一個高頻變化的 Condition 節點導致 AI 在兩個行爲之間高頻來回切換時，AI 的表現可能比 FSM 更"智障"。
舉個例子。 AI 的行爲樹頂層有兩個分支：
分支 1（高優）：玩家距離 < 10m → 近戰攻擊
分支 2（低優）：玩家距離 >= 10m → 遠程射擊
如果玩家剛好站在 10m 的邊界上晃動，AI 會在"近戰攻擊"和"遠程射擊"之間每幀切換。 玩家看到的效果就是：AI 像個癲癇患者一樣抽搐——往前衝一步又退回來，舉槍又放下。
怎麼解決？
加遲滯（Hysteresis）： 近戰觸發距離 8m，退出距離 12m。中間留一個"緩衝區"。
降低 Condition 評估頻率： 不是每幀都檢查，而是每 0.5 秒檢查一次。
使用 Service 節點的 Tick 間隔控制： 不要讓 Service 每幀都跑。
暗坑二：Running 節點泄漏
一個永遠返回 Running 的節點會讓 AI"卡死"在一個行爲上，永遠無法被搶佔。
舉個例子。 你寫了一個"移動到目標位置"的 Action 節點。如果目標位置永遠不可達（比如被牆擋住了），這個節點會一直返回 Running。
結果： AI 卡在一個永遠到不了的位置，所有更高優先級的分支都被它佔着位置，無法觸發。 玩家看到的效果就是：AI 對着一面牆發呆，玩家走過去把它打死它都不動。
怎麼解決？
給所有 Running 節點加超時機制。 如果超過 N 秒還在 Running，強制返回 Failure。
用 Blackboard 記錄"嘗試過但失敗的位置"，避免重複嘗試。
代碼審查時重點檢查所有可能永遠 Running 的節點。
暗坑三：深層樹的重入問題
當行爲樹深度超過 5-6 層時，同一幀內的 Tick 遍歷可能出現"重入"——一個節點在同一幀內被多次執行。
這在 Parallel 節點和嵌套 Selector/Sequence 的組合中尤其常見。
舉個例子。 你有一個 Parallel 節點，兩個子分支都引用了同一個"播放動畫"的子樹。如果這個子樹內部有狀態修改（比如設置 Blackboard 變量），同一幀內兩次執行可能導致狀態覆蓋。
結果： AI 播放了錯誤的動畫，或者 Blackboard 數據被意外覆蓋。
怎麼解決？
避免在行爲樹中共享可變狀態。 如果必須共享，確保它是冪等的。
限制行爲樹深度。 超過 5-6 層時考慮拆分成多棵子樹。
在調試工具中標註"重入風險節點"。
第八章：總結
寫到這裏，我們已經走過了從《最後生還者》的 HFSM，到《光環 2》的早期行爲樹實踐，再到《全境封鎖》的大規模行爲樹應用，以及 GOAP 的替代方案和《恥辱 2》的極端場景挑戰。
現在是時候回答一個核心問題了： 行爲樹到底是神器，還是又一個被過度吹捧的技術？
技術演進的啓示
回顧整個技術演進歷程，有幾個清晰的趨勢：
從"能做什麼"到"能改什麼"。 FSM 的瓶頸不是功能不夠——理論上 FSM 可以模擬任何行爲樹的邏輯。它的瓶頸是修改成本。當狀態數超過某個閾值，加一個行爲的成本變得不可接受。行爲樹解決的正是這個問題——它讓新增行爲的成本從 O(N) 降爲 O(1)。
從"單體決策"到"分層架構"。 《最後生還者》的 Skills Priority Stack + Behaviours 兩層架構，本質上是把決策和執行解耦。行爲樹的 Selector / Sequence 組合機制，則是把優先級和步驟解耦。分層解耦是管理複雜度的通用方法。
從"硬編碼"到"數據驅動"。 《全境封鎖》的行爲樹配置、《恥辱 2》的規則系統，都體現了同一個趨勢——把 AI 行爲從代碼中抽離出來，變成可配置的數據。這讓設計師（不僅僅是程序員）可以參與 AI 調優，也讓迭代速度大幅提升。
2020 年代的新趨勢：混合架構
進入 2020 年代後，遊戲 AI 架構呈現出明顯的混合化趨勢——不再追求"用一種架構解決所有問題"，而是根據場景組合使用多種技術：
Utility AI + 行爲樹混合。 《模擬人生》（The Sims）系列長期使用的 Utility AI 在近年受到更多關注——它的核心是"給每個可選行爲打分，選最高分"，就像 Sim 們會根據飢餓、社交、娛樂等需求的緊急程度自動決定"先去喫飯還是先去社交"。現代實踐中，常見的模式是用 Utility AI 做高層決策（選哪個行爲），用行爲樹做底層執行（行爲的具體步驟）。這種組合兼顧了靈活性和可控性。
更好的行爲樹案例。 如果你想了解行爲樹在現代遊戲中的表現，以下幾個案例值得研究：
《Alien: Isolation》（2014）： 異形 AI 使用雙層 AI 系統——"導演 AI"（知道玩家位置但不可直接攻擊）控制"異形 AI"（不知道玩家位置但會搜索），行爲樹在其中扮演了關鍵角色（Mike Lipshaw, GDC Europe 2015）。
《Halo 3》（2007）： Bungie 在《光環 2》的基礎上進一步進化了行爲樹架構，增加了更完善的並行行爲支持和更精細的優先級控制。
《地平線：零之曙光》（2017）： Guerrilla Games 的機器獸 AI 使用了複雜的行爲樹系統，不同機器獸有不同的行爲樹配置，支持動態行爲切換。
機器學習輔助 AI。 雖然深度學習尚未取代傳統的基於規則的 AI 架構（因爲可控性要求），但在特定子任務上已有應用——如《Forza Motorsport》中的駕駛 AI 使用了強化學習來優化賽車線。
核心趨勢總結： 遊戲 AI 正在從"單一架構之爭"走向"實用主義混合"。選擇哪種架構不再是信仰問題，而是工程問題——根據項目需求、團隊技能和開發週期做出最務實的選擇。
行爲樹的核心價值和代價
核心價值：
可中斷： 優先級搶佔不需要顯式寫中斷邏輯。
可複用： 行爲節點可以被多個分支引用（DAG 結構）。
可擴展： 新增行爲只需要插入新分支，不影響已有節點。
可讀性： 樹形結構直觀反映決策邏輯。
可調試： 可以實時觀察 AI 的執行路徑。
代價：
學習成本： 理解 Tick 機制、Selector / Sequence 邏輯、Running 狀態的搶佔行爲，需要一定的學習投入。
運行時開銷： 每幀遍歷樹比狀態查詢開銷大。需要優化（Observer Abort、Tick 頻率調整等）。
調試複雜度： 深度嵌套的行爲樹同樣難以理解。Parallel 節點會增加調試難度。
過度設計的風險： 不是所有 AI 都需要行爲樹。簡單 AI 用行爲樹是殺雞用牛刀。
技術選型決策框架
如果你在開發一款遊戲，在 FSM 和行爲樹之間猶豫，可以參考這個決策框架。
注意： 這個框架沒有考慮最關鍵的現實變量——團隊能力。 一個對 FSM 有豐富經驗、有完善自研調試工具的團隊，和一個熟悉 UE4 行爲樹但缺乏深入理解的新手團隊，他們的技術選型會截然不同。 架構選擇從來不只看技術優劣，更要看團隊能不能駕馭它。
沒有最好的架構，只有最適合當前項目需求的架構。 行爲樹不是通解——它只是管理 AI 複雜度的一個工具。 用好它的前提是理解它的優勢和代價，然後在合適的場景下使用它。
下期預告
如果你已經讀到這裏，說明你對遊戲 AI 這個話題是真的感興趣。
下一期，我們會聊一個更加有趣的話題：Utility AI（效用 AI）和 AI 動態難度調整實踐。
簡單來說，Utility AI 讓 AI 的決策不再基於"滿足 / 不滿足"的二元條件，而是基於"這個行爲有多好"的量化評分。
AI 不再問"我該不該逃跑"，而是問"逃跑、進攻、躲掩體、扔手雷——哪個效用值最高"。
更重要的是，我們會討論Utility AI 在動態難度調整（DDA）中的應用——這正是現代遊戲實現"無感難度調節"的核心技術：通過量化評估玩家當前狀態，實時調整 AI 的行爲傾向、反應速度和資源分配，讓遊戲始終保持在"既不太簡單、也不太困難"的心流區間。
這種技術在《求生之路》的 AI Director、《生化危機4》的動態難度系統、以及多款現代獨立遊戲中都有成功應用。
這套思路比傳統難度分級更自然（沒有"簡單/普通/困難"的硬性切換），比固定腳本更靈活（AI 行爲隨玩家表現實時變化）——而且它的核心思想（給每個選項打分然後選最高的）其實非常直覺。
如果你對遊戲 AI 感興趣，或者正在爲自己的遊戲選擇 AI 架構，下一期內容一定不要錯過。
感謝閱讀！(๑•ㅂ•)✧
附錄：關於 AI"讀指令"的常見誤解
Tick 機制本身不區分"世界狀態變化"和"按鍵輸入"。 如果 AI 沒有感知延遲，它可以在手雷生成的同一幀做出反應——這在物理上當然不可能（信息傳遞需要時間），但在代碼層面它確實可以。這就是爲什麼有些遊戲的 AI 會讓玩家覺得"它讀了我的指令"。
"讀指令"在玩家社區裏是個更廣義的概念，不只是指 AI 直接讀取你的按鍵輸入，更指 AI 以遠超人類反應速度（<100ms）對任何可觀測的行爲做出完美反應——哪怕是彈道出現或角色起跳動作的第一幀。 不公平感的來源不一定是 AI 作弊了，更可能是它反應得太完美了，完美到不像人類 (攤手)。
真正"公平"的 AI 設計，不會讓 Tick 機制裸奔。 負責任的實現會在 AI 和環境之間加入"感知延遲"——比如 AI 的視野檢查每隔 0.2 秒才觸發一次，聽覺範圍加一個模糊半徑，讓 AI 不能"看到"牆壁後面的東西，甚至在看到玩家後先"愣"零點幾秒再反應。 這纔是"公平的挑戰"和"作弊的讀指令"之間的界線。
本文基於公開 GDC 演講和技術資料整理，不同工作室的實現細節可能有所差異。歡迎評論區交流指正，我會持續更新完善。
參考文獻
系列文章索引：
第一篇（FSM）：【遊戲科普】你以爲Boss在思考？關於遊戲AI背後的有限狀態機
第二篇（行爲樹）：本文
第三篇（預告）：Utility AI + 混合架構實踐
Travis McIntosh. "The Last of Us: Human Enemy AI." GDC 2014. Naughty Dog. 介紹了 Hunter AI 的 Skills + Behaviours 兩層架構、視覺視錐和音頻傳感器感知系統，以及"讓角色不做蠢事"的核心設計理念。
Damian Isla. "Handling Complexity in the Halo 2 AI." GDC 2005. Bungie Studios. 介紹了《光環 2》中 Covenant 敵人的 Objective Tree（目標樹）架構，包括優先級裁決、步驟執行和行爲複用。這是樹形優先級決策結構在 3A 遊戲中的開創性應用。
Philip Dunstan & Drew Rechner. "Blending Autonomy and Control: Creating NPCs for Tom Clancy's The Division." GDC 2016. Massive Entertainment. 介紹了《全境封鎖》中 11 種 AI 模板和 5 個派閥的行爲樹實現，以及可視化編輯器和運行時調試工具的開發。
Jeff Orkin. "Three States and a Plan: The A.I. of F.E.A.R." GDC 2006. Monolith Productions. 介紹了 GOAP（Goal-Oriented Action Planning）系統在《F.E.A.R.》中的應用，包括規劃器原理、大量目標（dozens of goals）的動態選擇、以及只有三個狀態（Goto、Animate、Use Smart Object）的狀態機架構。
Laurent Couvidou & Xavier Sadoulet. "Taking Back What's Ours: The AI of Dishonored 2." GDC 2017. Arkane Studios. 介紹了《恥辱 2》中應對不可預測玩家行爲的 AI 系統，包括約 6000 條規則（GDC 原文列出 5 組數據：4609、373、596、204、246），以及小隊情報共享機制。
Ian Millington. Artificial Intelligence for Games. CRC Press, 2009. 遊戲 AI 領域的經典教材，全面介紹了 FSM、行爲樹、GOAP 等技術的理論和實踐。
Unreal Engine Documentation. "Behavior Trees." Epic Games. Unreal Engine 官方行爲樹文檔，介紹了 Blackboard、Service、Task 等核心概念以及可視化工具的使用。
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
