# 06｜商業遊戲 AI 的隱藏層：真正稀缺的是組合，而非基礎演算法
## The Hidden Layer of Commercial Game AI: Composition, Not Primitives, Is the Scarce Knowledge

**系列：**《可執行資料與深層解構學習》  
**篇次：** 06 / 10  
**作者：** Neo.K with Aletheia  
**機構：** EveMissLab／一言諾科技有限公司  
**版本：** v0.1 Research Draft  
**日期：** 2026-08-16  
**文件性質：** 商業遊戲 AI／系統組合／Production Architecture／AI Tooling／深層解構方法論  
**範圍聲明：** 本文討論一般遊戲 AI 工程架構與可公開技術材料，不宣稱知道任何未公開商業遊戲的專有內部實作。對特定遊戲的內部架構若無直接公開證據，應視為觀察、候選假說或獨立重建，而非官方事實。

---

## 摘要

有限狀態機、行為樹、A*、Utility AI、Goal-Oriented Action Planning、Blackboard、Scheduler、Influence Map、Steering、Navigation Mesh 等技術，早已存在於遊戲 AI 教材、論文、引擎文件與開發者演講中。因此，如果商業遊戲 AI 的真正困難只是「知道有哪些演算法」，那麼高品質遊戲 AI 應早已成為容易複製的標準商品。

然而，實際遊戲開發顯示，單一 primitive 很少能獨立構成玩家所感知的完整智能。Unreal Engine 的官方 AI 架構即明確將 Behavior Tree、Blackboard、AI Perception、Environment Query System 與 AI Debugging 作為相互協作的工具；F.E.A.R. 的 Goal-Oriented Action Planning 實作亦指出，真正把即時規劃放入 AAA 遊戲時，必須處理 CPU 預算、distributed processing、cache，以及與 physics、animation、rendering 共存的整體 agent architecture。Halo 系列公開技術演講則長期將 decision making、knowledge representation、behavior tree 演化、設計工具與「如何讓角色看起來具有智能」放在同一生產問題中。

因此本文提出：

$$
\boxed{
\text{Primitive Knowledge}
\neq
\text{Production Intelligence}
}
$$

以及核心命題：

$$
\boxed{
\text{The hidden layer of commercial game AI is often composition, not primitives.}
}
$$

本文將商品級遊戲智能表示為：

$$
\boxed{
\mathfrak A
=
(
\mathcal P,
\mathcal C,
\mathcal W,
\mathcal T,
\mathcal I,
\mathcal F,
\mathcal L,
\mathcal D
)
}
$$

其中：

- $\mathcal P$：primitive set；
- $\mathcal C$：composition graph；
- $\mathcal W$：shared world / agent state；
- $\mathcal T$：timing and scheduling policy；
- $\mathcal I$：interrupt / priority / arbitration policy；
- $\mathcal F$：fallback and failure recovery；
- $\mathcal L$：simulation level-of-detail and resource policy；
- $\mathcal D$：debugging、authoring、content tooling 與 production workflow。

同一個 Behavior Tree primitive，在不同 Blackboard schema、perception 更新節奏、EQS query、interrupt 規則、animation gate、navigation fallback、content tuning 與 CPU budget 下，可以形成完全不同的玩家體驗。因此「知道某遊戲使用 BT」對真正重建其智能而言，資訊量非常低。

本文進一步提出「組合知識缺口」（Composition Knowledge Gap）：

$$
\boxed{
\Gamma_C
=
K_{\mathrm{production}}
-
K_{\mathrm{primitive}}
}
$$

其中真正難以由教材直接取得的部分，往往包括：

- 模組如何接；
- 哪一層擁有決策權；
- 誰能 interrupt 誰；
- shared state 如何維持；
- 不同更新頻率如何協調；
- 離屏角色如何降階模擬；
- planner 失敗如何 fallback；
- pathfinding、animation 與 decision 如何互鎖；
- designer 如何 author 行為；
- 如何 debug；
- 如何在 CPU budget 中維持可接受智能；
- 如何讓內容與演算法共同形成玩家感知到的「聰明」。

本文最後提出「Composition Archaeology」作為商業遊戲智能考古的核心方法：研究單位不應只標註某遊戲用了什麼演算法，而應重建其功能模組、共享狀態、控制權、時序、資源、失敗路徑與工具鏈。只有如此，AI 才可能從「看懂 primitive」進一步學會「組裝出可運行商品級系統」。

**關鍵詞：** Game AI、Behavior Tree、GOAP、FSM、Composition、Blackboard、EQS、AI Perception、Scheduler、Interrupt、Production Architecture、AI Debugging

---

# 1. 問題：如果演算法都公開了，為什麼還是很難？

現代遊戲 AI 的基本 primitive 並不神秘。

常見技術包括：

$$
\mathcal P
=
\{
FSM,
HFSM,
BT,
A^*,
Utility,
GOAP,
HTN,
Blackboard,
Scheduler,
Steering,
InfluenceMap,
\ldots
\}.
$$

大量教材可以解釋：

