Utility Theory真的是很複雜的，果然不是花一些時間可以了解的主題。但這次想要嘗試的Utility AI可否用Behavior Tree來實現的試驗。在那之間，還是先閱讀一些簡易闡述Utility AI的文章。

• At-a-glance functions for modelling utility-based game AI
• Utility AI (Discussion)
• 游戏人工智能 读书笔记 （四） AI算法简介——Ad-Hoc 行为编程

看完後大致上的想法是將每個可能的動作用某個函式去做計算，進而得到一個值，而就這些值排列大小後，從中選最大（或最小），而後執行該動作。

從這樣的想法上去看，前篇所舉的例子變得不太適合。移動到門、開門、關門是一系列的動作，做或不做取決於中斷點為何。而Utility AI比較像是同時有多個選擇動作時，要執行哪個（這比較像是開門的方法那所描述的）。

用Unity中的Behavior Designer進行實作，但換個情境來思考，NPC在多個可選擇的行為中做決擇。比如說動作遊戲（大亂鬥類型）的NPC，可選擇的動作為攻擊、離開和吃加血道具。

官方有針對UtilityAI加了一個Utility Selector節點，並提供了一個範例做展示，可惜該範例有錯誤，行為樹的圖打開後都是空的，沒有實值的參考，所以只能自己在儘可能不寫Code的情況下重建此範例。

Utility Selector意外的相當好用，所以底下的節點使用上很精簡。直接用Sample裡寫好的Evaluate節點，但此節點要放在實際行為（這裡的行為是以秀文字在Unity Console上為主）後面，符合了行為完成後的評估。而這裡的函式，是直接用Unity的動畫用函式，這的確是最方便的引用法。在正常的情況上面的文章裡提到的線性函式、漸升函式等都可以快速選用。

突然間想到，其實這裡也可以用DOTween所提供的Tween函式進行，一方面它也是現成的選擇，二方面它提供了更多可預期的數學函式。

且使用Evaluate和Random Probability很像，一個是放置在動作以亂數決定是否進行，而Evaluate則置於後，以某形式的函式拿取計算值，再決定是否結束。

不過最複雜的地方應該會落在真正的開發中，要規劃什麼樣的數值之間的互動、引用，並代入哪個函式中。這大概才是Utility AI使用上會令人困擾的地方。

了解Behavior Designer中Utility AI的感想

在Behavior Designer（BD）中引用Utility AI的方法沒有想到這麼的單純，複雜的部份在於值和函式間的計算，這卻又是短短的範例中很難規劃的。本想再設想複雜的使用情境展示BD的強悍，無奈腦袋這時又很僵硬，沒有辧法想到能突顯BD的情境，只好貼一些其它團隊實際使用的截圖，讓開發者自行領悟。

• Antisocial behavior
• 【オススメ!】Behavior Designer

雖然BD的設計可以複雜到極致，但和寫程式碼一樣，若是一個檔案裡行數多到一個地步而不做一些重構，行數多看起來並不會比較厲害，只會讓其它人覺得邏輯淩亂而導致程式碼無法拆開（當然也可能真的是複雜到就是切不開）。

今天花了不少時間在閱讀Utility AI相關的文章，但實際進入到Unity裡要用BD時，才發現好像弄不出具代表性的範例。但還是勉強的做了一個很簡易的範例，好讓日後有個可以參考的依據。今日測試用的專案放罝在Git Repo中的behavior-tree-utility目錄裡，沒有太多的參考價值，但日後有複雜的設計時，需要再好好的將使用過程記錄下。

BD的介紹和自己對於Utility AI的探索到此結束，迎接Unity推出的另一個視覺化工具-Visual Effect Graph的使用之前，會先行介紹其它開發遊戲時非常有用的擴充當做暖身。