动作系统设计：从状态机到输入缓冲与命中判定的实践

上面这个东西当时做的时候，心里其实没底。动作系统不是单纯堆一堆动画切片让角色播片，真正麻烦的是"逻辑"。如果只是跑一个Demo，用状态机硬编码也没问题，做到十几个动作就要开始裂开；做到角色、敌人、场景交互混在一起的时候，硬编码基本就是灾难。这篇东西就围绕"动作逻辑与机制"讲讲我在一个3D动作场景交互实验项目里的思路、踩坑和最终落地的取舍。

1. 动作逻辑的骨架：为什么状态机总是"死路一条"

1.1 大多数人印象里的状态机长什么样

做动作系统，新手最容易想到的就是状态机。一个角色有Idle、Walk、Run、Jump、Attack，每个状态根据输入跳转，画一张大流程图，好像就能把动作管起来。

实际做起来你会发现这套思路撑不住。原因不复杂：动作状态机里的"状态"如果颗粒度太粗，一个Attack状态内部其实还分成前摇、命中帧、后摇、收招等多个阶段，每个阶段的可打断性完全不同；如果颗粒度太细，状态数量爆炸，状态之间的连线比蜘蛛网还密。我在项目里一度把状态列表拉到了四十多个，连线画完自己都看不懂。

"状态"本身不是问题，问题是"状态"承载的职责太多了。它既要在管"当前播放哪个动画"，又要在管"能不能被其他动作打断"，还要在管"移动和转向是否允许"，甚至还要在管"攻击判定什么时候生效"。这些职责绑死在状态枚举里，改一个需求就得动一堆条件判断。

1.2 几个反直觉的坑

第一，状态机里的"跳转条件"看起来是代码，其实是全局耦合。比如Jump可以打断Attack，这个规则写在Attack状态里还是Jump状态里？都有程序员这么干过，但一旦规则多了，同一个打断规则被复制到十几个状态，改一次就要翻遍整个文件。

第二，"状态"这个概念天然是离散的，但动作手感是连续的。比如从Run突然切到Attack，动画过渡做不好，角色就像瞬移一样切换姿势。为了让过渡不突兀，你还需要一层"动画融合"逻辑，可它跟状态跳转逻辑是两码事。很多人的状态机里混着动画Transition和逻辑Flag，调试的时候两个维度来回切，非常痛苦。

第三，状态机回答的是"现在在干什么"，但动作系统真正要回答的是"接下来能干什么、不能干什么"。这是两套问题。前者是状态描述，后者是规则约束。我在项目里把这两件事拆开了之后，动作逻辑瞬间清晰很多。

1.3 我最终采用的分层结构

做完复盘，我把动作逻辑拆成了四层：

• 动作声明层：角色有哪些动作，每个动作的基础属性（名称、时长、动画资源、移动配置）。
• 打断权管理层：每个动作对外的可打断规则，不依赖具体状态。
• 状态求解层：根据当前动作、输入、物理条件，算出"下一个动作应该是什么"。
• 动画表现层：拿到目标动作ID后，去处理AnimationClip的切换、融合、速度和播放位置。

这个结构里，状态机从"老板"变成了"翻译官"。状态机只管状态切换，打断规则交给一个独立的优先级表格，动画表现完全由动画层自行处理。改一个动作的打断规则，不需要动状态机代码；改动画融合参数，也不会影响逻辑判断。这样才算把"动作逻辑"和"动作表现"分开。

2. 手感的分水岭：输入缓冲与触发窗口的数值设计

动作逻辑里最影响"手感"的，不是状态机结构，而是输入处理。

2.1 从按下按键到角色出招，中间发生了什么

玩家按下一个攻击键，你不能立刻让角色出招。原因很简单：如果角色正在做上一个动作，比如正在跑动或者正在收招后摇里，直接切到新动作会显得非常生硬。

我项目里的处理链是：按下按键 -> 输入被记录并打上"按下时间戳" -> 输入管理器把这个意图广播出去 -> 动作系统在合适的窗口内检查这个输入 -> 如果当前动作允许打断并且在输入有效窗口内，则触发新动作。

这里最关键的概念是"输入缓冲"（Input Buffer）和"触发窗口"（Trigger Window）。输入缓冲指按键按下去之后，这个指令能保留多长时间；触发窗口指在某个动作播放的哪个时间段内，允许接受并响应新的输入指令。

