动作类游戏状态机设计

动作游戏中，角色在任意时刻可能处于站立、跳跃、攻击、受击等多种状态。状态之间存在复杂的转换和冲突——这是动作游戏开发中最经典的架构问题之一。

在开发一款轻度动作 RPG 时，我经历了三种方案的演进，最终落地于分层状态机。本文记录这个思考过程。

==================== 状态基本结构 ====================

状态的基本结构

每个状态拥有独立的生命周期：

从持续性角度，状态分为两类：

类型	行为	典型例子
持久状态	条件满足就持续存在，每帧检测	Stand（在地面→生效）、Run（有速度→生效）
触发状态	事件触发，执行完毕自动退出	Attack（动画播完→退出）、Skill（释放完→退出）

角色通过一张状态表展示当前所有生效的状态。核心问题随之而来——当多个状态同时存在时，冲突怎么办？

==================== 方案一 ====================

方案一：状态栈

最直观的思路：每个按钮对应一个状态栈，栈内管理连招序列，所有按钮的状态栈并行执行。

对于状态混合（如角色在空中），有两种处理方式：

==================== 方案二 ====================

方案二：第三方冲突管理器

既然分散管理太混乱，那就集中——引入一个管理器统一仲裁。

==================== 方案三 ====================

方案三：分层状态机（最终方案）

核心思路：按职责分层，层内用状态栈，层间用优先级仲裁。

==================== 对比 ====================

三种方案对比

	状态栈	冲突管理器	分层状态机
冲突管理	每个状态自行维护	集中在冲突表	按层隔离 + 层间优先级
耦合度	高	中	低
可维护性	O(n²)	表膨胀	O(n)
连招支持	栈式压入，直观	需额外设计	技能层内栈式管理
适用场景	状态极少的简单游戏	中等复杂度	动作游戏推荐方案

具体实现在 Skill.cs 和 SkillState 中，将普通状态与技能状态统一纳入分层状态机体系管理。相关项目详见 XYGame 项目页。