- FSM 如何切 state；
- A* 如何尋路；
- Behavior Tree 如何執行 selector / sequence；
- Utility 如何計分；
- GOAP 如何從 goals 與 actions 搜尋 plan；
- Blackboard 如何共享資料。

因此最簡單的假設會是：

$$
\boxed{
\text{Know the primitives}
\Rightarrow
\text{Can build commercial AI}.
}
$$

但實務上這個推論並不成立。

---

# 2. Primitive 是零件，不是產品

假設一個遊戲有：

$$
P_1=\text{Behavior Tree}
$$

與：

$$
P_2=\text{A*}.
$$

僅知道：

$$
\{P_1,P_2\}
$$

並不能回答：

- Behavior Tree 何時 tick？
- 路徑何時重算？
- Perception 更新時是否立即打斷？
- 失去視線多久才取消 chase？
- Blackboard 哪些 key 是 persistent？
- path fail 後回到哪個 branch？
- animation 是否可以阻止決策切換？
- combat montage 期間能否重新規劃？
- 多個 NPC 是否共享 threat state？
- 離屏 NPC 是否仍跑完整 BT？

所以：

$$
\boxed{
\text{Set of Parts}
\neq
\text{System}.
}
$$

---

# 3. 組合圖

本文將 primitive 的實際組合表示為：

$$
\boxed{
\mathcal C
=
(V,E,\tau,\pi,\iota,\phi)
}
$$

其中：

- $V$：功能節點；
- $E$：依賴與資料流；
- $\tau$：timing / update rate；
- $\pi$：priority；
- $\iota$：interrupt relations；
- $\phi$：fallback / failure transitions。

真正的 AI behavior 是：

$$
\boxed{
B
=
Exec(
\mathcal P,
\mathcal C,
W,
E_t
).
}
$$

其中：

- $W$：world / agent state；
- $E_t$：環境事件與時間條件。

---

# 4. 同一 primitive 可以生成完全不同的 AI

假設兩個遊戲都使用：

$$
BT.
$$

遊戲 A：

```text
Perception
→ Blackboard
→ BT
→ Move
```

遊戲 B：

```text
Perception
→ Threat Memory
→ Blackboard
→ Tactical Query
→ BT
→ Animation Gate
→ Navigation
→ Squad Coordinator
→ World Event
```

二者都可以說：

> 使用 Behavior Tree。

但這個描述的判別力非常低。

因此：

$$
\boxed{
\text{Primitive Label}
\ll
\text{Composition Description}.
}
$$

---

# 5. Unreal Engine 已經公開展示這種組合性

Unreal Engine 官方 AI 文件並不是只提供 Behavior Tree。

其 AI 工具至少明確包含：

- AI Controller；
- Behavior Tree；
- Blackboard；
- AI Perception；
- Environment Query System；
- Navigation；
- AI Debugging。

AI Perception 可以接受 sight、sound、damage 等刺激，再更新 Behavior Tree 所依賴的 Blackboard state。

EQS 可以根據環境產生 candidate locations，再以多個 tests 評分，將最佳結果回傳 Blackboard。

Behavior Tree 再根據 Blackboard keys 決定執行分支。

因此最簡化的官方工作流已經是：

$$
\boxed{
\text{Perception}
\rightarrow
\text{Shared State}
\rightarrow
\text{Environmental Query}
\rightarrow
\text{Decision}
\rightarrow
\text{Action}.
}
$$

這本身就是一個 composition system。

---

# 6. Blackboard 的價值不只是「存變數」

若 Blackboard 只有：

```text
EnemyVisible = true
```

它只是共享變數。

但商品級系統可能包含：

```text
CurrentTarget
LastKnownTargetLocation
ThreatLevel
CurrentGoal
CoverPoint
SquadOrder
NeedAmmo
UnderFire
LastDamageTime
InvestigationLocation
```

此時：

$$
\boxed{
\text{Blackboard Schema}
}
$$

已經等於部分認知架構。

也就是：

> AI 被允許知道什麼？

本身就是設計問題。

---

# 7. Perception 不是感測器列表，而是信息政策

假設 AI sight range：

$$
r_s.
$$

sound range：

$$
r_a.
$$

memory duration：

$$
T_m.
$$

這些參數不是純 technical detail。

它們直接改變：

$$
\boxed{
\text{What the agent can know}.
}
$$

若 AI 永遠知道玩家座標：

$$
O(s)=s_{\mathrm{player}}.
$$

則它與需要視線、聲音、記憶推斷的 AI 完全不同。

所以：

$$
\boxed{
\text{Perception Policy}
}
$$

是 composition 的一級部分。

---

# 8. Query System 不是 Behavior Tree 的附屬品

Behavior Tree 可以知道：

> 我要找 cover。

但：

> cover 在哪？

是另一個問題。

EQS 這類 query system 將環境搜索獨立成：

$$
\boxed{
\text{Candidate Generation}
+
\text{Scoring}.
}
$$

例如：

$$
Q(c)
=
w_1Cover(c)
+
w_2Distance(c)
+
w_3LOS(c)
+
w_4Threat(c).
$$

