Godot HitStop 与时间停顿：打击感不是随手暂停几帧

HitStop 是动作游戏里最直接的打击感手段之一。命中瞬间停顿几帧，玩家会感觉攻击更重；格挡时短暂冻结，反馈会更清楚。但 HitStop 也很容易写坏：全局暂停导致 UI、网络、粒子和音频一起卡住；多个命中叠加让角色像掉帧；恢复时动画不同步；联网场景中本地停顿影响预测。

Godot 提供 Engine.time_scale、AnimationTree、Timer、process mode 等能力，但打击停顿不应该等同于全局 time_scale。更可靠的做法是建立 HitStopCoordinator，把停顿时长、作用对象、时间域、输入缓冲和恢复曲线都数据化。

项目里的真实问题

一个近战项目中，程序在命中时直接把 Engine.time_scale 设为 0.05，0.08 秒后恢复。单机训练房里很爽，进入真实关卡后问题很多：UI 冷却也变慢，网络心跳延迟，粒子拖尾异常，多个小怪同时被连击时停顿不断叠加，Boss 多段攻击甚至让游戏像卡死。

问题不是 HitStop 本身，而是作用范围不清。重击命中需要停顿攻击者、受击者和部分镜头；普通持续伤害不需要停顿；多人远端角色可能只播放表现停顿；UI、输入采样和网络不能被全局冻结。

设计目标

• 局部生效：按命中类型决定停顿对象，不把整个游戏粗暴暂停。
• 叠加可控：多次命中有合并、上限和衰减，避免连续卡死。
• 输入不断：玩家输入采样和缓冲在停顿期间仍然可靠。
• 恢复自然：动画、粒子、音频和镜头按规则恢复，不突然跳变。

这些目标不是为了堆抽象，而是为了让 Godot 客户端在内容量增加、平台差异变多、团队协作变复杂之后仍然可维护。原型阶段直接在节点脚本里写判断很快，但进入发版节奏后，系统需要能解释当前状态、能处理失败、能被 QA 复现，也能被后续同事接手。

推荐架构

flowchart TD
    A["命中事件/格挡事件"] --> B["HitStopCoordinator"]
    B --> C["停顿规则表"]
    B --> D["时间域路由"]
    B --> E["输入缓冲"]
    B --> F["恢复曲线"]
    C --> G["状态快照"]
    D --> G
    E --> G
    F --> G
    G --> H["表现层/日志/回滚"]

图里的模块可以按项目规模合并。小团队可以先用一个 Autoload 管理核心状态，大团队再拆成 Resource 配置、运行时服务、调试面板和 UI ViewModel。真正重要的是调用方向：业务脚本提交意图，系统层做决策，表现层只消费快照。这样功能不会随着页面和场景数量增长而失控。

关键实现细节

HitStopRequest 应包含 source_id、target_ids、kind、duration_ms、strength、time_domain、priority、merge_key。普通轻击可能 35ms，重击 80ms，破盾 120ms；同一 merge_key 在短窗口内合并，不能无限叠加。
时间域要分开。Gameplay 动画和物理可以暂停或降速，UI 使用真实时间，输入采样继续运行，网络保持正常 tick。Godot 中可以通过自定义 TimeDomainService 分发 delta，而不是直接依赖全局 time_scale。
输入缓冲必须明确。玩家在 HitStop 期间按下闪避或连击，输入应该进入 buffer，并在恢复后按规则消费。否则停顿越强，操作越不跟手。
音频通常不应该完全暂停。命中音效可以正常播放，环境和音乐不受影响；某些重击可以短暂 ducking 或加瞬态效果。声音和画面停顿要配合，而不是一起冻结。

失败处理和恢复路径

HitStop 请求异常未释放时，要有最大持续时间保护。任何来源都不能让角色永久停住。
联网项目里，本地 HitStop 不应改变权威模拟时间。客户端可以做表现停顿，但预测和服务器同步要有独立时钟。
切场景或死亡时清理所有未完成停顿，避免复活后仍处于慢速域。

数据契约和协作接口

CombatSystem 发出 HitStopRequest，不直接改 time_scale。HitStopCoordinator 决定目标和时间域。
角色控制器读取 TimeDomain delta，同时输入系统读取真实时间并维护 buffer。
表现规则表定义 kind 到 duration、strength、merge_window、max_stack 的映射。

GDScript 接口草图

class_name HitStopCoordinator
extends Node

signal snapshot_changed(snapshot: Dictionary)
signal warning_raised(code: String, detail: Dictionary)

var _snapshot := {}
var _active_version := 0

func submit(intent: Dictionary) -> void:
    _active_version += 1
    var version := _active_version
    _snapshot = {"phase": "pending", "intent": intent, "system": "godot-hitstop-time-dilation-rules-2026"}
    emit_signal("snapshot_changed", _snapshot)
    _resolve(intent, func(result: Dictionary):
        if version != _active_version:
            return
        if result.get("warning", "") != "":
            emit_signal("warning_raised", result.warning, result)
        _snapshot = result
        emit_signal("snapshot_changed", _snapshot)
    )

func current_snapshot() -> Dictionary:
    return _snapshot.duplicate(true)

这段代码只表达接口形状。实际项目里，intent 应该换成明确的 Resource 或 typed Dictionary，_resolve 内部也要处理超时、取消、错误码和日志。保留版本号，是为了避免旧异步结果覆盖新状态。Godot 项目里 UI 快速切换、资源晚返回、网络重试都很常见，没有版本保护会出现非常隐蔽的回退问题。

