最近的業務上，又回到Animation Tree這塊了。
衆所周知的是Animation Tree這些概念已經提出很久了，但是使用有着AT支持的CE引擎的項目，卻依然義無反顧地沒有使用AT，而且，連某些引擎支持人員居然也沒搞明白這是個什麼東西，前因後果如何，也不去推行這個前期一旦定好後期一勞永逸的事情。
吭哧百度做了一年多，在遊戲的上層幾乎重新把AT做的事情做了一遍，用一種最糟糕的方式——拿狀態機來做狀態，誰說角色的狀態就一定要狀態機做的？那都是上世紀90年代和本世紀最早4、5年的遊戲教材纔會這麼寫好伐？狀態機做狀態我所見過的沒有正面的例子，全都是血淋淋的教訓。
果不其然，看到了一張似曾相識的長數十列，寬千行的大表，技能，條件組合1，一行，條件組合2，一行，條件組合3，一行……Oh yeah，嗅到了作死的節奏，維護這樣的東西？設計師自信滿滿的表示幾萬行的數據都處理了，這個問題不大……
行，問題是不大，問題是人家一個月出十個，你十個月出一個，我知道你能出來，等你出來的時候，永遠的毀滅公爵都出3代了……
於是就動了個手術，把狀態機和與之相關的Animation徹底廢棄重來。
要解釋清楚AT，先要解釋一下狀態機這個坑爹玩意兒。
之前的文章裏這裏就留了個尾巴，爲什麼狀態不適合用狀態機來做？先要從狀態這個概念說起。
從邏輯意義上說，狀態的組成關係一般不會特別複雜，但組成成分上卻並不單純，很可能不能用一個體系去說明，舉個例子：角色技能與否，跟移動有關係嗎？現今的大部分遊戲，這個答案都是否定的。是否處於技能過程中，並不影響是否同時處於移動流程中，亦不影響死否處於下落過程中，亦不影響角色是否受擊，亦不影響角色中毒與否、減速與否。你會說，中毒減速那是Debuff，但你能說清楚中毒減速是Debuff，爲何技能不能算作同樣的東西嗎？當一個技能指令過來後，我需要判斷的是什麼呢？是否正處於受擊，是否正被沉默，是否正被眩暈……也就是說，對於邏輯而言，你需要的只是一堆堆的標記，狀態機？受擊同時被沉默狀態，受擊同時正在技能狀態，技能同時正在減速狀態，技能帶位移狀態，位移帶技能狀態。就算把Buff那幾個能去掉，最後這倆帶Stance的，也是完蛋。
更有甚者，竟然還敢把AI狀態也給整進來，再來幾個尋路移動狀態，攻擊目標移動狀態，回位移動狀態……真實的故事。問題是尋個路、尋個的、接近個的、逃個跑什麼的，這到底是跟移動互斥啊還是跟技能互斥啊？以人類的思路理解不能啊。
AI自己形成個狀態機不就好了，本身AI就是Controller層面的概念，角色是Actor層面的概念，Controller control Actor，分成兩套狀態機再正常不過了，合到一起除了給自己添麻煩外有任何哪怕一點的好處嗎？
單純從邏輯上，真正可能到最後有跟狀態機有很大關聯的，一般只有Stance這種偏表現的邏輯狀態：是否正在爬梯子跟是否在走路鐵定是沒有關係的，是否正在舉起箱子跟是否正在走路也鐵定沒有關係。
從這一點引開來，你會發現真正適用於狀態機的，可能只有動畫部分了。沒錯，這個直覺是對的。
這是有道理的，狀態機的特點是什麼？無論有多少狀態，同時可且儘可能處於一個狀態。也就是說，從屬於狀態機的各狀態之間，有很明確的互斥關係。技能和移動互斥嗎？看遊戲設計，有些可以很明確，有些不會很明確。格鬥遊戲表示技能和移動互斥，旋風斬表示我可以一邊技能一邊移動。邏輯上可以互斥，就做狀態機，不可以，就不要做。有些遊戲要做技能過程中仍然有一定的受擊導致的IK效果，那這種情況下，邏輯就不互斥，技能和受擊就必須作爲獨立的兩個Trigger。
但是動畫是基本很明顯的，互斥性很強。上下半身融合，頭部融合，受擊融合，無論怎麼融合，每個具體單元都是赤裸裸地互斥性。下半身在跑步的同時就不可能同時做出游泳的動作，非常好理解。
但是，你的邏輯狀態很簡單啊。即便邏輯上，技能、移動、受擊是三個狀態，那又怎麼樣呢？移動中還有中毒移動、減速移動、暈乎乎的移動，受擊中還有中毒受擊，Debuff特殊受擊，這些難道要算邏輯狀態嗎？正常人都不會這樣做的，中毒、減速、眩暈一定是Debuff，本來就是，這三個從邏輯意義上，根本就無法跟移動、技能互斥。怎麼可能做成狀態機呢？
但是，動畫上，確實有着帶毒移動，帶減速移動這樣的需求啊，邏輯上，不能做成狀態機，但是動作上，卻又需要狀態機這樣的機制，這樣的矛盾怎麼破？
靈活而複雜的邏輯結構和相對簡單的動畫結構的矛盾，這個矛盾客觀存在，這就是AT誕生的理由。