多人网络游戏模型

多人游戏并不是共享同一份物理现实，而是每位玩家各自看到的近似。历史上主要两条路：对等锁步 (Peer-to-Peer Lockstep)（RTS 仍常用）与权威客户端/服务器 (Authoritative Client/Server)（动作/FPS 主流）；后者再叠加客户端预测、插值与延迟补偿，把延迟藏进体验里。

核心幻觉

从外面看，多个玩家似乎同处一个虚拟世界；从程序员视角，这是精心设计的错觉——每人基于本地时刻与视角看到的是近似状态。（What Every Programmer Needs To Know About Game Networking）

对等锁步

早期网游常做成全连接网格，各方交换命令而非完整状态，从同一初始状态推进相同回合（Age of Empires 等 RTS 的经典路径）。优点是带宽跟单位数量脱钩。代价是：

确定性极难保证，一点路径差就会整盘不同步；
必须等齐所有人的命令，延迟等于最慢玩家；
中途加入困难（要抓取可复现的中途检查点）。

（What Every Programmer Needs To Know About Game Networking；实现细节见确定性锁步同步）

客户端/服务器

Doom 的锁步在调制解调器互联网上几乎不可玩。Quake 改为 C/S：游戏真正只在服务器上存在，客户端像哑终端，发输入、收附近状态并插值。体验取决于本机到服务器的链路，而不是全场最慢的人；还可中途加入，人均带宽更低。（What Every Programmer Needs To Know About Game Networking）

Source 引擎沿用同一骨架：专用服务器权威模拟与规则；客户端发用户命令、收世界快照；服务器做压缩与滞后补偿，客户端做预测与插值。（Source Multiplayer Networking）

flowchart LR
  subgraph clients ["客户端"]
    C1["客户端 A"]
    C2["客户端 B"]
  end
  S["权威服务器"]
  C1 -->|"输入 / usercmd"| S
  C2 -->|"输入 / usercmd"| S
  S -->|"快照 / 状态"| C1
  S -->|"快照 / 状态"| C2

上图：客户端彼此不直接通信；服务器是唯一权威。

纯 C/S 的延迟问题

若客户端完全等待服务器回包再动，RTT 会直接变成操作手感（Quake 原版在高延迟 PPP 上体感极差）。现代 FPS 用客户端预测与纠正重放消除自己动作的延迟，用快照插值平滑别人，用延迟补偿让命中检测对齐「你看见的那个时刻」。（What Every Programmer Needs To Know About Game Networking；Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization）

选型取舍

模型	带宽	确定性	延迟特征	典型体裁
P2P 锁步	极低（只传输入）	必须比特级一致	等于最慢对端	RTS、部分格斗
权威 C/S + 快照	随对象数上升	不需要全场确定	取决于到服务器的 RTT	FPS、动作、大部分网游
C/S + 预测/补间/补偿	同上，可再压	本地与服务器运动代码尽量一致	本地操作近零感延迟	现代射击

反作弊要求下，不能让客户端自行申报「我现在的位置 / 我爆了谁的头」作为权威；服务器必须是「The Man」。（What Every Programmer Needs To Know About Game Networking；Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization）

与 UE5 的对应

UE 的服务器权威复制与 RPC、专用服务器、CMC/Mover 预测纠正，都是本页 C/S 模型在引擎里的落地：见网络复制与 RPC、专用服务器、角色移动组件与 Mover。