前一阵子看到一个 Unity 教学 youtuber 在用状态机做角色控制的时候，竟然直接使用 Animator Controller （以下称为动画状态机）作为角色逻辑状态机，这是我从没想过也不敢尝试的方法。
我也喜欢用状态机来做角色控制，但一般是自己写一个逻辑状态机，然后再用这个状态机去确定动画播放。动画状态机对我来说只是一个播动画的组件，即使哪天 Unity 出了新的动画系统也可以随时把它换掉。
其实以前在做项目的时候，我曾对于动画状态机和自己写的逻辑状态机如何协同工作感到困惑。如果动画状态机也使用一些 conditions 来进行状态切换，那么动画状态机和逻辑状态机很可能会出现不一致的情况。这在做网络游戏的时候尤其明显，即便服务端和客户端同步了逻辑状态机，动画状态机的状态由于一些 timing 的差异也会不一致，除非再单独同步动画状态机，也就是逻辑状态和动画状态各自单独同步，但我觉得这个方案并不合适（也考虑过只有服务端使用动画状态机，客户端用类似 legacy 动画系统的方法来播放动画，也不好）。
后来得出的方案是一切以逻辑状态机为准，逻辑状态机决定动画播放，即使没有动画系统，逻辑状态机也能独立完成整个游戏逻辑。这样如果想要动画系统表现好，逻辑状态机应该知晓一些动画的数据信息，这些信息是在编辑器阶段（而非运行时阶段）就准备好的，比如逻辑状态机和动画系统都应该知晓攻击动画的持续时间是多久，而不互相依赖。为了网络同步，动画系统应该能从任意动画切换到任意动画，这样动画系统实际退化成了一个简单的动画播放器。
我想应该很多网络游戏都是这样做的。
但如果是一个单机动作游戏呢？如果逻辑高度依赖动画系统，尤其是一些近几年兴起的 physics based 动画系统呢？这时动画系统还是需要参与逻辑运算。而开头说的那位 youtuber 更激进了一步，直接将动画状态机作为逻辑状态机，以致于理论上来说，某些动画状态机节点甚至可能不播放动画。以前 StateMachineBehaviour 刚出的时候我以为只是用来做一些简单的动画计算，没想到现在可以用来运行核心逻辑。
我本来也不是很确定像他这样用会不会有什么问题，但后来看到 CinemachineStateDrivenCamera 组件里，Unity 将 Animator Controller 作为不播放动画的纯状态机来使用，我想 Unity 是倾向于这样使用的。