概念页
Godot 多人与 RPC
Godot Multiplayer & RPC
Godot 高层多人 API（ENet/WebSocket 等 peer + MultiplayerAPI）用 RPC 与场景多人生成降低手写包负担；底层仍可直接 UDP/TCP。同步理论（权威、预测、插值）见本库网络页——本页只讲引擎挂钩。
原理
- 低层：UDP/TCP/HTTP/WebSocket/WebRTC——灵活，状态同步全靠自己。
- 高层：MultiplayerPeer + RPC 注解/
rpc调用；可配置可靠/有序、调用对象（服务器/客户端/远程）。 - 场景树与
multiplayer_authority决定谁有权改节点；生成用 MultiplayerSpawner 等（以 stable 文档为准）。
应用
- 主机权威：客户端发输入 RPC，服务器模拟再广播状态。
- Web 导出常 WebSocket/WebRTC；桌面常用 ENet。
取舍与理论锚点
- 高层易用但控制粒度不如自定义协议——竞技顺畅度仍需 客户端预测与纠正重放 等。
- TCP 不适合实时动作同步的原因见 UDP 与游戏协议设计。
- Godot 物理非确定性 → 不要默认锁步物理；锁步见 确定性锁步同步。
- UE 对照：RPC + 生成 ≈ 复制图简化版；无内建同等 Iris/RepGraph，复杂项目要自研或插件。
参见
出处
相关页面
游戏开发多人网络游戏模型Multiplayer Networking Models多人游戏并不是共享同一份物理现实，而是每位玩家各自看到的近似。历史上主要两条路：对等锁步 (Peer-to-Peer Lockstep)（RTS 仍常用）与权威客户端/服务器 (Authoritative Client/Server)（动作/FPS 主流）；后者再叠加客户端预测、插值与延迟补偿，把延迟藏进体验里。游戏开发UDP 与游戏协议设计UDP & Game Protocol Design动作游戏的时间关键数据（输入、位姿、物理）只关心最新状态。TCP 的可靠有序流会在丢包时把头阻塞住；正确做法是游戏协议只走 UDP，自己做虚拟连接、按需可靠性与拥塞退避，并按数据类型选择「冗余重发」还是「直接丢弃旧包」。游戏开发客户端预测与纠正重放Client-Side Prediction & Reconciliation本地客户端立刻用与服务器相同的运动（及可选武器）代码根据输入推进自己的角色，消除操作往返延迟；服务器仍是权威。权威纠正到达时已是「过去」，客户端丢弃过期缓冲、回绕到纠正状态再重放未确认输入，得到与服务器一致的「现在」。游戏开发快照插值Snapshot Interpolation发送端按固定频率拍下世界（或相关子集）的快照，接收端不跑权威模拟，而是把渲染时刻拨回一小段，在缓冲里的两份快照之间插值，用额外延迟换平滑，并扛住抖动与偶发丢包。Source 的实体插值与 clinterp 是同一思想的产品化。游戏开发延迟补偿Lag Compensation服务器在执行玩家开火等用户命令前，把其他玩家（及必要状态）回拨到「该命令在客户端生成时」所对应的世界时刻——扣除包延迟与客户端视图插值——再做命中判定，然后恢复。这样玩家可以对着自己屏幕上看到的目标直接开火，而不必凭感觉提前量；代价是可能出现「拐角后仍被击中」等时间悖论。游戏开发确定性锁步同步Deterministic Lockstep锁步不同步物体状态，只同步驱动模拟的输入；各方从相同初态用相同固定步长推进。带宽与对象数量无关，但要求比特级确定性，且每人延迟受最慢输入到达时间约束，通常适合约 2–4 人。游戏开发 · UE5网络复制与 RPCNetwork Replication & RPCUE 采用服务器权威 (Server-Authoritative) 的客户端-服务器模型：游戏真正在服务器上进行，服务器把状态复制 (Replication) 给客户端，客户端通过远程过程调用 (Remote Procedure Call, RPC) 向服务器请求操作。开发者需要显式声明哪些 Actor、属性、函数要走网络，并借助所有权、网络角色、相关性、优先级控制“发给谁、发多少”。UE 5.8 提供通用复制系统、Replication Graph 和实验性的 Iris 三套复制系统。游戏开发快照压缩与增量编码Snapshot Compression & Delta Encoding提高快照率以降低插值延迟，必须把每快照比特打下来：有界量化、四元数「最小三分量」、静止省略，以及相对对端已确认基线的增量编码。Source 的 delta snapshot 与 ack 跟踪是同一家族的工程实现。