這是一個可與 BT、Utility 或 planner 組合的子系統。

---

# 9. Decision 與 Action 之間還有 Execution Layer

假設 AI 決定：

$$
a=\text{Attack}.
$$

這不代表 action 已完成。

還需要：

- turn；
- aim；
- move；
- animation；
- weapon；
- cooldown；
- collision；
- hit detection；
- damage；
- interruption。

因此：

$$
\boxed{
\text{Decision}
\neq
\text{Execution}.
}
$$

商業遊戲 AI 的大量 bug 就發生在這兩層之間。

---

# 10. Animation 是 AI 架構的一部分

教材容易把 animation 當成 presentation。

但例如：

- attack animation 不可隨意中斷；
- reload 有 committed phase；
- hit reaction 會取得控制權；
- vault animation 需要 navigation alignment；
- locomotion state 會限制 action availability。

因此：

$$
\boxed{
\text{Animation State}
\leftrightarrow
\text{Decision State}.
}
$$

如果忽略這個 coupling，生成的 AI 可能邏輯正確但實際不可玩。

---

# 11. Navigation 也不是一個單獨的 A*

教材可能寫：

$$
\text{Path}=A^*(start,goal).
$$

但商品級導航還可能需要：

- navmesh；
- local avoidance；
- dynamic obstacle；
- off-mesh link；
- crowd；
- door state；
- jump / climb；
- path invalidation；
- repath threshold；
- movement animation；
- network correction。

所以：

$$
\boxed{
A^*
\neq
\text{Navigation System}.
}
$$

---

# 12. Planner 也不是一個搜尋演算法

F.E.A.R. 的 GOAP 歷史案例特別適合說明這一點。

Jeff Orkin 在 AIIDE 2005 論文中指出，即時 planning 的優點包括：

- 更能處理 unexpected situations；
- goals / actions 可以 modularize；
- behavior building blocks 容易 reuse / share / maintain。

但代價是 CPU。

而遊戲 CPU 同時還要支援：

- physics；
- animation；
- rendering。

所以 planner 必須依賴：

- distributed processing；
- caching；
- 更大的 agent architecture 支援。

這表示：

$$
\boxed{
\text{Planner Algorithm}
\subset
\text{Planning Production System}.
}
$$

---

# 13. 即時限制會反過來改演算法

理論上最好的 decision：

$$
a^\*
=
\arg\max_a U(a)
$$

如果計算需要：

$$
300\text{ ms}
$$

而遊戲 frame budget：

$$
16.67\text{ ms},
$$

則它可能沒有產品價值。

因此：

$$
\boxed{
\text{Game AI}
=
\text{Intelligence under Resource Constraints}.
}
$$

---

# 14. CPU Budget 是認知架構的一部分

令：

$$
B_{CPU}
$$

為 AI 可用計算預算。

則不同 agent 可能被分配：

$$
b_i.
$$

要求：

$$
\sum_i b_i
\leq
B_{CPU}.
$$

此時 AI design 不只是：

> 每個 NPC 如何做最好的決策？

而是：

> 在所有 NPC 與其他 game systems 都要跑的情況下，如何分配智能？

---

# 15. Simulation LOD

因此大型世界常需要：

$$
\boxed{
\text{Simulation Level of Detail}.
}
$$

例如：

### Near Player

$$
L_{\mathrm{near}}
=
\text{full perception + decision + navigation}.
$$

### Mid Distance

$$
L_{\mathrm{mid}}
=
\text{reduced update frequency}.
$$

### Far / Offscreen

$$
L_{\mathrm{far}}
=
\text{aggregate / statistical update}.
$$

所以一個角色的「AI」其實可能隨觀測尺度切換。

---

# 16. Update Rate 直接改變智能表現

假設：

$$
\tau_p
$$

為 perception update interval。

$$
\tau_d
$$

為 decision interval。

$$
\tau_n
$$

為 navigation interval。

如果：

$$
\tau_p
=
0.1s
$$

與：

$$
\tau_p
=
2s,
$$

玩家感受到的 AI 反應能力會完全不同。

因此：

$$
\boxed{
\text{Timing}
}
$$

不是 implementation detail。

---

# 17. Interrupt 是最被低估的智能 primitive 之一

假設 AI 正在：

$$
Task_1=\text{Eat}.
$$

突然：

$$
Event=\text{EnemyAttack}.
$$

是否：

$$
Interrupt(Task_1)?
$$

取決於：

- threat；
- current phase；
- task commitment；
- animation；
- resource；
- priority；
- cooldown。

所以：

$$
\boxed{
\iota:
(\text{Task},\text{Event},\text{State})
\rightarrow
\{\text{Continue},\text{Pause},\text{Abort},\text{Replace}\}.
}
$$

這是一個核心控制結構。

---

# 18. 沒有 Interrupt，世界就會顯得「腳本化」

即使每個行為本身寫得很好，

若：

$$
Task
$$

一旦開始就不能被新事件打斷，

角色就容易出現：

- 被攻擊還吃飯；
- 火災仍工作；
- 玩家靠近仍照巡邏；
- 世界已變化但 plan 不更新。

