《游戏编程模式》 读书笔记 状态模式

        状态模式，或者状态机，说白了其实是一个标记位，或者说一个枚举变量，这个标记位会影响你处理一些逻辑的方式。比如一个角色本来可以按shift奔跑，但是当他瞄准时不能奔跑，那么“是否在瞄准”就是这个标记，本来可以奔跑，现在在瞄准就不能奔跑了，这就是影响的处理逻辑的方式。一般来说只是这种程度的需求的话，一个bool变量，一个if判断就搞定了，但是如果这样的变量越来越多，那你就不得不在代码里塞很多的if，这种时候，就要状态模式出场了。状态模式可以用于整理多个互斥bool变量对逻辑处理的影响，所谓互斥bool变量，是指多个bool变量中最多有一个为true，其实这种情况下只需要一个枚举来指示当前激活的bool变量是哪个，并不需要这么多bool变量。用得很多的是人物的当前体态：正常站立、跳跃、下蹲、匍匐等，人物只能同时处于其中一个状态。亦或是AI控制的敌人行为逻辑：巡逻、警戒、休眠、追击等，明显一个敌人同时只能由一个行为模式控制。简单的做法就是我用一个枚举来保存当前状态，然后在各种被影响的逻辑上加switch语句来根据当前状态走不同的逻辑。这种做法在影响逻辑不多的时候还是好用的，比如刚才提到的敌人行为逻辑，我只根据敌人当前状态走对应的行为树，一个switch就搞定了。但如果switch的地方很多，case下的语句很长很杂，看起来就很费劲，这个时候就应该对每个状态进行封装，让每个状态自己写自己的逻辑，外面只负责调用当前状态实例的接口就好了。比如本来有站立状态、跳跃状态、下蹲状态，每个状态都有自己处理玩家输入的一个逻辑，使用switch函数的话，就是外面这么写：switch（当前状态）case 每个状态：这个状态自己处理输入的逻辑。包装成类的话，就可以这么写 ：当前状态.HandleInput（），当前状态是一个状态类的实例，不同的状态都继承自一个状态父类，实现了自己的HandleInput方法。这样做的话维护起来就很爽了，我看某个状态之间去它类里看就完了，不用到处搜索那个枚举的引用了。一般来说这种封装好的状态也会自己处理状态之间的转移，这样连在一起的状态的集合就是状态机

        使用状态模式，重点要注意自己要处理的标记是不是互斥的，以及影响的逻辑是不是差别很大，一定不要滥用设计模式。比如我只在站立和移动的时候能瞄准，瞄准了就不能奔跑和跳跃，那有没有必要添加站立瞄准、移动瞄准这两个状态？这种复合的情况要小心，有时简单的bool判断可能是最有效的。比如这里你加了站立瞄准、移动瞄准状态，后面又来了个：玩家有时能漂浮在空中，漂浮在空中时能瞄准，也能移动，但是不能跳跃不能下蹲，那你岂不是要一口气加漂浮站立、漂浮移动、漂浮站立瞄准、漂浮移动瞄准四个状态？我个人的建议是没有很多区别的情况的话，直接用if判断即可。 

        把普通的状态机搞懂了，书里讲的进阶的状态模式的应用就很好懂了。并发状态机，就是有多个枚举，实际上是有两个状态机各跑各的，但如果这两个状态机耦合太多，我认为不如合成一个状态机。层次状态机，实际上就是说你可以在状态子类上再套继承，这样合并一些状态子类的重复逻辑。下推自动机，实际上就是存了你之前的状态以供你现在正在跑的逻辑来引用。