【置顶】动作类游戏状态机设计
在做一款轻度动作RPG游戏的时候，使用混合状态机来实现角色的状态控制，每种状态都有自己独立的执行单元，我称之为状态栈，状态栈 用栈式管理 来处理连招，表象就是每个输入按钮 对应一个状态栈，所有按钮运行在状态栈管理器中并行执行，
暂不考虑按钮间的组合连招，类似于拳皇这类重度动作游戏。
每个状态都有对应的生命周期函数，每种状态负责管理和自己冲突的状态评定，
状态间的冲突处理：
一些状态是持久的 一切状态是短暂触发的，比如Stand状态，逻辑上来说 只要角色不在空中，那么都是处于Stand状态，那么对于Stand状态逻辑来说，就简单多了 只需要检测当前角色是否在地面即可。Stand逻辑每帧都会处理 角色通过一个状态表 来展现当前状态，一些简单状态的混合，如角色起跳在空中，既有Jump状态 也有Fall状态 的混合，也可以分解为Jump到最高点之前为jump jump的下个状态就是Fall状态，
这2种方案 一个是并行 一个是通过上面的 状态栈来处理，状态栈的一个缺点就是每个状态如果有 连招，那么就要知道自己下一个招式状态是什么 某些逻辑可能还要知道当前状态的上个状态是什么，那么状态之间的耦合性太大，也许这种耦合性是可接受的，比如你起跳状态后肯定是下落 或者 击飞，
这种简单一对一关系可以用状态配置表来处理，但是如果有复杂的逻辑，比如 玩家在起跳中在空中 如果收到了击飞 那么下个状态就是继续 起跳被击飞，如果收到了倒地的 效果 那么下个技能就是直接下落到地面，这种非一对一的关系的处理，可以通过一个下个状态并行机来处理，只要有一个下个状态返回true 那么就评定下个状态为他，
这种设计维护起来特别困难，至少所有技能或者状态，吧技能暂且称为状态的一种，都要维护自己和所有其他状态的关系，简单评定就是冲突与否，
还有一种做法就是通过一个第三者管理器来维护这个状态中之间的冲突，对于A状态来说 我只需要知道我的下个状态可以是 B C D 吧这个信息告知 管理器 管理器负责实际中到底是哪一个状态被确认为下一个状态，管理器负责冲状态冲突表中而状态或者技能只需要维护 和自己相容或者冲突的 状态ID即可，
这种设计只是吧状态间的 相容和冲突 委派给了管理器 虽然代码上看起来会很优雅，但是还是没解决状态要维护自己冲突状态或者相容状态的需求 而带来的 维护难度困境
在这里把普通状态和 机能状态组合成了分层状态机，把技能的规则也加入状态机里面
具体在Skill.cs 和SkillState