所以：

$$
\boxed{
\text{Responsiveness}
\propto
\text{Interrupt Architecture}.
}
$$

---

# 19. Priority Arbitration

當同時存在：

$$
\{
Need,
Threat,
Order,
Goal,
Social,
Quest,
Environment
\}
$$

時，需要：

$$
\boxed{
\pi:
\text{Candidates}
\rightarrow
\text{SelectedAction}.
}
$$

而：

$$
\pi
$$

可以是：

- fixed priority；
- utility score；
- planner cost；
- rule ordering；
- learned policy；
- hybrid。

真正商品級問題是：

> 這些 arbitration mechanism 如何互相嵌套？

---

# 20. 多層 arbitration

例如：

```text
Safety Gate
    ↓
Interrupt Priority
    ↓
Strategic Goal
    ↓
Task Utility
    ↓
Behavior Tree
    ↓
Action Preconditions
```

此時：

$$
\boxed{
\pi
=
\pi_1
\circ
\pi_2
\circ
\cdots
\circ
\pi_k.
}
$$

只說：

> 這是一個 Utility AI。

已經無法描述整體。

---

# 21. Fallback 決定 AI 是否耐用

如果 AI 要：

> MoveTo Cover

但：

$$
PathFail=1,
$$

它怎麼辦？

可能：

- 找第二個 cover；
- 改站立射擊；
- 撤退；
- 等待；
- 重算；
- teleport；
- abort plan。

因此需要：

$$
\boxed{
\phi:
\text{Failure}
\rightarrow
\text{Recovery}.
}
$$

成熟 AI 的很大一部分其實是：

> 正常計畫失敗後還能不能繼續玩。

---

# 22. Happy Path 不是產品

教材示例通常：

```text
see enemy
→ chase
→ attack
```

商品世界則會出現：

```text
see enemy
→ path blocked
→ target disappears
→ ally occupies cover
→ weapon empty
→ animation interrupted
→ door closes
→ navmesh changes
```

所以：

$$
\boxed{
\text{Production AI}
=
\text{Happy Path}
+
\text{Failure Space}.
}
$$

---

# 23. Shared State 與局部狀態

如果每個 NPC 完全獨立：

$$
W_i.
$$

則 squad behavior 很難成立。

可能需要：

$$
W_{\mathrm{shared}}
$$

保存：

- enemy location；
- squad target；
- cover reservation；
- command；
- alarm state；
- faction state。

因此：

$$
\boxed{
W
=
W_{\mathrm{local}}
\oplus
W_{\mathrm{shared}}.
}
$$

---

# 24. Squad Intelligence 不是多個單體 AI 相加

假設：

$$
N
$$

個 NPC 各自很聰明。

仍不保證：

$$
\boxed{
\text{Group Intelligence}
}
$$

出現。

還需要：

- role allocation；
- shared target；
- reservation；
- formation；
- coordination；
- communication；
- conflict resolution。

因此：

$$
\boxed{
\sum_i Intelligence_i
\neq
Intelligence_{\mathrm{group}}.
}
$$

---

# 25. Halo 的歷史案例：表象智能與製作工具

Bungie 過去公開 AI 演講很早就以：

# The Illusion of Intelligence

描述 Halo 的 AI 設計目標。

這個名稱本身已經指出：

> 玩家感受到的智能，不等於內部演算法在抽象意義上的智能程度。

公開演講同時討論：

- design goals；
- technical constraints；
- framework elements；
- level creation；
- production tools；
- player experience。

因此：

$$
\boxed{
\text{Perceived Intelligence}
=
f(
AI,
Level,
Animation,
Content,
Tools,
Presentation
).
}
$$

---

# 26. 「看起來聰明」可能來自關卡設計

一個敵人知道：

> 從左側 flank。

可能不是因為它建立完整 3D 戰術模型。

也可能因為：

- designer 放置 tactical point；
- navmesh 提供 route；
- encounter script 控制時機；
- cover system 限制選項。

因此：

$$
\boxed{
\text{AI Behavior}
}
$$

與：

$$
\boxed{
\text{Level Affordance}
}
$$

高度耦合。

---

# 27. Content 也是演算法的一部分嗎？

嚴格來說：

$$
\text{Content}
\neq
\text{Algorithm}.
$$

但從產品行為來看：

$$
\boxed{
\text{Behavior}
=
\text{Algorithm}
\times
\text{Content}.
}
$$

例如 planner 有：

$$
10
$$

個 action definitions

與：

$$
1000
$$

個 action definitions

會形成不同的可行策略空間。

所以 content authoring 直接決定 AI 能做什麼。

---

# 28. Data-Driven AI

成熟遊戲常希望 designer 可以修改：

- action；
- condition；
- weight；
- goal；
- animation；
- query；
- tuning parameter；

而不重新編譯核心 engine。

因此：

$$
\boxed{
\text{AI Architecture}
+
\text{Authoring Data}.
}
$$

這使 production AI 具有一個教材常低估的資料層。

---