2.2 为什么这两个窗口的数值直接决定手感

窗口太短，玩家感觉"按键不灵"，明明按了却没反应，尤其在连招衔接、闪避接攻击这类需要卡时间点的操作里特别明显；窗口太长，角色会"吞招"，玩家已经按了下一个技能，结果角色把当前动作做完才执行，看起来像慢半拍。

通常来讲，输入缓冲建议设置在100到150毫秒区间，触发窗口要根据具体动作设计：攻击命中的那一帧前后最容易接后续招式，因为这时候玩家注意力最集中。我在实验项目里把"攻击命中后继续输入下一招"的触发窗口设在80到120毫秒，正好覆盖玩家在命中反馈后的下意识输入区间。

有一点要单独提醒：游戏里如果跑在60帧，一帧约16.7毫秒，窗口设置低于30毫秒的话，玩家在掉帧到30帧时基本就无法触发连招了。做动作系统要留出"帧率容差"，尤其考虑低端设备和复杂场景下的性能损耗。

2.3 实测中的数据参考

我在项目里维护了一张输入窗口参数表，每个动作独立配置，核心参数如下：

这些数值不是拍脑袋写的，是我在项目里用慢动作重放逐帧调出来的。核心思路：先定"希望玩家在什么节奏下完成操作"，再把节奏换算成帧数，最后配合输入缓冲做微调。

3. 动作优先级与打断规则：谁能管谁，怎么管

状态机里的跳转条件多了以后，你会发现大量规则都在回答同一个问题：A动作进行到一半时，B动作能不能插进来？这个问题实际上和"当前状态"无关，只和"A动作的硬直级别"以及"B动作的优先级"有关。

3.1 优先级表的搭建

我借鉴了格斗游戏的做法，把所有动作按"硬直等级"分成八级。等级越高，越难被打断，也越容易打断别人。

这张表解决了一件事：打断规则从"每个状态都要写条件"变成"查表"。新加动作时，只需要给它分配一个优先级，系统自动就知道它能打断谁、能被谁打断。

3.2 三种打断策略

每个动作内部的打断点是不同的，所以不能简单地说"高优先级直接压过低优先级"。我在项目里实现了三种打断策略：

• 无条件打断：常见于闪避、防御、跳跃。无论当前动作在哪个阶段，只要按下对应按键，立即切换。这种策略适合"生存向"动作，玩家需要时刻判断施放时机。
• 帧窗口打断：常见于攻击动作的取消。只有在前摇阶段或者命中帧之后的特定时间段内，才允许被其他动作打断。超出窗口就要等当前动作播放完。
• 条件打断：常见于受击。只有当攻击判定命中角色且角色处于非霸体状态时，才切换到受击动画。

三种策略并存，配合优先级表，动作系统在判断"能否打断"时只需要三步：当前动作的打断策略是否允许？目标动作的优先级是否足够？当前播放的进度是否在可打断帧范围内？三步全过就执行切换，否则维持原动作。

3.3 实际调优中踩过的一个坑

最初我把"受击硬直"的优先级设为2，想着大部分动作都能打断受击。结果玩家角色被打飞之后，如果在空中按一下攻击键，角色居然能瞬间解除硬直在空中打出攻击，看起来特别违和。

后来发现，优先级表只解决了"能不能抢占"的问题，没有解决"当前状态允不允许抢占"的问题。空中、倒地、被击飞这几种状态应该单独有一个"状态锁"，这些状态里不允许低优先级动作抢占。最终的规则变成了：状态锁优先于优先级表，只有解除锁定后，优先级表才生效。这个改动之后，空中受击被攻击打断的Bug就消失了。

4. 命中判定的"侦探游戏"：从判定体生成到打击感事件链

动作逻辑的另一个大块是"攻击判定"。很多Demo里，角色挥剑动画播放完，敌人扣血，看起来能跑通，但玩家玩起来觉得"砍空气""没有打击感"。问题多半出在判定时机和判定体的设计上。

4.1 判定体生成时机：比"看见动画"更重要

新手常犯的错误是：动画一播放就生成攻击判定，直到动画播完才消失。这样做的直接问题是，攻击判定覆盖了前摇阶段，玩家还没看到刀刃挥出去，伤害就已经打出来了。

