飞行模拟器的网络同步难题：UDP插值与兴趣气泡

飞行模拟被称为多人在线游戏中最难啃的骨头之一。Computerphile 这期节目请到了一位曾参与飞行模拟器开发的工程师，围绕一个核心问题展开：当你和我各自坐在屏幕前驾驶飞机时，系统究竟需要交换哪些数据，才能让双方看到彼此在同一片天空中飞行？

答案比多数人想象的复杂得多。

为什么飞行模拟比赛车游戏难得多

如果做的是赛车模拟，问题相对简单。你只需要处理 X 和 Y 两个坐标轴，赛道范围有限，把原点设在赛道中心，向四周延伸几英里就够用了。火车模拟同理，基本上也是二维平面上的位置问题。

飞机完全不同。首先，Z 轴不可忽略——高度是飞机最核心的状态量之一。其次，飞机有三个旋转轴：俯仰（pitch）、滚转（roll）和偏航（yaw）。赛车只能左右转向，而飞机可以在三个维度上同时改变姿态。更麻烦的是，你需要同步的不仅是位置，还有速度——一个包含 X、Y、Z 三个方向分量的矢量。

这就引出了飞行模拟器网络同步的第一个关键机制：速度插值（interpolation）。与其每毫秒都在发送精确坐标，不如利用已知的速度信息来推算对方的位置。如果上一次收到的位置是 X，速度是 V，经过时间 T 后，对方大概率在 X + V×T 的位置。这个简单的推算可以大幅降低需要发送的数据包频率——只在对方偏离预测位置时才需要更新。

UDP 与不可靠传输的取舍

飞行模拟器的网络同步几乎都建立在 UDP 之上。原因很直接：位置数据包在持续不断地发送，偶尔丢一两个无所谓，因为下一个包马上就到。TCP 的可靠传输机制在这种高频小包场景下反而会引入不必要的延迟和开销。

这里有一个精妙的对称设计。发送端也在做同样的插值计算：如果根据速度和上次发送的位置推算，我当前的实际位置与预测位置足够接近，那就干脆不发这个包——因为接收端自己也能算出来。只有当飞机开始转弯或做剧烈机动时，预测失效，才需要发送更新。

但 UDP 意味着丢包是常态。网络在负载高时有权直接丢弃这些包。服务器在繁忙时也会降低发送优先级，觉得“这个人的位置信息暂时没那么重要，等下再发”。

每个数据包里还会附带时间戳。如果某个包姗姗来迟，接收端发现“这个信息我已经处理过了”，直接丢弃即可。这也是玩家抱怨延迟和“你不在我看到的位置”的根本原因。

UDP 与 TCP 的本质差异：TCP（传输控制协议）提供可靠、有序的数据流，通过确认重传、拥塞控制等机制保证数据完整到达，但代价是延迟不确定——一个包丢失会阻塞后续所有数据的交付（队头阻塞）。UDP（用户数据报协议）则是“尽力而为”的传输，不保证到达、不保证顺序，也没有拥塞控制。对于每秒发送数十次的飞机位置更新，一个丢失的旧位置包毫无价值——下一个包马上带来更新的位置，因此重传只是浪费带宽。TCP 的可靠机制反而会因等待重传而引入额外延迟，导致更糟的体验。所以飞行模拟器通常混合使用：位置、速度等高频状态走 UDP，而航行灯开关、武器发射等一次性事件走 TCP 或可靠 UDP 通道。

兴趣气泡：只同步你需要知道的信息

坐标精度是另一个棘手问题。赛车模拟把原点设在赛道中心就够了，但飞行模拟器里飞机可以飞向任何方向。更极端的情况是 Microsoft Flight Simulator 这类覆盖整个地球的模拟——浮点数的精度根本不够用。

解决方案是混合坐标系统：在全球范围内设置多个局部原点（比如伦敦是一个原点），数据包中记录相对于某个原点的偏移量，从而获得更高精度。地球曲率也必须纳入计算，经纬度映射到三维空间需要额外的数学处理。