# 29. Tooling 是 AI 系統的一部分

如果一個 AI 架構理論上很強，

但 designer：

- 看不到 state；
- 無法追蹤 branch；
- 不知道為什麼選這個 action；
- 無法重播；
- 無法修改 parameter；

則它很難進入大型商業製作。

所以：

$$
\boxed{
\text{Authorability}
+
\text{Debuggability}
}
$$

是 production viability 的必要條件之一。

---

# 30. Unreal AI Debugging 是很直接的例子

Unreal 官方 AI Debugging 工具允許觀察：

- Behavior Tree；
- Blackboard；
- Perception；
- EQS。

這揭示一個重要工程事實：

> AI 不只是要能跑，還必須能被理解為什麼這樣跑。

因此：

$$
\boxed{
\text{Observability}
}
$$

是 production architecture 的一級能力。

---

# 31. GOAP 十年後仍然需要 Debug / Analytics

GDC 2015 的 GOAP 回顧並沒有只重新介紹 planning。

該 multi-studio session 明確討論：

- AAA 世代需求如何使 GOAP implementation 演化；
- novel / unexpected behaviors 如何 debugging / reporting；
- analytics 如何分析 planning patterns。

這表示即使 primitive 不變：

$$
GOAP_{2005}
$$

與：

$$
GOAP_{2015}
$$

的 production system 仍可能差很多。

---

# 32. Primitive Stability 與 Composition Evolution

可以存在：

$$
P_t
\approx
P_{t+10}
$$

但：

$$
C_t
\neq
C_{t+10}.
$$

也就是：

> 基礎演算法多年沒變，但它被接入整個產品的方式一直演化。

這也是為什麼只讀 primitive 教材容易低估業界累積。

---

# 33. Production Knowledge 的真正內容

本文定義：

$$
\boxed{
K_{\mathrm{production}}
=
K_P
+
K_C
+
K_T
+
K_I
+
K_F
+
K_R
+
K_D
}
$$

其中：

- $K_P$：primitive；
- $K_C$：composition；
- $K_T$：timing；
- $K_I$：interrupt / arbitration；
- $K_F$：failure handling；
- $K_R$：resource policy；
- $K_D$：debug / authoring / production practice。

---

# 34. Public Primitive Knowledge

一般公開教材最容易保存：

$$
K_P.
$$

因為它：

- 容易抽象；
- 容易寫成章節；
- 容易畫圖；
- 容易教；
- 跨遊戲可泛化。

因此：

$$
\boxed{
K_{\mathrm{public}}
\approx
K_P
+
\text{部分 }K_C.
}
$$

---

# 35. Composition Knowledge Gap

本文提出：

$$
\boxed{
\Gamma_C
=
K_{\mathrm{production}}
-
K_{\mathrm{primitive}}.
}
$$

這不是說業界刻意把所有東西藏起來。

 $\Gamma_C$ 的來源還包括：

- tacit knowledge；
- company-specific tooling；
- accumulated patches；
- project history；
- designer habit；
- performance constraints；
- content pipeline；
- undocumented conventions。

---

# 36. 隱藏層不是陰謀論

需要明確區分：

$$
\boxed{
\text{Hidden}
\neq
\text{Secret}.
}
$$

很多 composition knowledge 並沒有被刻意保密。

它只是：

- 太瑣碎；
- 太專案特定；
- 太難寫成論文；
- 散在 source；
- 散在 designer workflow；
- 散在 bug fix；
- 散在工具；
- 散在團隊經驗。

因此不會自然出現在教科書。

---

# 37. 這就是為什麼 Source Code 仍然不夠

完整 source 可以告訴 AI：

$$
\text{What exists}.
$$

但要得到：

$$
\text{Why it is structured this way}
$$

與：

$$
\text{Which parts generalize},
$$

還要做：

- dependency analysis；
- temporal analysis；
- runtime tracing；
- failure analysis；
- cross-game normalization；
- historical comparison；
- functional typing。

因此：

$$
\boxed{
\text{Code Reading}
<
\text{Production Deconstruction}.
}
$$

---

# 38. Composition Archaeology

本文提出：

# **Composition Archaeology**

作為 Game Intelligence Archaeology 的核心子方法。

目標不是：

> 找出用了哪些演算法。

而是建立：

$$
\boxed{
\mathcal C_g.
}
$$

---

# 39. Composition Archaeology 的八個問題

對任一 subsystem，至少回答：

### 1. Input

它吃什麼？

### 2. State

它保存什麼？

### 3. Decision

誰做選擇？

### 4. Timing

何時執行？

### 5. Priority

誰比誰高？

### 6. Interrupt

什麼能打斷？

### 7. Failure

失敗後去哪？

### 8. Output

結果如何提交回世界？

---

# 40. 九個補充問題

成熟研究還要問：

1. 是否有 shared state？
2. 是否有 cache？
3. 是否有 LOD？
4. 是否有 async job？
5. 是否有 reservation？
6. 是否有 debug trace？
7. designer 如何 author？
8. 參數如何 tuning？
9. 不同版本如何改？

---

