Question

您可以从状态同步 (State Synchronization) 下拉菜单中选择可靠的差值压缩 (Reliable Delta Compressed) 或不可靠 (Unreliable)，对给定的“网络视图”(Network View) 启用“状态同步”(State Synchronization)。您必须使用观察数据 (Observed) 属性选择同步数据的类型。

Unity 可以同步“变换”(Transform)、“动画”(Animation)、“刚体”(Rigidbody) 和 MonoBehaviour 组件。

变换可通过存储位置、旋转和缩放进行序列化。父子化信息不在网络上传递。

动画使每个运行动画状态（即时间、重量、速度和启用的属性）序列化。

刚体使位置、旋转、速度和角速度序列化。

脚本调用 OnSerializeNetworkView() 函数。

可靠性和带宽

网络视图 (Network View) 当前支持两个可靠性等级：可靠的差值压缩 (Reliable Delta Compressed) 和不可靠 (Unreliable)。

它们各具有优缺点，游戏的具体细节将决定使用哪个最佳。

有关最小化带宽的附加信息，请参阅最小化带宽页面。

可靠的差值压缩 (Reliable Delta Compressed)

可靠的差值压缩 (Reliable Delta Compressed) 模式会自动将客户端最后收到的数据与当前状态比较。如果从最后一次更新起数据未更改，则不发送数据。但是，这些数据将按每个属性来进行比较。例如，如果变换 (Transform) 的位置变化但其旋转不变，那么只会在网络上发送其位置。只传输变化的数据来保存带宽。

Unity 通过重新发送直到确认接收来确保每个 UDP 数据包都可稳定送达。这意味着如果数据包丢失，只有重新发送丢失的数据包并已接收才会应用稍后发送的数据包。在此之前，所有后来的数据包都将在缓冲中保持等待状态。

不可靠 (Unreliable)

在不可靠 (Unreliable) 模式中，Unity 不检查是否已收到数据包就将其发送出去。这意味着 Unity 不知道收到哪条信息，所以只发送变化的数据并不安全 - 每次更新都会发送整个状态。

决定使用哪种方法

网络层使用不可靠的无序协议 UDP，但 UDP 可像 TCP 一样用于可靠地发送有序数据包。要执行此操作，Unity 在内部使用 ACK 和 NACK 控制数据包传输，以确保无数据包丢失。使用可靠有序数据包的缺点在于如果数据包丢失或延迟，数据包安全到达前一切都将停止。这可能会在出现明显的网络滞后时造成传输延迟。

当您知道每一帧数据总会变化时，不可靠传输就很实用了。例如，赛车游戏中，您几乎可以判定玩家的赛车始终在移动，所以丢失的数据包效果很快会被下一个数据包修复。

总之，您应该在快速频繁的更新比丢失数据包更重要的时候使用不可靠的发送。反之，当数据变化不频繁时，您可以使用可靠的差值压缩来保存带宽。

预测

服务器对世界坐标状态有完全权限，客户端只能根据从服务器收到的更新来更改游戏状态。但这存在一个问题，即因等待服务器响应而引起的延迟会影响游戏可玩性。例如，当玩家按下向前移动的键后，在收到服务器的更新状态之前他都不会移动。这种延迟取决于连接的等待时间，因此连接效果越差，控制系统越迟缓。

应对此情况的一个可能的解决方案是客户端预测 (Client-side Prediction)，即客户端可以利用几乎相同的内部模型来预测服务器的预期移动更新。因此玩家可立即响应输入，但服务器从最后一次更新可预见其位置。状态更新最终从服务器到达时，客户端会将其预测的内容和实际发生的情况作比较。这可能会不同，因为服务器可能知道更多有关玩家环境的信息，客户只知道自己需要知道的信息。预测时发生的错误会得到修正，而且如果不断修正错误，则效果会更加流畅，错误的影响也不太明显。

航位推算或插值/外插

将客户端预测基本原理应用于玩家对手是可行的。外插 (Extrapolation) 过程存储有关对手位置、速度和方向的最近的已知值并使用这些值来预测对手即将存在的位置。当正确位置的下一个状态更新最终到达时，客户状态端会使用这些准确信息进行更新，如果预测偏颇太大，可能会导致角色突然跳动。FPS 游戏中，玩家的角色会表现得漂移不定，所以此类预测成功几率有限。如果迟滞程度太高，当预测错误积聚时，对手会剧烈跳动。

插值可以在数据包在传输到客户的路途中丢失时使用。但这一般会引起 NPC 暂停移动，然后在新数据包最终到达时跳到最新的位置。通过延迟世界坐标状态一定量的时间（如 100 ms），然后在最后已知的位置和新位置之间插值，会使丢失数据包的两点之间的移动显得流畅。