歡迎參與討論，轉載請註明出處。
前言
·DFQ是PVE（Player VS Environment）遊戲，那麼自然要有AI了。DFQ的AI實現並不算複雜，並沒有用到時下流行的行爲樹（Behavior Tree）。原因在於不需要做到太精細的操作，且AI部分的業務不需要執行策劃參與（不需要編輯器化）。本文將一一敘述其中要點，相信對於同類型的遊戲也有一定的參考價值。
宗旨
·AI設計的宗旨只有一個：根據遊戲的各種情況，決定進行怎樣的操作。這樣的思路其實挺仿生的，我們玩遊戲的時候本質上也是如此。要注意的是，玩家進行操作的方式是通過外設（鍵盤鼠標手柄觸控等）輸入操作信息（按鍵座標等）。從這點來說，AI也可以這麼做，以進行虛擬的輸入操作。這麼做的好處是很明顯的，如此AI與玩家在功能上達到了一致，AI也不需要與某個具體的功能耦合，只需要關注相應的操作指令，無需關注具體的功能實現。
·而這一切只需要做一套操作模塊即可，並且做聯機時來自其他玩家的輸入亦可如此處理，通過這種方式達到了玩家、AI、聯機三者的有機統一。可謂「軟件開發中遇到的所有問題，都可以通過增加一層抽象而得以解決」的一次實踐。
·當然這也會引入新的問題：*某些功能只想AI擁有，那該怎麼辦？*DFQ中的非轉向移動便屬於這類，解決方法很簡單：設計一個玩家無法觸發的操作指令即可。
對象
·AI的實體存在就是個類對象（下文稱AI對象）而已，它會被外部調用的基礎函數只有兩個：Update和Tick。Update用於處理持續性的業務，而Tick則是一次性的業務，當然兩者可能會有所結合（Tick接收參數，以驅動Update的運作）。
·AI對象主要會存在的場合有：常駐（移動和攻擊）、技能（判斷是否應發動）、狀態（某些狀態下需要後續的操作），通過配置化的方式，即可靈活的組合需要的AI了：
return {
script = "base",
state = "attack",
ai = {
script = "battleJudge",
collider = "duelist/goblin/skin/3-attack"
},
attackValues = {
{
damageRate = 1,
isPhysical = true
}
}
}
·如上配置所示，這是個技能的配置。在AI部分選擇了battleJudge類，並提供了用於判斷範圍的collider參數。如此便定下了該技能的AI方針：使用collider判斷是否存在敵人，存在則按下技能對應的按鍵，以發動技能。
實現
·說完基本構成後，再來說說一些具體AI業務的實現吧。
- 移動：移動AI的核心構成有三
- 獲取目標：遍歷符合條件的對象，涉及到陣營等因素。
- 尋路：以目標爲終點展開的尋路，由於DFQ使用的是網格地圖，所以使用A星之類的尋路算法即可。
- 輸入操作：獲取到移動路徑後，通過發出輸入指令以驅動角色以之移動。要注意的是，這種方式不可能做到完全貼合路徑，所以出現了超過了路徑點的情況也不會作處理。
- 攻擊：攻擊AI要做的事情很單純，遍歷技能以Tick它們的AI對象進行發動而已。要注意的是，技能的使用順序要建立優先級進行排序。
- 判定：這個判定，便是上文的battleJudge了，通過collider以判斷目標是否存在。這裏的collider便是先前打擊感所言的立體矩形，如下圖所示：
![collider]()
·以上便是DFQ裏值得一提的AI業務。順帶一提的是，AI是典型的不需要立即生效的業務，所以可以考慮每幀只執行一個單位的AI業務，以此減緩性能壓力，並且避免敵人一窩蜂展開攻擊的現象。
後記
·在本文開篇時，輸入AI二字的我其實有點恍惚。短短數年，AI幾乎成了深度學習/機器學習的代名詞了。在遊戲領域一個理所當然的縮寫反倒讓我躊躇了一瞬，真是唏噓啊。也許以後的遊戲AI真的都成了基於強化學習的實現也說不定呢（笑。