分阶段落地

第一阶段只对玩家近战命中和受击者动画做局部停顿。
第二阶段加入合并窗口、输入缓冲和镜头冲击。
第三阶段处理联网表现停顿、多角色叠加和调试 Overlay。

自动化验证和人工验收

快速连击多个敌人，确认 HitStop 不无限叠加。
停顿期间按闪避，恢复后输入能按预期消费。
UI 冷却、网络心跳和 Toast 不受 HitStop 影响。
切场景、死亡、暂停时清理未完成停顿。

观测指标

• HitStop 请求次数、合并次数和丢弃次数。
• 每次停顿实际持续时间与规则差异。
• 输入缓冲在停顿期间的命中率。
• 超过最大停顿保护的次数。

指标不必一次性全部上报。开发包可以显示完整调试面板，内测包采样关键计数，正式包只保留错误码和聚合趋势。关键是让一次异常能落到具体阶段、具体配置和具体玩家路径，而不是停留在“好像偶尔不对”的口头描述。

上线前检查清单

• 没有技能脚本直接写全局 time_scale。
• HitStop 规则有上限、合并和优先级。
• 输入采样使用真实时间。
• 联网模拟和表现停顿分离。
• 死亡和切场景会清理停顿状态。

检查清单不是为了增加流程负担，而是把隐性经验写下来。能自动化的尽量交给脚本，不能自动化的也要明确谁在什么阶段确认。每次事故复盘后补一条检查项，系统会随着项目经验逐渐变厚。

案例复盘

一次 Boss 战复盘中，玩家多段攻击同时命中三个弱点，旧实现给每个弱点都触发 90ms 停顿，叠起来接近半秒。修复后，同一攻击帧的停顿按 merge_key 合并，只取最高强度，并给 Boss 弱点设置共享冷却。打击仍然有重量，但不会像卡死。

灰度验收脚本

灰度验收可以在训练房测试轻击、重击、破盾、连击、多目标和死亡清理。打开 HitStop Overlay，记录请求来源、实际持续时间和输入缓冲。验收重点不是停顿越明显越好，而是强反馈和操作连续性之间的平衡。

维护策略

HitStop 规则上线后，新增技能必须声明是否触发停顿、停顿类型和 merge_key。战斗策划可以调时长，但不能绕过 Coordinator。每次调大停顿，都要重新跑连击和多目标测试，避免局部爽感破坏整体流畅度。

工程补充

HitStop 还需要和镜头、手柄震动、伤害数字建立顺序。推荐顺序是先确认命中和伤害，再发 HitStopRequest，再触发镜头冲击和震动，最后让伤害数字按停顿后的节奏出现。如果伤害数字先飞、画面后停，会显得反馈错位。多人项目还要区分本地玩家和远端玩家：本地玩家的命中可以有更强停顿，远端玩家的表现应轻一些，避免整个画面频繁卡顿。

这个系统落地后，配置版本要进入日志和问题反馈。无论是停顿规则、地表定义、高亮样式、配方表、成就定义还是占位策略，只要配置能影响玩家体验，就应该有版本号。线上反馈如果只知道“高亮不对”或“脚步声错了”，但不知道玩家用的是哪版配置，排查会非常慢。

调试面板也要尽早准备。开发包里至少能看到当前输入意图、系统决策、最终快照、失败原因和配置来源。对于表现类系统，最好能在画面上叠加当前 id：surface_id、highlight source、recipe_id、achievement_id、boss_phase。QA 截图带上这些信息，开发就能少猜很多。

协作与内容接入

这类系统大多需要内容同学持续接入。新增地表、新增配方、新增成就、新增 Boss 阶段、新增高亮样式，都不应该只改一个资源路径。每种新增内容都要有最小样本和验收步骤。样本可以很小，但必须能触发主要路径和失败路径。

建议把接入说明写成三段：需要填哪些字段，常见错误是什么，如何在调试模式验证。文档不必冗长，但要足够具体。例如“新增配方必须提供 recipe_version、result_preview、server_quote_policy”，比“记得配置完整”有用得多。

边界和降级

降级策略要提前写清楚。HitStop 异常时可以跳过停顿但保留伤害；脚步 Surface 缺失时用默认脚步；高亮样式缺失时用低强度默认描边；制作 quote 失败时禁用制作按钮；成就平台同步失败时保留本地 pending；截图隐私处理失败时阻断公开分享。不同系统的降级不一样，不能统一成“出错请重试”。

降级也要进入指标。fallback 次数长期偏高，说明内容或配置质量有问题。运行时兜底是保护玩家路径，不是让错误长期存在。每周看一次 fallback 排行，比发版前临时大扫除更有效。

小团队接入版本

小团队可以先做攻击者和受击者的局部动画暂停，不碰全局 time_scale。只要输入和 UI 不受影响，HitStop 的基础体验就会比全局暂停稳很多。之后再加镜头、音频和联网表现。

交付边界

交付标准是重击更有重量，轻击不拖泥带水，连续战斗不会出现假卡顿。HitStop 是打击感工具，不是性能掉帧的伪装。

结语

打击感不是随手暂停几帧。Godot 项目把 HitStop 做成时间域和规则系统后，命中反馈、输入缓冲、动画恢复和联网表现才能一起成立。