真正体现设计智慧的是“兴趣气泡”机制。你不需要知道世界上每一架飞机的位置——只有进入你周围一定范围内的飞机才需要精确同步。气泡内的数据保持高频更新，气泡外的飞机只需要粗略的位置估计，甚至可以用一个点在屏幕上标示就够了。

这个范围不是固定的。做一战风格的模拟器时，能见度可能只有五到十英里，气泡就可以设得很小。但现代空战有超视距武器和能扫描四五十英里的雷达，气泡就必须撑得很大，问题难度随之飙升。

这也解释了细节层次（Level of Detail）设计如何与网络同步配合：飞机距离很近时，连副翼位置、起落架收放、航行灯开关都需要同步；距离拉远后，只需要一个大概的位置和航向；再远就退化成一个点。其中航行灯开关这类一次性事件，通常走 TCP 这样的可靠通道发送，因为它是无法通过插值推断的状态变化。

这套机制其实和现实中的空中交通管制逻辑如出一辙。管制员不会告诉你周围每一架飞机的位置，只会提醒你“前方有一架飞机从左向右通过，在你下方一千英尺”。兴趣气泡做的就是同样的事情：筛选出与你相关的信息，其余的暂时忽略。

浮点数精度与坐标原点：32 位浮点数只有约 7 位有效十进制数字。当坐标值达到数百万米时（如全球尺度），两个相近位置可能被舍入到同一个浮点值，导致抖动或碰撞检测失效。多原点方案（类似“浮动原点”）在玩家附近动态设置一个局部原点，所有坐标都相对于该原点表示，数值保持在较小范围内，精度得以维持。当玩家移动时，原点也随之平移，必要时重新计算所有实体的相对坐标。这种技术不仅用于飞行模拟，也用于《微软模拟飞行》和太空游戏如《星际公民》。

延迟补偿与平滑插值的代价

当网络中断后突然收到一个新位置，如果直接跳到新坐标，画面会非常突兀。所以客户端通常会做平滑过渡——从旧位置逐步插值到新位置。

但这种平滑也有副作用。你有时会在停机坪上看到其他飞机从地面里升起来，正是因为系统认为它“应该在别处”，然后把它从错误位置慢慢移动到正确位置，视觉上就像从地底下钻出来一样。

关于要不要同步加速度数据，答案是多数情况下不值得。恒定加速度在真实飞行中极为罕见——飞行员不断调整油门、改变姿态，加速度项几乎一直在变化，加上网络本身的不可靠性，发送加速度带来的预测收益非常有限。

太空模拟则是另一回事。以 Elite Dangerous 为例，星系之间的距离大到需要用光年来衡量，游戏采用星系间“跳跃”的方式切换坐标原点，巧妙地绕开了超大尺度坐标精度的问题。

如果要自己动手实现一个简化的多人飞行同步，起点并不复杂：维护每个实体的 X、Y、Z 位置和三个方向的速度分量；每帧用位置加上速度乘以时间间隔来推算新位置；只在推算结果与实际偏差超过阈值时发送更新。从这个最小可行方案出发，再逐步叠加兴趣气泡、细节层次、可靠通道等机制，就能构建出一个基本可用的多人飞行体验。

细节层次（LOD）与网络同步的联动：LOD 传统上用于渲染，减少远处物体的多边形数量。在网络同步中，LOD 决定状态更新的频率和内容。近处飞机需要同步副翼、起落架、航行灯等所有可动部件，因为玩家可能仔细观察；中距离仅同步位置和航向即可；远距离甚至只用一个点表示。这种分级策略需要与兴趣气泡范围协调：气泡半径越大，需要处理的高细节实体越多，服务器和客户端的计算、带宽压力也越大。现代空战模拟中，雷达可探测数十英里，气泡覆盖范围广，但通过 LOD 机制，只有少数近处目标需要高细节同步，远处目标仍可高效处理。