尝试自主打造一个有限状态机（二）

前言

上一篇文章我们从理论角度去探索了状态机的定义、组成、作用以及设计，对状态机有了一个基本的认识，这么做有利于我们更好地去分析基于实际应用的状态机，以及在自主设计状态机时也能更加地有条不紊。本篇文章将从状态机的实际应用出发，分析基于角色控制的状态机是如何进行设计的。

声明

本系列文章要求读者具备一定的C#编程基础，同时对接口和抽象类、继承关系、设计模式以及面向对象等知识有所了解，在文章中我会对这些知识进行简要的阐述，对于描述有误的地方敬请指正。

基于角色控制的状态机

1.定义

基于角色控制的状态机是用于管理一个角色的状态的，在动作类游戏中角色的状态往往比较多，并且状态之间的过渡关系也比较繁杂，那么我们就可以为此打造一个状态机来更好地开发和维护这个部分。

从Unity3D的Animator去分析，首先一个角色通常是通过一个.controller文件来管理角色的状态的，这个. controller文件就像一个系统，从Animator的界面可以看到这个系统中包括了定义的状态、状态之间的连接以及状态过渡的条件参数等，而每个状态和状态之间的连接都有一些属性可以进行设置，由于状态机的应用不仅限于像Animator那样用于动画，所以这些属性应该根据状态机的实际应用场景去定义，如果用于动画，那么状态的属性可以是动画源文件和动画播放速度等。

2.组成

通常一个角色只需要使用一个状态机去控制即可，这个状态机属于角色控制的一部分，它至少应该包括角色状态类、角色状态转换路径类和角色状态机类三个部分，除此之外我们还可以把角色状态的执行逻辑与角色状态分离将其单独作为一个类，但是它仍然属于状态机。同时角色控制是与输入相关联的，所以角色状态的转换将由当前状态与输入共同决定，输入不属于角色控制，所以也就不作为状态机的组成部分，除此之外还有一些不属于状态机但是必要的部分，例如角色控制的参数、角色的消息机制和角色实体类等。那么综上所述，我们明确了基于角色控制的状态机应该包括角色状态类、角色状态转换路径类、角色状态机类和角色状态执行逻辑类四个部分。

3.需求

接下来较为复杂的就是设计这四个类中具体的方法，这首先需要我们明确角色控制的需求，基于需求去设计才能尽可能避免偏离实际。

组成部分	必要属性	可选属性	必要方法	可选方法
角色状态	状态名称、状态优先级、角色控制参数、动画组件或系统、输入检测集合	未知	初始化方法、动画播放方法、重置方法	未知
角色状态转换路径	源状态、目标状态、状态机、角色控制参数	未知	初始化方法、重置方法	未知
角色状态机	未知	未知	初始化方法、重置方法	未知
角色状态执行逻辑	角色控制参数	未知	刷新方法、初始化方法、重置方法	未知

角色状态最基本的功能需求是记录角色各个状态的信息，例如状态名称和状态优先级等，与角色状态对应的动画播放是采用Unity3D的Animator或Animation组件还是自定义的动画系统，这也可以作为角色状态的一部分，在角色状态中可能需要调用一些角色控制的参数，那么角色状态中还需要维护一个相关的变量，同时并非所有输入都需要在当前角色状态进行检测，例如角色跳跃的时候不一定需要检测攻击的输入，所以可以在角色状态中规定需要检测或不可检测的输入。除此之外角色状态还可以配备重置方法、初始化方法、动画播放的方法等。

角色状态转换路径需要记录源状态到目标状态的转换信息和状态转换的检测逻辑，如果需要调用状态机或角色控制参数就加上对应的变量即可，还可以配置初始化方法、重置方法等。

角色状态机需要管理各个角色状态和角色状态转换路径，向外提供调用接口，同时也可以配置初始化方法、重置方法等。角色状态机应该继承自基本的状态机，所以角色状态机中仅需要添加或重写一些特有的方法即可，具体的方法根据角色状态机的需求进行添加。

角色状态执行逻辑用于记录某个角色状态的执行逻辑，例如与某些组件一起完成当前状态的角色控制的实现或者当前状态下某些角色控制参数的改变，可以配备刷新的方法、初始化的方法以及重置方法等。

对于首次开发，我们无法非常完整地确定需求，所以我们可以边开发边改进，后续通过不断地优化来完善这个基于角色控制的状态机。

4.设计

基于上述需求，基于角色控制的状态机分为角色状态、角色状态机、角色状态转换路径以及角色状态执行逻辑，四个部分分别对应PlayerState类、PlayerStateMachine类、PlayerStateTransition类以及PlayerStateRule类，且四个类分别继承自CSFState类、CSFStateMachine类、CSFStateTransition类以及CSFStateRule类。而对于PlayerState、PlayerStateMachine、PlayerStateTransition以及PlayerStateRule四个类具体的设计则需要根据角色控制的具体需求去完成，在接下来的实际示例UML图中可以看到对于这四个部分的具体类设计。

我们可以先结合每个部分的功能来明确一些对应的属性和方法，然后逐渐修改完善，不断贴合需求进行优化。

实际示例（UML）

如图1所示，AnimationEvents是属于动画事件类，用于管理角色各个状态的动画中的事件。PlayerState是角色状态类，继承自CSFState这个通用状态类。PlayerStateMachine是角色状态机类，继承自CSFStateMachine这个通用状态机类。PlayerStateTransition是角色状态转换路径类，继承自CSFStateTransition这个通用状态转换路径类。PlayerStateRule是角色状态执行逻辑类，继承自CSFStateRule这个通用状态执行逻辑类。PlayerTransitionMediator是角色状态转换路径中介者类，继承自CSFTransitionMediator这个通用状态转换路径中介者类，这个中介者类负责某个状态对应的所有状态转换路径的过渡检测。

实际运转则是首先调用PlayerStateMachine中的Init方法对所有的PlayerState、PlayerStateTransition以及PlayerStateRule进行初始化，为每个PlayerState设置输入配置以及添加对应的PlayerStateRule，为每个PlayerState对应的PlayerTransitionMediator添加对应的PlayerStateTransition，最后将所有的PlayerState和PlayerStateTransition添加到PlayerStateMachine中，然后设置PlayerStateMachine的初始状态。

每个PlayerState都具备一个OnEnter、OnUpdate和OnExit方法，在角色控制类中分别调用PlayerStateMachine的接口方法StateUpdate和StateRuleUpdate，StateUpdate方法负责PlayerStateMachine中当前状态对应的OnUpdate方法的执行，当前状态的OnUpdate方法中执行PlayerTransitionMediator中的StateCheck方法用于对当前状态对应的PlayerStateTransition的过渡进行检测，由于这个示例我们借助Animator播放动画，所以对应状态的动画播放则放在了OnEnter方法中执行，PlayerTransitionMediator中的StateCheck方法则是对每个PlayerStateTransition的按照优先级进行排序，优先级高的先进行检测，这个过渡检测的逻辑则对应着PlayerStateTransition中的CanTransitionTo方法，若通过了过渡检测，则PlayerStateMachine的当前状态将过渡到指定的状态，然后继续重复上述过程，在每一次StateUpdate方法执行后都会执行一次StateRuleUpdate方法，StateRuleUpdate负责当前状态的PlayerStateRule中的Update方法的调用，进而完成对应的角色状态执行逻辑的工作。每个状态都配置着一个PlayerState、PlayerStateTransition、PlayerStateRule和PlayerTransitionMediator的派生类，在这些派生类中只需要完成对应功能具体逻辑的编写即可，不需要关注各自之间的合作和调用问题。