# 41. Composition Graph Schema

可使用：

```yaml
composition:
  nodes:
  edges:

  perception:
  memory:
  shared_state:
  decision:
  planning:
  query:
  scheduler:
  navigation:
  execution:
  animation:
  coordination:
  persistence:

  timing:
  priorities:
  interrupts:
  fallback:
  simulation_lod:
  resource_budget:

  authoring:
  debugging:
  telemetry:
```

---

# 42. Functional Node

每個 node 不應只有原遊戲名稱。

例如：

```yaml
source_name: ThinkTree
functional_type: candidate_selection
```

或：

```yaml
source_name: TacticalPointQuery
functional_type: environment_candidate_scoring
```

這樣才能跨遊戲正規化。

---

# 43. Edge Type

關係可以包含：

```text
reads
writes
triggers
interrupts
blocks
schedules
queries
reserves
commits
invalidates
fallback_to
shares_state_with
```

這比一般 dependency graph 更接近 AI control graph。

---

# 44. Timing Annotation

```yaml
update:
  mode: event_driven
  interval: null
```

或：

```yaml
update:
  mode: periodic
  interval_ms: 500
```

若未知：

```yaml
update:
  mode: inferred
  confidence: 0.4
```

---

# 45. Control Ownership

對每個 state 要標：

> 誰擁有控制權？

例如：

```text
StrategicPlanner
CombatController
Animation
ScriptedSequence
SafetyOverride
```

這能重建：

$$
\boxed{
\text{Control Hierarchy}.
}
$$

---

# 46. Control Hierarchy

令：

$$
H_C
$$

為控制權偏序。

例如：

$$
Safety
\succ
ScriptedCinematic
\succ
Combat
\succ
Routine.
$$

若沒有這個資訊，只看 BT graph 仍可能誤解真正行為。

---

# 47. Temporal Composition

有些模組不是上下層，而是不同時間尺度。

例如：

$$
Strategic:
10s
$$

$$
Tactical:
1s
$$

$$
Reactive:
50ms.
$$

因此：

$$
\boxed{
\mathcal C
}
$$

還需要 temporal topology。

---

# 48. Macro–Meso–Micro 組合

可以表示：

$$
\mathcal C
=
\mathcal C_{\mathrm{macro}}
\oplus
\mathcal C_{\mathrm{meso}}
\oplus
\mathcal C_{\mathrm{micro}}.
$$

例如：

- macro：faction strategy；
- meso：squad task；
- micro：movement / attack。

它們之間以：

$$
\boxed{
\text{Constraint Down}
+
\text{State Up}
}
$$

互動。

---

# 49. AI 的「聰明」可能來自良好約束

如果角色只有：

$$
5
$$

個選項，

但每個選項都在正確 context 開放，

玩家可能感覺它很聰明。

相反，如果有：

$$
100
$$

個 action，

但 arbitration 很差，

角色可能顯得混亂。

所以：

$$
\boxed{
\text{Behavioral Richness}
\neq
\text{Action Count}.
}
$$

---

# 50. Composition 可以壓縮複雜度

好的組合允許：

$$
\text{Small Primitives}
+
\text{Rich Interaction}
\rightarrow
\text{Complex Behavior}.
$$

因此真正優秀的系統可能不是 primitive 很多，

而是：

$$
\boxed{
\text{Compositional Leverage}.
}
$$

---

# 51. Compositional Leverage

本文定義粗略指標：

$$
\boxed{
L_C
=
\frac{
B_{\mathrm{effective}}
}{
|\mathcal P|
+
C_{\mathrm{authoring}}
+
C_{\mathrm{runtime}}
}.
}
$$

其中：

- $B_{\mathrm{effective}}$：有效行為多樣性；
- $|\mathcal P|$：primitive 數；
- $C_{\mathrm{authoring}}$：內容建置成本；
- $C_{\mathrm{runtime}}$：運行成本。

高：

$$
L_C
$$

代表以少量基礎構件產生大量可靠行為。

---

# 52. AI 生成時代，Composition 更重要

生成式 AI 很容易產生：

- FSM；
- BT node；
- pathfinding code；
- utility function；
- action class。

也就是：

$$
C_{\mathrm{primitive generation}}
\downarrow.
$$

因此未來真正難點更可能轉向：

$$
\boxed{
\text{System Integration}.
}
$$

---

# 53. 生成一個 BT 已經不是難題

未來使用者可以說：

> 做一個巡邏—追擊—攻擊 AI。

AI 很容易生成。

但真正需求通常是：

> 讓 300 個 NPC 在持續世界中各自生活、工作、社交、戰鬥，並且離屏降低計算量，存檔後仍連續，玩家干預時可以中斷，還不能彼此搶同一張床。

這完全是另一個級別。

---

# 54. 從 Code Generation 到 Architecture Generation

因此 AI 遊戲開發的下一個能力階梯是：

$$
\boxed{
\text{Code Generation}
<
\text{Module Generation}
<
\text{Architecture Generation}
<
\text{System Integration}.
}
$$

---

# 55. Composition Dataset

