音游、格斗与竞速的权威时间源：输入、模拟、音频与表现层的时钟分工

问题与结论

系列目录

玩家按下按键，画面可能要到下一帧才显示动作。

车辆越过终点线，计时 UI 可能稍后才刷新。

格斗游戏收到远端输入后，可能发现刚才几帧预测错了。

音游发生一次渲染卡顿，音符甚至会瞬间跳过一小段距离。

这些现象都说明：一件事真正发生的时刻，与玩家在屏幕上看见它的时刻，并不总是相同。

如果游戏没有明确哪一个时间负责裁定，卡顿、刷新率、设备延迟、暂停、慢动作和网络抖动就会进入规则层。玩家最终感受到的不是困难，而是系统前后不一致。

先说结论：权威时间源，就是“最后听谁的钟”

权威时间源（即“最后听谁的钟”）：当多个时间读数不一致时，某一裁定域用于确认事件先后、持续时间和结果的基准；不同裁定域可以各有权威，但跨域换算必须明确。

“最后听谁的钟”不是要求整款游戏只能存在一个计时器。

恰恰相反，复杂游戏通常同时存在：

• 操作系统的单调时钟；
• 音频设备的播放位置；
• 固定逻辑帧或物理 Tick；
• 渲染帧时间；
• 动画播放时间；
• 网络确认帧；
• 回放播放时间；
• UI 展示时间。

真正重要的是给这些钟分工：

• 哪一只钟记录规则事实？
• 哪些钟负责把外部事件映射到规则时间？
• 哪些钟只负责把结果展示得平滑？
• 时间发生跳转或预测修正时，怎样恢复一致？

音游、格斗和竞速给出了三种不同答案，但它们遵循同一条原则：

先确定规则听谁的钟，再让画面追上已经成立的事实。

证据与分析

音频主时钟：歌曲说现在到哪了

音频主时钟（即“歌曲说现在到哪了”）：以音频设备的播放游标、DSP 时间或采样位置表示歌曲当前进度，并作为节奏判定的主要时间基准。

在音游里，歌曲说现在到哪了，比这一帧音符画到哪了更可信。

例如一首音频的采样率是 48,000 Hz，播放游标位于第 240,000 个采样，则相对该播放代次起点经过了约五秒的采样进度。前提是游标单位、起点、采样率和播放速率已定义；DSP 时钟、排队采样和实际出声位置也不能无校准地混用。谱面中的目标时刻可以在加载时转换成同一种采样单位。

玩家输入是否命中，只需比较：

• 输入对应的歌曲采样位置；
• 音符目标采样位置；
• 当前规则允许的时间误差。

渲染卡顿可以让音符画面短暂跳跃，却不能让歌曲已经播放的采样倒退。动画漏掉一个回调，也不能改变谱面上的目标时间。

因此，以下对象都不适合成为音游的最终裁定者：

• 音符在屏幕上的坐标；
• 每帧累计的 deltaTime；
• 动画播放百分比；
• UI 进度条；
• 音符表现对象是否已经生成；
• 系统日历时间。

谱面记录的是时间规则，场景中的音符只是它的视觉代理。

时间域映射：把不同的钟对到一起

时间域映射（即“把不同的钟对到一起”）：通过同时刻快照、偏移和换算规则，把一个时间系统记录的事件转换到权威时间轴。

输入设备并不知道歌曲播放到了第几个采样。它通常只知道：“某个按键在主机单调时钟的这个时刻被按下。”

音频系统则知道：“这个主机时刻附近，歌曲播放游标位于这个采样。”

把不同的钟对到一起，可以想成定期拍下一张双时钟快照：

主机时间 H0  ↔  音频采样 A0
主机时间 H1  ↔  音频采样 A1

当输入发生在 H0 与 H1 之间时，系统便可把它换算到对应歌曲位置，再应用已经明确含义的设备与玩家校准。

这里尤其要避免把所有延迟塞进一个含义不明的总偏移：

