回放系统本质是序列化输入事件而非录屏，需在帧开始时捕获原始输入并存为带时间戳的结构体，使用内存环形缓冲区+后台线程落盘，回放时禁用实时输入、用帧计数器驱动，并依赖服务端快照保障联机一致性。
回放系统本质是序列化输入事件
游戏回放不是录屏，而是把玩家每帧的输入（按键、鼠标移动、手柄轴值）打上时间戳存下来。核心在于：你得在游戏主循环里捕获原始输入，而不是等逻辑处理完再记——否则会漏掉被消费掉的事件或引入延迟。
常见错误现象：SDL_PollEvent 或 glfwWaitEvents 被调用多次导致事件丢失；回放时用 SetCursorPos 强制重置鼠标位置，结果和摄像机朝向不匹配。
- 必须在输入采集阶段（比如帧开始时）立刻拷贝当前帧全部输入状态，存为结构体：
struct InputSnapshot { uint64_t frame; bool keys[256]; float mouse_x, mouse_y; }; - 不要依赖操作系统级输入钩子（如 Windows 的
SetWindowsHookEx），它们跨进程、权限高、易被反作弊拦截，且无法获取游戏内坐标系下的相对鼠标位移 - 若用 ECS 架构，把输入快照作为独立组件写入帧历史缓冲区，避免和实体生命周期耦合
录制时别直接写磁盘，先缓存再批量落盘
每帧都 fwrite 会导致 I/O 瓶颈，尤其在 60fps 游戏中可能卡顿。更糟的是断电或崩溃会让最后几秒数据全丢。
使用场景：联网对战游戏需支持“即时回放”（按 F12 立刻回看前 30 秒），这时内存环形缓冲区比文件更关键。
立即学习“C++免费学习笔记（深入）”；
- 分配一块固定大小的内存（比如 2MB），用环形队列存最近 N 帧的
InputSnapshot，写满后自动覆盖最老数据 - 后台线程每 500ms 把环形缓冲区中新数据
memcpy到临时文件，再rename替换旧文件（保证原子性） - 回放文件格式建议纯二进制：前 8 字节存帧数，后续每帧紧挨着存
InputSnapshot，不加 JSON 或 protobuf——解析快、体积小、无依赖
回放播放器必须解耦于游戏主循环
直接把回放数据塞进主循环做“重放输入”，会导致物理模拟失步、动画时间轴错乱。真实情况是：回放不是“重新运行游戏”，而是“驱动已有逻辑按指定输入演进”。
性能影响：若每帧都从文件读取并解析，60fps 下磁盘寻道会拖垮性能；兼容性问题：不同硬件/驱动下 QueryPerformanceCounter 时间精度不一致，导致回放加速或卡顿。
- 回放时禁用所有实时输入源（
glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_DISABLED)），只从内存缓冲区喂数据 - 用独立定时器控制播放节奏，不要依赖
glfwGetTime()—— 改用单调递增的帧计数器：replay_frame_index++，再查表拿到对应InputSnapshot - 关键帧插值可选：对鼠标移动这类连续量，若回放帧率低于录制帧率（比如录 120fps 回放 30fps），用线性插值补中间值，但键盘开关状态绝不能插值
网络同步游戏的回放要额外处理服务端权威逻辑
纯客户端回放能跑通单机 demo，但联机游戏里角色位置、伤害判定由服务端决定。只录客户端输入，回放时会因网络抖动、预测补偿失效而严重偏移。
容易踩的坑：sendto 发送的 UDP 包内容没记录；服务端没开启操作日志；回放时硬把客户端预测的位置当成真实位置渲染。
- 服务端必须记录每个 tick 的完整世界快照（含所有实体位置、血量、技能冷却），而不仅是输入 —— 这才是“可信回放”的基础
- 客户端录制时同步保存自己发送的输入包 + 服务端返回的确认包（含
server_tick和ack_sequence），用于对齐时间轴 - 回放播放器应优先加载服务端快照，客户端输入仅作参考；若需调试预测逻辑，才启用双轨模式（服务端轨迹 vs 客户端预测轨迹）
真正难的不是录和放，是怎么让回放里的“跳跃”看起来和当时一模一样——这要求你连浮点运算顺序、随机数种子、甚至编译器优化级别都得锁死。