如果 AI 要學會 composition，

資料就不應只有：

```text
source_code
```

而應加入：

```text
architecture graph
runtime trace
state schema
update frequency
interrupt rules
failure paths
authoring workflow
debug trace
version diff
```

這才真正教 AI：

> 怎麼把零件變成系統。

---

# 56. Composition Example Pair

可以建立：

### Input

```text
Need System
Utility Selector
Task Scheduler
Navigation
Animation
```

### Target

```text
Needs update every 1s
→ candidate jobs generated
→ utility scores
→ reservation
→ scheduler commits
→ navigation executes
→ animation locks action
→ failure releases reservation
```

這種資料比：

> Utility AI 是什麼？

更接近工程學習。

---

# 57. Negative Composition Data

失敗架構也要保存。

例如：

```text
Perception directly writes action
Planner also writes action
Animation cannot reject
Scheduler unaware of planner
```

結果：

$$
\boxed{
\text{Control Conflict}.
}
$$

這種反例是很高價值的訓練資料。

---

# 58. Composition Invariant

跨遊戲後，可以尋找：

$$
I_C
$$

即某類 AI 的組合不變量。

例如 persistent autonomous agent 可能反覆需要：

$$
\boxed{
\text{Perception}
+
\text{State}
+
\text{Goal}
+
\text{Selection}
+
\text{Execution}
+
\text{Feedback}.
}
$$

具體 primitive 可以替換。

---

# 59. Replaceable Freedom

若：

$$
FSM
$$

可以換成：

$$
BT
$$

而整體 behavior contract 不變，

則這一部分屬於：

$$
\boxed{
F_C=\text{Composition Freedom}.
}
$$

這對未來 AI 自動架構重寫非常重要。

---

# 60. Interface Contract

如果各模組有契約：

$$
M_i:
I_i
\rightarrow
O_i,
$$

則 AI 可以替換：

$$
M_i
\rightarrow
M_i'
$$

只要：

$$
O_i'\equiv_C O_i.
$$

這使 composition knowledge 可進一步變成 modular generation。

---

# 61. 深層解構真正要找的是「控制契約」

例如 perception contract：

```text
Input: sensory world
Output: percept events
```

planner contract：

```text
Input: world state + goal
Output: candidate plan
```

executor contract：

```text
Input: action
Output: state delta / failure
```

這比遊戲自己的 class 名稱更有泛化性。

---

# 62. Production AI 的五個隱藏表面

本文將最容易被教材漏掉的部分概括為：

$$
\boxed{
\mathcal H
=
\{
\text{Timing},
\text{Control},
\text{Failure},
\text{Resources},
\text{Tooling}
\}.
}
$$

即：

1. 時序；
2. 控制權；
3. 失敗；
4. 資源；
5. 工具。

---

# 63. Timing

問：

> 何時算？

---

# 64. Control

問：

> 誰說了算？

---

# 65. Failure

問：

> 壞掉怎麼辦？

---

# 66. Resources

問：

> 算得起嗎？

---

# 67. Tooling

問：

> 人類能做、能看、能修嗎？

這五個問題往往比：

> 用哪種 AI 演算法？

更接近產品成敗。

---

# 68. 命題一：Primitive–Production 非同一命題

$$
\boxed{
\text{Primitive Knowledge}
\not\equiv
\text{Production Intelligence}.
}
$$

知道演算法不等於知道如何將其放入完整遊戲系統。

---

# 69. 命題二：Composition Gap 命題

存在：

$$
\boxed{
\Gamma_C
=
K_{\mathrm{production}}
-
K_{\mathrm{primitive}}.
}
$$

其內容主要由跨模組關係、時序、控制、失敗、資源與工具構成。

---

# 70. 命題三：同 Primitive 多行為命題

若：

$$
\mathcal P_A=\mathcal P_B,
$$

仍可因：

$$
\mathcal C_A\neq\mathcal C_B
$$

而有：

$$
B_A\neq B_B.
$$

因此 primitive set 不足以預測最終智能。

---

# 71. 命題四：Tooling 屬於 Production Intelligence 命題

若 AI 系統不可：

- author；
- observe；
- debug；
- profile；
- replay；

則其商業可維護性顯著受限。

因此 tooling 不只是開發周邊，而是 production AI architecture 的一部分。

---

# 72. 命題五：Failure Space 命題

商品級 AI 的能力不應只由：

$$
\text{SuccessPath}
$$

評估，

還應評估：

$$
\boxed{
\operatorname{Recovery}(\text{Failure}).
}
$$

正常行為與失敗恢復共同決定 robustness。

---

# 73. 命題六：Resource-Bounded Intelligence 命題

遊戲 AI 的智能必須滿足：

$$
\boxed{
\text{Intelligence}
\mid
\text{Budget}.
}
$$

即任何 decision architecture 都存在於 CPU、memory、latency、network 與 content production 約束下。

---

# 74. 命題七：Composition Archaeology 命題

若要從遊戲歷史中抽取可泛化智能，不應只建立：

```text
Game → Algorithm
```

而應建立：