• 输入设备补偿会改变输入映射到规则时间的位置；
• 音频输出补偿解释声音实际被听见的延迟；
• 视觉偏移只改变音符何时抵达判定线；
• 打击反馈偏移只调整声音、震动和动画反馈。

如果视觉偏移反过来修改目标时刻，玩家换一块显示器，游戏规则也会跟着变化。

输入时间戳：按下时就记时间

输入时间戳（即“按下时就记时间”）：输入事件被设备或系统捕获时立即记录的单调时间，以及用于维持稳定顺序的事件编号。

按下时就记时间，是为了区分“玩家何时操作”与“游戏何时处理”。

假设游戏暂时下降到每秒 20 帧，同一帧的 50 毫秒内可能发生多次按键。若系统到下一次更新时才统一使用当前帧时间，这些输入会被压成同一个时刻。

保留原始记录后，玩法层才能准确还原：

• 哪个输入先发生；
• 两个按键相差多少时间；
• 输入属于哪一次播放或比赛；
• 输入来自哪个设备；
• 该时间戳精度来自硬件、操作系统还是帧内估算。

输入层只记录事实，不负责决定它命中了哪个音符、触发了哪个招式或怎样影响车辆。

音游会把记录映射到歌曲时间；格斗会把它归入逻辑帧并加入输入历史；竞速会把方向、油门和制动采样成某个模拟 Tick 的驾驶意图。

固定步长模拟：每次按同样大小往前走

固定步长模拟（即“每次按同样大小往前走”）：规则世界使用恒定时间间隔和固定执行顺序推进，而不是直接跟随每个渲染帧长短。

以固定逻辑帧格斗与固定步车辆模拟为目标时，需要每次按同样大小往前走；这不是所有作品和所有圈速规则都必须采用的唯一实现。

格斗游戏可能每秒推进 60 个逻辑帧。每一帧按稳定顺序读取输入、识别指令、推进动作、更新碰撞区域、裁定命中、提交伤害并生成快照。

竞速游戏则在每个 Tick 中读取驾驶意图，计算发动机、轮胎、抓地、外力与碰撞，再更新赛道投影、检查点、圈速和排名。

固定的不只是 delta 数值，还包括读写相位。

以引擎物理循环为例，一次渲染帧可能执行零次、一次或多次物理子步。每个子步又可以按类似顺序完成：

1. 回传上一步产生的碰撞与查询结果；
2. 运行本步玩法逻辑；
3. 处理导航或其他固定步系统；
4. 提交延迟命令；
5. 对物理世界执行本步积分；
6. 再把后续命令送入稳定边界。

如果某个模块在自己的回调里私自多推进一次时钟，或者在求解进行到一半时读取半更新世界，即使步长数值固定，结果仍然不稳定。

判定窗口：早一点晚一点还算不算

判定窗口（即“早一点晚一点还算不算”）：规则明确允许事件相对目标时刻提前或延后的范围，以及不同误差对应的结果等级。

早一点晚一点还算不算，必须是正式规则，而不能散落在各种临时修正里。

音游最容易理解：

• 非常接近目标时刻，得到最高等级；
• 稍早或稍晚，得到较低等级；
• 超出允许范围，记为失误；
• 长按提前松开、错轨输入和滑动方向错误，需要给出不同原因。

同一思想也会出现在其他类型：

• 格斗中的输入缓冲和指令方向容差；
• 精确格挡的提前与延后范围；
• 竞速起跑对抢跑的判定；
• 网络对战中的有限命中补偿；
• 平台跳跃中的“土狼时间”。

容忍输入不等于模糊结果。玩家意图可以被更友好地识别，但一旦进入规则裁定，同一条件必须得到稳定答案。

确定性裁定：同样输入必须得到同样结果

确定性裁定（即“同样输入必须得到同样结果”）：在规则版本、初始状态和输入序列相同的前提下，系统以稳定顺序产生一致结果。

同样输入必须得到同样结果，是回放、联网验证和自动测试能够成立的基础。

