Unity FSM有限状态机

上篇短文小菜展示了行为树的内容，既然说了行为树就不得不提及一下它的好兄弟状态机，关于两者在职责上相似在实现上又不同的两个亲兄弟，网上的作者早已争论的喋喋不休了。

    和行为树类似，有限状态机同样可以担任ai自主决策的工作。我们更多的见到它的身影是在连招系统（左劈右砍上挑）和场景中的状态管理上。

行为树更像是：

而状态机则是：

小菜也是菜菜的小菜，只有轻描淡写的拿这两张图做简短的比较了。

 

有限状态机

    有限状态机的有限代表的是由一组有限多个状态，它的组成便是这有限多个状态、输入以及状态间的切换过渡组成。

    有限状态机能很好的分离过多的if（xx）{}else if （xxx）{}以及switch（）case：的逻辑职责，提高代码的可维护性和扩展复用性。

    关于状态。对于游戏中，开始游戏、进入战斗、释放技能、等都可以称之为状态。当某些条件发生时，状态A就可以顺利的切换到状态B或者状态C.而这个切换的过程通常称之为过渡。

    没错这倒是和unity的动画系统的动画状态机很类似。

 

组成

1).状态机

2).状态

3).过渡

 

一个帮助更详细的解释便是下图：

 

一个简单的例子

先是一个简单的巡逻NPC的AI图解：

然后通过对状态和转换分析得到下表：

在游戏中不管任何时间、任何地点、任何的行为我们的NPC都将处于四种状态中的其中一种，如果还有第五种状态，恭喜你成功获得了创建bug一等奖。这些状态会根据输入的影响在多个状态之间做转换。

 

FSM有限状态机编码

状态机模式源于设计模式中的状态模式，风趣幽默的大话大神是这样定义描述状态模型的。

对于状态机的内容，网上也有很多的参考文章。虽然实现细节不尽相同。但原理都是类似的。

 

疲于多日的苦战，小菜已经累的不知道如何开口和下手了。直接编码吧。

先是帮助理解小菜做法的uml类图（为了节省空间，实现接口的属性和方法就在实现类中被小菜省略了）。

 

核心类的说明：

IState                                                 状态接口

 

ITransition                                          过渡接口

IStateMachine                                   状态机接口

 

BaseState : IState                               状态基类

BaseTransition:ITransition                  过渡基类

GameStateMachine : IStateMachine  状态机基类

 

IState 

 

ITransition

 

IStateMachine

 

BaseState : IState

 为了更好的帮助继承于状态的子类去理解实现，仅仅为上层提供的委托的回调。

 

BaseTransition:ITransition

 

GameStateMachine : IStateMachine

核心的调用便都在这个update里了。

 

这些核心的类仅仅是支撑了主要的架构职责，我们仍需根据需求划分并实现这些状态。

行为树与有限状态机对比

1).行为树每一次遍历执行遍历的过程总是要从根发起，然后按照深度执行贯穿到每个叶子节点。遍历的代价是巨大的。而状态机多数情况下仅仅是通过一个事件条件触发去影响某一个状态就可以了。

 

2).但对于需求的更改，由于行为树只有条件和行为是需要去编辑的，同时它又是树的形式，可以很轻松的打散行为进行节点重组。而对于状态机来说，一旦对那些已经有的有限多个状态做出修改，导致的改动可能是比较多的。维护起来并不是那么轻松。

 

3).调试和自由编辑上行为树会较状态机轻松许多。

 

当然具体问题还要具体分析，什么时候用行为树什么时候用状态机？有哪些利和弊？需要设计者在考量后做出自己的判断和选择。永远不可忽略人的思维是高级于机械式的决策行为树和状态机的存在。