企业官网建设流程全解析

Netcode for Entities 实战指南：3 步跑通预测回滚的 ECS 网络同步拆解

【免费下载链接】EntityComponentSystemSamples项目地址: https://gitcode.com/GitHub_Trending/en/EntityComponentSystemSamples

多人游戏里最劝退的体验：按下方向键，角色晚半拍才动；网络一抖，人直接被拽回原位。Netcode for Entities 就是冲着这套 ECS 网络同步痛点来的，把预测、回滚、Ghost 同步做成了可配置的组件和系统。

先搞懂 ECS 网络同步：Ghost 快照到底在同步什么

先拿快递打比方。服务器是发件仓，定期把货物打包寄出；客户端是收件人，手里永远是某个时刻的快照，不是实时画面。Ghost 快照就是那个包裹：只装打了标记的组件，没标记的字段本地改一万遍，别人也看不见。

多人协作文档同理。你看到的是别人最后一次保存的版本，各人编辑区互不干扰，冲突留到保存时解决。同步的本质不是每帧广播一切，而是挑出值得寄的字段，定好寄给谁、按什么节奏寄。

说白了，服务器权威（Server Authoritative）就是：服务端持有最终裁决权，客户端负责表现。数据错了要不要紧、本机改动别人看不看见、带宽花得值不值——三件事想清楚，策略就选出来了。

四种策略怎么选，看这张表：

动手：3 步跑通最小可用的预测回滚

目标只有一个：让玩家移动不再卡。链路分三步，每步都有现成示例可抄。

第一步，采集输入。输入组件要标记成 AllPredicted 才会走预测流程。采集系统挂在 GhostInputSystemGroup 里，每帧只处理带本地玩家标记的实体。NetCube 的输入示例就是这个结构。

标注需要同步的输入组件，只需一个属性：

// 输入组件: 标记 AllPredicted 后才走预测流程 [GhostComponent(PrefabType = GhostPrefabType.AllPredicted)] public struct CubeInput : IInputComponentData { public int Horizontal; public int Vertical; }

第二步，客户端预测（Client Prediction）。不等服务器，收到输入立刻自己推进位置。玩家看到的是零延迟反馈，哪怕这个位置还是猜出来的。

第三步，服务端校验加回滚。服务器拿到输入重算一遍，下发权威值。客户端对比两边：一致就渲染，有偏差就在几帧内平滑拉回，绝不瞬移。

整条链路走一遍：

参数别硬编码，默认值都在作者面板烘焙。什么时候该动它们，看这里：

半径和余量要一起调，只改一个大概率会抖。

通信层：RPC 消息从定义到销毁的完整生命周期

RPC 在 ECS 里不是函数调用，是把消息搬进实体世界。生命周期就四段：定义、发出、接收、销毁。

定义阶段，给结构体实现 IRpcCommand 接口，字段就是消息体：

// 消息即结构体: 实现 IRpcCommand 就能被发送 public struct ChatMessage : IRpcCommand { public FixedString128Bytes Message; }

发出阶段，客户端新建实体，挂上消息组件和发送请求组件，经命令缓冲提交。HelloNetcode 的 RPC 示例把收发两端都写清楚了。接收阶段，服务端查询带接收请求组件的实体，从源连接字段知道是谁发的，再走业务逻辑。

定向还是广播，看这张表：

单独说一段：忘了 DestroyEntity 会怎样。消息实体不销毁，它就留在世界里，下一帧又被查询命中，同一条消息处理第二遍、第三遍。广播发两遍，计数器加两次。再往后，实体数持续上涨，内存和快照体积一起被拖垮。示例里每个处理分支后面都紧跟销毁，这不是样板，是纪律。

体验打磨：预测半径怎么调，画面才不抖不跳不穿模

一句话分工：预测管自己，往未来推；插值（Interpolation）管别人，在过去两个快照之间取平滑值。

预测半径决定谁值得被预测。半径内的实体切预测模式，超出半径加余量才切回插值。这个余量是防抖设计。没有它，卡在边界上的实体每帧在两种模式间横跳，画面直接抖。预测切换示例里进出判定用的是两个不同半径，就是为此。

过渡时长控制切换那一下的渐变，别设成 0。物理预测要单独配：预测循环有自己的步长和重建策略，第一步是否全量重建物理世界，直接决定第一帧的手感。别用默认值上线。

误差校正的触发条件，是权威值和预测值偏差超过可接受范围。玩家感知上，调好是轻微吸附，调砸是瞬移。

上线前必做：流量监控、分级压缩与反作弊兜底

先别急着上生产。顺序是：先监控，再压缩，最后兜底。

NetDebug 是运行时看网络的窗口，重点盯三类数：

重要性分三档，频率和精度跟着降：

自定义序列化只讲思路：别发整块数据，只发和预制体默认值的差。差值为零的字段一帧不占字节，大批量静态实体下带宽能省一大截。

反作弊兜底一条原则：服务端永远不信客户端。客户端上报的只是"我按了方向键"，不是"我到了那个位置"。速度、血量、拾取全部服务端重算，客户端的数值只做展示。模拟发现超速，按服务端结果校正并记日志，别指望客户端自觉。

⚠️ 避坑清单：Ghost 同步最常踩的 6 个陷阱

你大概率会踩到下面几个：

• Ghost 属性漏标— 字段本地改了、别人看不见，日志一切正常 — 上线前全局搜一遍结构体，逐个核对标记。
• RPC 实体不销毁— 消息实体越积越多，同一条被反复处理 — 处理完紧跟 DestroyEntity，别依赖运行时回收。
• 预测半径设太小— 边界附近模式反复切换，角色抖动 — 半径和余量一起加，过渡时长别设 0。
• FixedString 长度溢出— 超长内容被静默截断 — 按最坏情况预留长度，输入上限写死。
• ThinClient 组件残留— 瘦客户端留下不该存在的同步组件，内存白涨 — 进瘦客户端模式时按查询清一遍残留实体。
• 边界余量设 0— 实体在半径边缘来回横跳 — 余量要大于一次过渡内能移动的距离。

如果你正在做竞技或协作类多人项目，建议按 1 同步策略 → 2 预测回滚 → 3 RPC 通信的顺序落地，监控与反作弊最后补。

【免费下载链接】EntityComponentSystemSamples项目地址: https://gitcode.com/GitHub_Trending/en/EntityComponentSystemSamples