音游不能让每个音符对象各自在更新函数里争抢一次按键，否则对象遍历顺序或帧率变化就可能改变命中对象。

格斗不能让动画事件决定攻击框何时出现，否则动画丢帧或资源差异会改变比赛。

竞技排行榜不能直接信任未经验证的客户端秒表结果；即便使用单调时钟，也需确认比赛规则、越线顺序和结果可信性。

稳定裁定通常需要：

• 明确的输入排序；
• 明确的候选收集范围；
• 明确的冲突优先级；
• 明确的提交顺序；
• 可冻结的规则版本；
• 足以重建未来的状态快照；
• 对随机流游标和临时规则的记录。

“确定”不是要求所有模拟都使用整数，也不是保证不同平台的任意物理实现天然逐位相同。它要求系统先声明可复现边界，再为这个边界选择合适的数据与算法。

表现层投影：画面展示结果，不决定结果

表现层投影（即“画面展示结果，不决定结果”）：根据已经成立的逻辑状态计算动画、坐标、特效、镜头、声音和 UI，而不让这些表现反向定义规则事实。

画面展示结果，不决定结果，是三类游戏最直接的共同语言。

在音游里

音符位置应由“目标歌曲时间减去当前歌曲时间”计算。某一帧卡顿后，下一帧可以直接画到正确位置，不会继续累积位移误差。

在格斗里

当前动作帧、攻击框、受击框和取消窗口由战斗逻辑确定。骨骼插值可以让动作更顺，却不能决定攻击是否已经生效。

命中停顿也能分层处理：角色动作暂时停住，输入继续采样，镜头、闪光和部分粒子仍可表现。

在竞速里

车辆物理状态由固定步推进，渲染层在相邻逻辑姿态之间插值。显示计时、回放速度和慢动作可以变化，圈速则服从已声明的比赛时钟。它可由逻辑 Tick、Tick 内越线插值或独立单调计时派生；关键是暂停、慢动作与联网裁定的换算规则一致。

把画面与事实分开，不会让表现变得次要。它只是让表现拥有更安全的自由：可以插值、预测、延迟确认或夸张反馈，而不会改写比赛结果。

回滚重演：回到旧状态再算一遍

回滚重演（即“回到旧状态再算一遍”）：发现过去某一帧使用了错误预测后，恢复到该帧之前的逻辑快照，并用已经确认的输入重新模拟到当前时刻。

回到旧状态再算一遍，是格斗联网中常见的低延迟策略。

本地玩家输入可以立即进入模拟；尚未到达的远端输入先使用稳定预测。远端真实输入到达后，如果预测不一致，系统就恢复最早错误帧并重算。

真正困难的不是“把角色位置改回来”，而是：

• 快照是否包含所有会影响未来的状态；
• 重算顺序是否与正常模拟完全相同；
• 随机流是否回到正确位置；
• 已确认音效和特效是否会被重复播放；
• 预测表现怎样平滑修正；
• 最多允许回到多早以前。

因此，回滚能力本质上是在检验战斗核心有没有把规则事实与表现副作用分开。

竞速中的幽灵、比赛回放和重连也需要类似的状态与输入记录，但不一定采用与格斗相同的逐帧预测策略。音游的练习跳转和回放更常围绕歌曲时间、谱面与输入日志重建。

共同原则可以迁移，具体同步方案不能直接照搬。

连续竞赛进度：不只看过了几个检查点

连续竞赛进度（即“不只看过了几个检查点”）：综合圈数、合法路线、最后有效检查点和沿当前路段的投影距离，得到稳定可比较的比赛进度。

竞速的时间事实不仅是秒表，还包括“谁真正更靠前”。

不只看过了几个检查点，是因为两辆车可能位于同一检查点区间，却相差几百米；交叉赛道上的两辆车在三维空间里很近，也可能处于完全不同的路线阶段。

系统需要先用赛道拓扑确认合法路线，再把车辆位置投影到正确路段。越野捷径、倒车穿终点、非法重生和跳过检查点都不能仅凭空间位置获得进度。

