回滚网络的核心是确定性帧同步而非重放；需C++实现无状态、确定性、固定步进逻辑，禁用非确定性操作，统一浮点与容器行为，采用快照+差分压缩及帧级ACK机制确保跨平台一致性。
回滚网络的核心不是“重放”，而是“确定性帧同步”
游戏回滚（rollback netcode）本质是让所有客户端在本地预测输入、并用对方延迟到达的输入去修正画面——它不靠服务器权威帧，而靠所有客户端运行完全相同的模拟逻辑。C++ 实现的关键前提：你的游戏逻辑必须是stateless、deterministic、且帧步进严格受控（比如固定 60Hz tick()）。一旦用了浮点随机数、系统时间戳、未初始化内存或非确定性 STL 容器遍历顺序，回滚就会在几秒内彻底发散。
常见错误现象：player A 看到自己打中了，player B 看到没打中；本地画面突然跳变/倒退；两台机器跑同一段 replay 文件输出不同 final state。
- 禁用
std::rand()、std::time(nullptr)、std::chrono::high_resolution_clock::now()—— 改用带 seed 的std::mt19937，所有随机都从当前帧号 + 输入哈希派生 seed - 所有物理/碰撞/角色状态更新必须走整数或定点数运算；若必须用 float，统一用
/fp:strict（MSVC）或-ffloat-store -fno-fast-math（GCC/Clang），并确保所有平台编译选项一致 - 容器遍历顺序要稳定：避免
std::unordered_map直接 for-range；改用std::vector<:pair data>></:pair>+ 手动排序，或用 robin_hood::unordered_map（保证插入顺序迭代）
如何组织帧缓冲与输入延迟补偿
回滚不是等所有输入齐了再算，而是「永远多算 N 帧」，N 就是最大预估延迟（比如 3 帧 ≈ 50ms）。客户端一边渲染第 frame_idx，一边在后台持续模拟 frame_idx+1、frame_idx+2、frame_idx+3……直到收到对端更正的输入，再决定是否 rollback 并重播。
使用场景：格斗游戏（GGPO）、本地化联机（LAN over WAN）、低带宽移动设备。
立即学习“C++免费学习笔记（深入）”；
- 每个客户端维护两个输入缓冲区：
m_local_inputs[128]（自己每帧存一份）、m_remote_inputs[128]（从网络收来，带 timestamp 或 frame number） - 网络收包不直接应用，先按
frame_number插入m_remote_inputs，再检查是否缺失中间帧 —— 缺失就 hold 渲染，插值或 freeze；收到旧帧就丢弃（除非用于 rollback 校验） - 渲染帧号永远比模拟帧号慢
ROLLBACK_DEPTH（如 3），即：显示frame_100时，模拟已跑到frame_103；若此时收到frame_101的修正输入，就从frame_100状态快照开始重放101→102→103
快照 + 差分压缩才是实际可行的内存方案
每帧全量保存游戏 state（比如 10k 字节）撑不过 2 秒缓冲。真正在用的方案是：只存关键 state 的 delta，并用滚动快照锚定基准点。
性能影响：全量快照内存增长线性，delta 压缩后通常压到 100–400 字节/帧（取决于角色数和状态粒度）。
- 定义一个紧凑结构体
GameStateSnapshot，只含确定性数据：角色 x/y/vel/health/action，不含指针、临时变量、渲染相关字段 - 每
SNAPSHOT_INTERVAL = 30帧存一次完整快照；其余帧只存StateDelta（用 XOR 或简单字段 diff，比如{player_id, field_offset, new_value_bytes}） - 回滚时，先定位最近完整快照，再按序应用 delta 到目标帧 —— 不要试图从头 replay 所有帧
网络层必须暴露「帧确认」和「丢包反馈」能力
UDP 不可靠，但回滚不能靠 TCP 重传 —— 那会彻底破坏实时性。你需要轻量级的帧级 ACK 和显式丢包通知，让对端知道“你漏了 frame_201，别等了，直接用 frame_200 的输入预测”。
容易踩的坑：只发不收 ACK 导致无限等待；ACK 包本身丢失 引发雪崩式重传；用 packet ID 而不用 frame number，导致无法跨连接复用逻辑。
- 每个发送的 input 数据包带
frame_number和input_hash；接收方回一个极小 ACK 包，只含ack_frame_num和latest_received_frame_num - 本地每帧检查：若
current_frame - latest_received_frame_num > ROLLBACK_DEPTH * 2，主动触发一次「请求重传最近 3 帧」（用单独 control channel，不塞进主流） - 禁止在 UDP 包里放任何非确定性数据（如本地毫秒时间戳），所有时序逻辑必须基于双方协商的 frame clock
最麻烦的从来不是怎么写 rollback，而是怎么让两台 Windows 机器、一台 macOS、一台 Android 手机，在各自编译器和 libc 下，对同一组输入给出完全一致的浮点中间结果。这点不压住，后面全是无用功。