正确做法是在动画资源里挂"判定事件帧"。攻击判定不是由逻辑代码猜时机，而是由动画帧明确标记：第几帧开始生成判定体，第几帧结束，判定体用什么形状，偏移多少。当角色播放攻击动画时，动作系统监听这些事件帧，精确地在对应时间生成和销毁判定体。

我项目里的攻击判定事件结构长这样：

{ "attackId": "sword_combo_01", "events": [ { "frame": 14, "type": "hitbox_start", "shape": "capsule", "radius": 0.55, "height": 1.8, "offset": [0.2, 1.2, 0.6] }, { "frame": 20, "type": "hitbox_end" }, { "frame": 20, "type": "hit_effect", "effect": "slash_trail" } ] }

这里frame是动画帧序号。攻击判定窗口只有6帧（约100毫秒），但这段窗口如果落在"刀刃已经挥出、看起来最应该造成伤害"的时间点，玩家的命中感会非常强。如果你的动画是30帧的，开枪那一下的判定帧一定不要放在第1到5帧，要放在枪口闪光和手臂伸直的共同帧附近。

4.2 判定体形状：球体、胶囊体还是长方体

判定体形状不复杂，但选错会很出戏。近战武器（剑、刀）适合用胶囊体——细长，能覆盖挥砍弧线，又不至于把背后也判进去。拳头攻击适合用球体，拳头本身是一个点，球体判定接地气。远程子弹适合用胶囊体或者长方体，表现出子弹飞行方向上的贯穿感。

关键点在于"判定体跟着武器走，而不是跟着角色中心走"。如果判定体永远固定在角色中心，角色转向时攻击范围会出现明显偏差；让判定体和武器骨节点绑定，挥砍的弧线才能和视觉表现重合。

4.3 打击感事件链：命中之后发生了什么

一次有效命中，不应只做"扣血"这一件事。我在项目里定义了下面的事件链：

1. 判定体触发目标 -> 生成命中事件
2. 命中事件通知受伤方进入"受击硬直"状态
3. 命中事件同时通知攻击方播放"命中反应"动作（例如轻微停顿）
4. 命中点生成特效、飘字、音效
5. 镜头轻微震动，震幅受攻击等级影响

这套链路里，最难调的是"命中停顿"（Hit Stop）——攻击命中瞬间，双方动作暂停几帧，给玩家一个"砍中了"的放大信号。停顿太短，感觉像没砍到；停顿太长，节奏拖沓。我实验下来的参考值是：轻攻击停顿3到5帧，重攻击停顿6到8帧，处决动画可到12帧。停顿期间，攻击方和受击方都应暂停动画播放，但特效和音效照常播放。

4.4 受击反馈：为什么角色被打了要做"后退"而不是"原地抖"

受击动作还会牵涉"受击位移"。如果受击方原地播放动画但没有任何位移，玩家会觉得"打中了但对方没反应"。我这里做了两个档位：轻受击只播放动画，原地不动；重受击在播放动画的同时，沿攻击方向推出一小段位移，并叠加短暂的受击倾斜。

这里要注意位移不能只靠修改Transform来实现，否则会跟NavMesh和物理系统打架。我在项目里通过"受击位移板"解决：受击事件触发后，往受击者身上挂一个临时脚本，用曲线驱动位移，位移结束后自动回收。曲线前段快速推出，后段减速停滞，模拟被打击后失去平衡的感觉。

5. 引擎落地：Animator、GAS与自研状态机的取舍

到这一步，动作逻辑和机制在纸面上已经完整了。真到写代码的时候，你还要面对"选什么载体"的问题。不同引擎、不同方案，实现同样的逻辑，工程量天差地别。

5.1 三套主流方案对比

我在实验项目里选择了Unity + 自写逻辑层 + 动画层分离的方式。Animator只负责"播放哪个Clip、怎么过渡"，真正的状态判断和打断逻辑放在C#层。这样Animator的过渡图保持简单，每帧只需要被动的执行"该播什么动画"。

5.2 动画事件与逻辑事件不同步的坑

这个坑是必须拿出来说的：Unity的Animation Event是在动画线程里触发的，如果你的攻击判定代码直接挂在Animation Event上，一旦动画因为网络延迟、物理暂停、动画融合被跳过，判定就会遗漏或错位。