圈速和排名因此共同依赖规则时间与规则空间：

• 时间确认何时通过；
• 拓扑确认通过了哪一段；
• 连续投影确认在该段前进了多少；
• 处罚规则确认最终成绩如何调整。

这也是为什么“车头看起来领先”与“规则上已经领先”不能永远画等号。

适用边界与实践

三类玩法为什么不能听同一只钟

三类游戏共享架构原则，却不能共用同一个直接权威。

音游不能简单改用固定战斗帧，因为玩家要跟随实际听见的连续音频。

格斗不能改用动画播放时间，因为动作契约、回滚与碰撞必须可重算。

竞速不能只记录音频或渲染时间，因为车辆动力学、赛道进度和处罚需要共同推进。

它们真正共享的是决策方法：

1. 找到最接近玩法事实的时钟；
2. 把外部输入映射进该时间域；
3. 用稳定顺序提交规则结果；
4. 让表现层追随结果；
5. 为暂停、跳转、预测和恢复定义明确边界。

一份强时序系统检查表

权威与映射

• 系统是否明确写出最后听哪一只钟？
• 其他时钟与权威时间之间怎样建立快照或映射？
• 使用的是单调时间，还是可能被系统校时修改的日历时间？
• 暂停、切歌、重开和设备切换是否会产生新的播放代次？

输入与裁定

• 输入是否在捕获时记录，而不是处理时补记？
• 同一帧内多个输入是否保留稳定顺序？
• 时间容忍是否有正式配置和失败原因？
• 候选收集、冲突仲裁和结果提交是否确定？
• 同一输入日志能否稳定复现结果？

模拟与相位

• 固定步是否同时固定执行顺序？
• 一次渲染帧执行零个或多个规则步时，系统是否仍正确？
• 查询结果、玩法逻辑和物理求解的读写边界是否明确？
• 有没有模块在自己的回调中私自推进全局时钟？

表现与恢复

• 动画、屏幕坐标、UI 或特效是否被错误地当成规则来源？
• 卡顿后表现能否追上事实，而不是永久积累误差？
• 回滚或跳转时，已确认事件是否会重复播放？
• 快照是否包含所有影响未来的逻辑状态，并排除纯表现状态？
• 调试工具能否同时显示输入时间、规则时间和表现时间？

结语：公平感来自时间事实能够被解释

音游玩家希望系统准确承认自己按得早还是晚。

格斗玩家希望同一招式的启动、命中和受罚永远遵守同一份帧数据。

竞速玩家希望圈速、排名和处罚不会因为客户端性能或画面刷新方式发生变化。

这些公平感背后都有同一个要求：系统必须保存一份可以追溯的时间事实。

权威时间源并不是一只万能时钟，而是一份清楚的责任划分。歌曲进度、战斗帧和比赛 Tick 各自回答不同问题；输入、网络、回放与画面则通过映射、预测和投影围绕它们工作。

当规则事实稳定时，表现可以大胆地插值、慢放、停顿和修正。

当规则事实含糊时，再流畅的动画也掩盖不了一次“不知道为什么算我失败”的判定。

来源与验证状态

术语对照

内部资料依据

以下链接用于仓库内部审稿与追溯，不是公开版最终引用：

• 节奏游戏：音频主时钟、谱面编译与确定性判定
• 传统对战格斗：帧数据、动作仲裁与回滚
• 驾驶竞速：固定步长、赛道拓扑与连续裁定
• Godot 主循环物理步进与查询回传时间线（内部研究材料）

公开发布前应补充公开案例或公开设计资料，并把内部路径替换为稳定公开链接。

2026-10-26 复核 Unity DSP 时钟定义 与 GGPO 官方回滚说明，用于核对时钟域和预测重演概念；文中 60 Hz、48 kHz 及竞速模型是说明性设计，不是所有作品的实测事实。未运行音频延迟、联网或圈速实验。