最近的业务上，又回到Animation Tree这块了。

众所周知的是Animation Tree这些概念已经提出很久了，但是使用有着AT支持的CE引擎的项目，却依然义无反顾地没有使用AT，而且，连某些引擎支持人员居然也没搞明白这是个什么东西，前因后果如何，也不去推行这个前期一旦定好后期一劳永逸的事情。

吭哧百度做了一年多，在游戏的上层几乎重新把AT做的事情做了一遍，用一种最糟糕的方式——拿状态机来做状态，谁说角色的状态就一定要状态机做的？那都是上世纪90年代和本世纪最早4、5年的游戏教材才会这么写好伐？状态机做状态我所见过的没有正面的例子，全都是血淋淋的教训。

果不其然，看到了一张似曾相识的长千列，宽千行的大表，技能1，一行一列，技能1受击，一行一列。Oh yeah，嗅到了作死的节奏，维护这样的东西？设计师自信满满的表示几万行的数据都处理了，这个问题不大……

行，问题是不大，问题是人家一个月出十个，你十个月出一个，我知道你能出来，等你出来的时候，永远的毁灭公爵都出3代了……

于是就动了个手术，把状态机和与之相关的Animation彻底废弃重来。

要解释清楚AT，先要解释一下状态机这个坑爹玩意儿。

之前的文章里这里就留了个尾巴，为什么状态不适合用状态机来做？先要从状态这个概念说起。

从逻辑意义上说，状态的组成关系一般不会特别复杂，但组成成分上却并不单纯，很可能不能用一个体系去说明，举个例子：角色技能与否，跟移动有关系吗？现今的大部分游戏，这个答案都是否定的。是否处于技能过程中，并不影响是否同时处于移动流程中，亦不影响死否处于下落过程中，亦不影响角色是否受击，亦不影响角色中毒与否、减速与否。你会说，中毒减速那是Debuff，但你能说清楚中毒减速是Debuff，为何技能不能算作同样的东西吗？当一个技能指令过来后，我需要判断的是什么呢？是否正处于受击，是否正被沉默，是否正被眩晕……也就是说，对于逻辑而言，你需要的只是一堆堆的标记，状态机？受击同时被沉默状态，受击同时正在技能状态，技能同时正在减速状态，技能带位移状态，位移带技能状态。就算把Buff那几个能去掉，最后这俩带Stance的，也是完蛋。

更有甚者，竟然还敢把AI状态也给整进来，再来几个寻路移动状态，攻击目标移动状态，回位移动状态……真实的故事。问题是寻个路、寻个的、接近个的、逃个跑什么的，这到底是跟移动互斥啊还是跟技能互斥啊？以人类的思路理解不能啊。

AI自己形成个状态机不就好了，本身AI就是Controller层面的概念，角色是Actor层面的概念，Controller control Actor，分成两套状态机再正常不过了，合到一起除了给自己添麻烦外有任何哪怕一点的好处吗？

单纯从逻辑上，真正可能到最后有跟状态机有很大关联的，一般只有Stance这种偏表现的逻辑状态：是否正在爬梯子跟是否在走路铁定是没有关系的，是否正在举起箱子跟是否正在走路也铁定没有关系。

从这一点引开来，你会发现真正适用于状态机的，可能只有动画部分了。没错，这个直觉是对的。

这是有道理的，状态机的特点是什么？无论有多少状态，同时可且尽可能处于一个状态。也就是说，从属于状态机的各状态之间，有很明确的互斥关系。技能和移动互斥吗？看游戏设计，有些可以很明确，有些不会很明确。格斗游戏表示技能和移动互斥，旋风斩表示我可以一边技能一边移动。逻辑上可以互斥，就做状态机，不可以，就不要做。有些游戏要做技能过程中仍然有一定的受击导致的IK效果，那这种情况下，逻辑就不互斥，技能和受击就必须作为独立的两个Trigger。

但是动画是基本很明显的，互斥性很强。上下半身融合，头部融合，受击融合，无论怎么融合，每个具体单元都是赤裸裸地互斥性。下半身在跑步的同时就不可能同时做出游泳的动作，非常好理解。

但是，你的逻辑状态很简单啊。即便逻辑上，技能、移动、受击是三个状态，那又怎么样呢？移动中还有中毒移动、减速移动、晕乎乎的移动，受击中还有中毒受击，Debuff特殊受击，这些难道要算逻辑状态吗？正常人都不会这样做的，中毒、减速、眩晕一定是Debuff，本来就是，这三个从逻辑意义上，根本就无法跟移动、技能互斥。怎么可能做成状态机呢？

但是，动画上，确实有着带毒移动，带减速移动这样的需求啊，逻辑上，不能做成状态机，但是动作上，却又需要状态机这样的机制，这样的矛盾怎么破？

灵活而复杂的逻辑结构和相对简单的动画结构的矛盾，这个矛盾客观存在，这就是AT诞生的理由。