我后来把Animation Event统一改成"逻辑事件广播器"：动画只在特定的帧发出一个纯逻辑信号（比如AttackHitFrame），这个信号进入事件队列，由主循环的Update统一消费。这样即便动画播放卡顿、跳过过渡，逻辑侧依然能收到完整的事件序列，判定也就不会丢。

类似的问题也存在于"动画是否播完"的判断上。不要用AnimatorStateInfo.normalizedTime来驱动连招逻辑，那个值在动画循环和融合时会跳动，不如自己维护一套"逻辑播放进度"，用固定时间步更新，与动画播放器解耦。

5.3 Web端和工具链的额外思考

这次项目还涉及一个3D场景交互验证的小环境，用Web渲染做了原型。核心逻辑层我用TypeScript复刻了一遍，状态机和输入缓冲完全保持一致，只是渲染层从Unity换成了WebGL。

这里有两个经验供参考：第一，在Web端做动作逻辑调试，慢动作回放是利器——直接把时间缩放调成0.1倍，所有判定帧、输入缓冲、优先级判定都能看得一清二楚；第二，Web端的动画混合精度会受帧率波动影响，所以输入缓冲要比在Unity里再加大约30毫秒，否则低帧率设备上手感差异明显。

6. 调试动作逻辑必须掌握的三板斧

动作系统的调试，不能靠"感觉不对就改参数"。如果每一步都有迹可循，调起来会快很多。

6.1 可视化的状态运行面板

我做一个简单的调试面板，实时显示当前角色状态：

• 当前动作ID、播放进度、所属优先级
• 本帧输入缓冲队列（哪些按键在等窗口）
• 当前可被打断的策略类型和剩余窗口
• 最近5次状态切换的时间线

这个面板帮我解决了很多"莫名跳动作"的问题。比如玩家经常发现角色在跑动中突然抽搐，面板上一看，原来是输入缓冲里残留了一个攻击指令，跑动的某个帧窗口恰好允许打断，于是角色来了一刀。这种问题如果不可视化，很难从一堆日志里找出来。

6.2 慢动作重放系统

这是我整轮开发里性价比最高的工具。每次手感调优，录一段玩家操作（存按键时间戳），然后以0.2倍速重放，暂停在关键帧，逐一检查输入缓冲是否清空、优先级判定顺序是否正确、判定体是否和动画帧对齐。

实际调试中，"先录音再回放"比"现场改现场试"高效得多。因为现场调试时会不断重复操作，手速变化会干扰判断；而录音回放能保证每一次测试的操作序列完全一致，这样你改参数前后的对比才是有效的。

6.3 判定体的运行时渲染

命中判定体在编辑器里选中的地方能看到，但运行时如果不可见，你就不知道攻击判定的真实范围。美术做了一条巨大的斩击刀光，实际判定却只有角色身前的一小块胶囊体，这在视觉上特别露馅。我让所有判定体在Debug模式下常显，用线框绘制，并且用颜色区分当前处于"待激活"还是"已激活"状态。这一招基本能解决"刀光砍到人但没伤害"的反馈失真问题。

7. 一些留给后来者的经验

整个项目做下来，最大的体会是：动作逻辑不是代码堆出来的，是约束堆出来的。优先级表、输入窗口、打断策略、判定事件帧，这些东西每一项都是在定"游戏允许玩家做什么、不允许做什么"的边界。边界定得越清楚，手感就越扎实；边界模糊，哪怕动画再华丽，玩起来也只是在播片。

如果你准备起手做一个动作类交互实验，我建议别一上来就追求表现力，先把这三件事做扎实：一套独立于渲染的输入缓冲系统、一张足够细的动作优先级表、一个和动画帧对齐的判定事件机制。这三样稳定之后，再接特效、镜头、音效，手感才立得住。

最后说一个小技巧：在项目里给每个动作单独建一个"手感配置"脚本，把输入缓冲、可打断窗口、优先级、命中停顿、镜头震动幅度全部集中在这个配置里。你的策划如果也想参与调手感，只需要调这个脚本里的参数就行，不需要碰任何状态机代码。这个做法看似笨拙，但后续迭代手感时它的价值会被无限放大。