上一篇讲每帧状态哈希提到帧同步的核心假设——同样的逻辑喂同样的输入结果必然一致。这篇要讲的东西正是这个假设带来的一个爽到不行的副产品你几乎不花额外成本就能拿到一套完整的游戏回放系统。为什么帧同步做回放这么便宜先想想传统架构状态同步要做回放有多麻烦。状态同步里服务器不断把世界状态广播给客户端客户端负责显示。要录回放你得把每一帧的完整世界状态都存下来——所有单位的位置、血量、状态……回放的时候一帧帧读出来还原。这个数据量大得吓人一局游戏录下来动辄几百兆,而且你还得单独维护一套从存档还原世界的逻辑。帧同步完全是另一个画风。既然输入决定一切那我根本不用存世界状态我只要把每一帧、每个玩家按了什么存下来就行了。回放的时候把这些输入按原来的帧序重新喂给逻辑游戏自己就会一模一样地重演一遍。一局 RTS 打半小时输入数据可能就几百 KB。这就是帧同步的魔法世界状态是输入的确定性函数存输入等于存了一切。输入序列长什么样所谓录制输入序列本质就是一个按帧组织的输入指令列表。[Serializable]publicclassInputCommand{publicintPlayerId;publicCommandTypeType;// 移动、攻击、释放技能...publicFixVector2Target;// 定点数坐标别用 floatpublicintSkillId;// ... 这条指令需要的参数}[Serializable]publicclassFrameInput{publicintFrameNumber;publicListInputCommandCommands;// 这一帧所有玩家的所有指令}// 整局回放就是这么个东西publicclassReplayData{publicuintRandomSeed;// 初始随机种子必须存publicintMapId;// 用哪张地图publicListPlayerInfoPlayers;// 有哪些玩家、用什么阵营publicListFrameInputFrames;// 逐帧输入}注意ReplayData的头部信息。光有逐帧输入还不够你得能把游戏还原到开局那一刻然后才能开始重放输入。所以初始随机种子、地图、玩家配置这些开局参数一个都不能少。随机种子尤其关键——上一篇说过它决定了后续所有随机结果种子对不上第一次随机就歪了。录制其实你什么都不用额外做录制的美妙之处在于如果你的帧同步框架是干净的录制几乎是免费的。帧同步里必然有一个地方负责把这一帧收集到的所有输入指令派发给逻辑层去执行。你要做的就是在这个必经之路上顺手把指令抄一份存起来publicvoidExecuteFrame(intframeNumber,ListInputCommandcommands){// 录制派发之前先存一份if(isRecording){replayData.Frames.Add(newFrameInput{FrameNumberframeNumber,Commandscommands});}// 正常的逻辑执行跟平时一模一样foreach(varcmdincommands){logicWorld.ApplyCommand(cmd);}logicWorld.Tick();}就这么几行。录制和正常游戏走的是完全相同的执行路径这一点非常重要——录制不能是一条独立的代码分支。一旦录制走的逻辑和实际游戏不一样那你录出来的东西就未必能正确重放。让它们共用一条路录制的正确性就等于游戏本身的正确性。回放把网络输入换成文件输入回放同样是复用整套逻辑唯一的区别是正常游戏里输入来自网络回放里输入来自文件。publicvoidPlayReplay(ReplayDatareplay){// 用录制时的开局参数初始化世界logicWorld.Init(replay.RandomSeed,replay.MapId,replay.Players);// 逐帧把存下来的输入喂回去foreach(varframeinreplay.Frames){// 走的还是 ExecuteFrame跟实际游戏同一条路ExecuteFrame(frame.FrameNumber,frame.Commands);}}看出来关键了吧输入的来源变了但处理输入的逻辑一点没变。网络层和回放层在架构上是可替换的两个输入源下游逻辑完全无感。这种设计下只要你的实际游戏是对的回放就自动是对的。状态哈希在这里的第二次登场上一篇讲的每帧状态哈希在回放这件事上还有个大用处。如果你录制的时候顺手把每帧的状态哈希也存进ReplayData那回放的时候就能干一件很爽的事一边重放一边拿重放算出的哈希和当年录制时存的哈希逐帧对比。uintreplayHashlogicWorld.ComputeFrameHash();if(replayHash!frame.RecordedHash){Debug.LogError($回放第{frame.FrameNumber}帧对不上了);// 说明确定性被破坏了}如果回放的哈希和录制时的哈希对不上那只能说明一件事——你的逻辑不是确定性的。同样的输入、同样的种子重放居然算出了不同结果这就是确定性被破坏的铁证。所以回放系统同时也是一套超强的确定性验证工具。你可以把线上真实对局的输入序列录下来拿到本地反复重放跑哈希专抓那些偶发的、难以复现的不同步 bug。这比在真机上对着两台设备干瞪眼高效太多了。几个绕不开的现实问题版本兼容。回放的致命软肋是它极度依赖逻辑代码。你今天录的回放明天改了个技能数值、调了下寻路逻辑这个老回放再放出来结果就全变了——同样的输入喂给新逻辑算出的是新世界。所以回放数据里必须存一个逻辑版本号版本对不上就别放了放出来也是错的。这也是为什么很多游戏更新后老回放就失效了。输入之外的随机源。前面反复强调种子就是因为回放里绝不能有种子之外的随机来源。任何System.Random、Time.time、Guid.NewGuid()这种游离在确定性框架之外的东西混进逻辑层回放当场崩给你看。这条和状态哈希那篇的要求是完全一致的——逻辑层必须是纯粹的、可复现的。存储优化。虽然输入序列本身已经很小但还能更小。大多数帧其实玩家啥也没按尤其 RTS人的操作频率远低于逻辑帧率空帧根本不用存回放时按帧号插空即可。指令本身也能做增量、做压缩。一局游戏最后压到几十 KB 很正常塞进战报、随邮件发送都毫无压力。这套东西能干嘛录制输入序列做出来之后你会发现它的用途远超给玩家看回放这一个玩家回放赛后复盘、精彩集锦、战报分享这是最直接的。Bug 复现玩家报了个诡异 bug让他把回放文件发上来你本地一放就能稳定复现不用再猜。确定性巡检把大批线上对局的回放跑批量重放对哈希自动化揪出不同步隐患。反外挂回放能还原完整对局配合服务器校验能发现很多异常操作。观战和 TV延迟几秒的观战本质上就是实时性的回放。说到底录制输入序列是帧同步架构送给你的能力。它便宜到几乎不用专门开发前提是你的框架足够干净——逻辑层纯粹、输入源可替换、确定性有保障。反过来看如果你发现回放做不出来、或者放出来总对不上那问题多半不在回放系统本身而是你的帧同步地基没打牢。从这个角度说能不能顺利做出回放本身就是对整套帧同步架构是否合格的一次体检。下一篇打算聊聊帧同步里的输入延迟处理——玩家按下按键到实际生效之间那几帧的延迟是怎么来的又该怎么在手感和同步之间找平衡。