```text
Game
→ Functional Modules
→ Composition Graph
→ Timing
→ Control
→ Failure
→ Resource Policy
→ Tooling
→ Behavioral Outcome
```

---

# 75. 與下一篇的連接

到第 06 篇為止，我們已經得到：

$$
\boxed{
\text{Game}
\rightarrow
\text{Population}
\rightarrow
\text{Research Economics}
\rightarrow
\text{Composition}.
}
$$

但下一個更深的問題是：

> 如果把完整 source code、JSON、影片、architecture graph 都直接餵給 AI，這是否就叫「學會」？

答案仍然是否定的。

因為：

$$
\boxed{
\text{Exposure}
\neq
\text{Deconstruction}
\neq
\text{Understanding}.
}
$$

下一篇將正式建立解構深度階梯：

# **07｜餵資料不等於學習：從 Raw Exposure 到深層解構學習**

---

# 76. 結論

遊戲 AI 的公開知識其實比表面上多。

我們知道：

- FSM；
- Behavior Tree；
- GOAP；
- Utility；
- A*；
- Blackboard；
- Perception；
- Query；
- Scheduler。

真正稀缺的並不必然是另一個「神秘新演算法」。

更常見的是：

$$
\boxed{
\text{How known mechanisms are composed into a reliable product}.
}
$$

也就是：

$$
\boxed{
\text{Composition}
+
\text{Timing}
+
\text{Control}
+
\text{Failure}
+
\text{Resources}
+
\text{Tooling}.
}
$$

所以未來 AI 如果只學：

> Behavior Tree 的定義，

它得到的是零件知識。

如果它能學：

> 在什麼狀態、什麼時間尺度、由誰控制、如何中斷、如何失敗、如何降階、如何 debug、如何讓 designer 持續新增內容，

它才逐步接近：

$$
\boxed{
\text{Production Intelligence}.
}
$$

這也重新回答了最初的問題：

> 為什麼傳統遊戲 AI 書籍與真正商業遊戲體驗之間，常讓人感覺存在巨大落差？

因為書籍最容易教的是：

$$
\boxed{
\text{Primitives}.
}
$$

而真正商品長年累積的是：

$$
\boxed{
\text{Compositions}.
}
$$

---

# 參考資料

1. Epic Games. **Artificial Intelligence — Unreal Engine Documentation.** 說明 Behavior Trees、Environment Query System、AI Perception 等多個 AI 系統如何共同構成角色 AI 工作流。

2. Epic Games. **Behavior Trees in Unreal Engine.** 說明 Behavior Tree 與 Blackboard 的協作架構。

3. Epic Games. **AI Perception in Unreal Engine.** 說明感知事件如何更新 Blackboard / Behavior Tree 決策所使用的狀態。

4. Epic Games. **Environment Query System in Unreal Engine.** 說明 EQS 如何產生與評分環境候選，並與 Behavior Tree / Blackboard 連接。

5. Epic Games. **AI Debugging in Unreal Engine.** 說明 Behavior Tree、Blackboard、Perception 與 EQS 的運行觀測與除錯能力。

6. Orkin, J. (2005). **Agent Architecture Considerations for Real-Time Planning in Games.** Proceedings of the AAAI Conference on Artificial Intelligence and Interactive Digital Entertainment, 1(1), 105–110. DOI: 10.1609/aiide.v1i1.18724.

7. Orkin, J. (2006). **Three States and a Plan: The A.I. of F.E.A.R.** Game Developers Conference 2006.

8. Bungie / Damian Isla. (2005). **Managing Complexity in the Halo 2 AI System.** Game Developers Conference 2005.

9. Bungie / Max Dyckhoff. (2007). **Evolving Halo's Behavior Tree AI.** Game Developers Conference 2007.

10. Bungie / Max Dyckhoff. (2007). **Decision Making and Knowledge Representation in Halo 3.** NIPS Workshop / Bungie Publications.

11. Bungie / Damian Isla. (2008). **Halo AI Retrospective: 8 Years of Work on 30 Seconds of Fun.** Develop 2008.

12. Conway, C., Higley, P., & Jacopin, E. (2015). **Goal-Oriented Action Planning: Ten Years Old and No Fear!** GDC 2015 AI Summit.

---

## 系列導航

- 01｜AI 時代的資料資產：從「賣資料」到授權可計算知識
- 02｜高品質資料之後：從 Quality Paradigm 到 Novelty Paradigm
- 03｜遊戲不是內容資料：遊戲作為可執行因果世界
- 04｜商業遊戲智能考古：從 AI 名作到普通遊戲群
- 05｜遊戲解構經濟學：成本、難度、資訊增益與研究深度
- 06｜商業遊戲 AI 的隱藏層：真正稀缺的是組合，而非基礎演算法
- 07｜餵資料不等於學習：從 Raw Exposure 到深層解構學習
- 08｜理解的工程驗收：如果真的懂，就重建給我看
- 09｜合成資料之後：從模仿既有設計到探索新穎可執行設計空間
- 10｜慣老闆測試：意圖重建、設計生成與可執行世界考古