Skip to content
写作:待补充更新:2026-05-16字数:—阅读:—维护:Azek431

创游世界动作状态机入门

一句话摘要

状态机是动作类项目的核心管理工具,用于明确"同一时刻只能处于少数状态中的某一个",解决动作冲突、优先级混乱、输入锁等问题。

适合谁阅读

  • 想做动作类游戏(横版格斗、RPG、闯关)的制作者
  • 遇到"一边翻滚一边攻击"等动作冲突问题的开发者
  • 想系统理解状态机的原理与实战应用的学习者

你将学到什么

  • 状态机的核心概念与设计思路
  • 常见动作状态的分类与优先级
  • 中断规则与输入锁的设计方法
  • 新手最常见的状态机错误

1. 什么是状态机

状态机可以先用最简单的话理解:

一个对象在同一时刻,只应该处于少数明确状态中的某一个。

比如玩家角色:

  • 待机
  • 移动
  • 攻击
  • 翻滚
  • 受击
  • 死亡

如果没有这种清晰分层,后期就很容易出现:

  • 一边翻滚一边又进入普通攻击
  • 死亡后还能移动
  • 受击时还能继续连按触发多个动作

2. 为什么动作类项目特别需要状态机

动作类玩法的问题,不是"会不会播放动画",而是:

  • 哪个动作优先级更高
  • 哪个动作能不能打断另一个动作
  • 哪个状态下允许输入
  • 哪个状态下必须锁输入

状态机就是用来回答这些问题的。


3. 常见状态有哪些

3.1 待机

没有明显动作输入时的默认状态。

3.2 移动

角色正在走、跑、冲刺等。

3.3 攻击

普通攻击、技能攻击、蓄力攻击等。

3.4 翻滚 / 闪避

通常带有位移和短时无敌或保护逻辑。

3.5 受击

被打中后的硬直、击退或受伤反馈状态。

3.6 死亡

角色不可继续执行正常行为的终止状态。


4. 状态机真正关键的是「切换规则」

不是把状态名字写出来就叫状态机。

真正关键的是:

  • 什么条件进入某状态
  • 什么条件退出某状态
  • 哪些状态之间能直接切
  • 哪些状态必须等待完成

例如:

  • 待机 → 移动:有移动输入
  • 移动 → 攻击:按下攻击键且未被锁定
  • 攻击 → 待机:攻击结束且无后续输入
  • 任意状态 → 死亡:生命值归零

5. 优先级很重要

不是所有状态地位都一样。

常见优先级思路:

  • 死亡最高
  • 受击通常高于普通移动
  • 翻滚可能高于普通攻击,或与攻击互斥
  • 普通移动低于很多特殊动作

如果没有优先级,后面很容易动作打架。


6. 中断规则要提前想清楚

状态机里最常见的问题就是"能不能打断"。

要明确:

  • 攻击中能不能翻滚取消
  • 受击时能不能释放技能
  • 翻滚过程中能不能再触发翻滚
  • 死亡后是不是彻底锁住全部动作

这些规则一旦不清楚,项目后面会非常乱。


7. 输入锁是什么

输入锁不是不能输入,而是:

在某些状态下,即使玩家有输入,也不允许立刻触发新行为。

常见场景:

  • 攻击前摇 / 后摇
  • 受击硬直
  • 死亡状态
  • 结算动画期间

如果没有输入锁,动作类项目通常会非常飘。


8. 一个最小动作状态设计示例

假设你做一个简单角色:

可用状态

  • 待机
  • 移动
  • 攻击
  • 翻滚
  • 受击
  • 死亡

最小规则

  • 有移动输入且不在特殊状态 → 进入移动
  • 无移动输入且不在特殊状态 → 回到待机
  • 按攻击键且当前允许攻击 → 进入攻击
  • 按翻滚键且当前允许翻滚 → 进入翻滚
  • 被命中且未死亡 → 进入受击
  • 血量归零 → 进入死亡

这已经比"全写 if 判断混在一起"稳很多。


9. 状态机和战斗系统的关系

战斗系统不是只有伤害计算。

动作类战斗至少还涉及:

  • 攻击什么时候生效
  • 受击什么时候触发
  • 无敌时间什么时候开始/结束
  • 攻击后什么时候能接下个动作

这些都高度依赖状态机。

所以可以把它理解成:

  • 战斗系统管「战斗规则」
  • 状态机管「动作流程秩序」

10. 新手最常见错误

10.1 所有动作都靠散乱布尔值控制

后期会出现:

  • isRun
  • isAttack
  • isHit
  • isDead
  • isRoll

一多起来很容易互相冲突。

10.2 没有统一状态入口

导致不同脚本各改各的状态名,最终谁都说不清当前到底在什么状态。

10.3 没有死亡最高优先级

这会导致死亡后还能放技能、移动、播错误动作。

10.4 没想清中断规则

很多"手感奇怪"本质都是中断逻辑没设计清楚。


11. 一句很好记的总结

状态机不是为了显得高级,而是为了防止动作互相打架。

只要项目里出现:

  • 攻击
  • 受击
  • 翻滚
  • 技能
  • 死亡

基本就值得认真做状态管理。


结论等级与待验证问题

已确认

  • [已确认] 动作类项目一旦同时存在攻击、翻滚、受击、死亡等行为,就必须明确状态切换与优先级,否则极易出现动作互相打架。
  • [已确认] 输入锁、中断规则与优先级并不是附属细节,而是动作状态设计的核心组成部分。

高可信推断

  • [高可信推断] 对大多数动作项目来说,建立统一状态入口会比散乱布尔值控制更稳,也更容易维护。
  • [高可信推断] 如果后续还会扩展技能、连招、硬直、无敌帧与取消机制,越早建立状态机边界,返工成本越低。

待验证

  • [待验证] 不同项目规模下,状态数量拆到多细、是否拆分为角色主状态与动作子状态,仍需要更多案例支持。

证据与回查入口

  • 主要交叉来源:docs/脚本系统/专题研究/创游世界战斗系统设计入门.mddocs/脚本系统/专题研究/创游世界脚本实战架构入门.md
  • OCR 反查入口:docs/OCR资料/官方教程截图转文本索引.md
  • 编号映射入口:docs/OCR资料/映射表/OCR 图片编号映射表.md

关联阅读


后续优化方向

  • [ ] 补充具体项目中的状态图示例
  • [ ] 添加更多中断规则的实战案例
  • [ ] 完善状态优先级的详细说明

参与维护

发现文档问题?

你可以编辑页面、提交反馈,或复制链接给维护者,帮助这个资料库继续变好。

由 Azek431 整理与维护 | 基于 MIT 许可证开源