The Network Synchronization Challenge of Flight Simulators: UDP Interpolation and Interest Bubbles

Flight simulation is considered one of the toughest nuts to crack in multiplayer online gaming. This episode of Computerphile features an engineer who previously worked on flight simulator development, centering on one core question: when you and I are each sitting in front of our screens flying aircraft, what data does the system actually need to exchange so that we both see each other flying in the same sky?

The answer is far more complex than most people imagine.

Why Flight Simulators Are Much Harder Than Racing Games

If you're building a racing simulation, the problem is relatively simple. You only need to handle two coordinate axes, X and Y. The track has a limited range, so you set the origin at the center of the track and extend a few miles in every direction—that's enough. Train simulators are the same, essentially a 2D positional problem on a plane.

Aircraft are completely different. First, the Z axis can't be ignored—altitude is one of the most fundamental state variables of an aircraft. Second, an aircraft has three rotational axes: pitch, roll, and yaw. A race car can only steer left and right, but an aircraft can change its orientation across three dimensions simultaneously. What's more troublesome is that you need to synchronize not just position, but also velocity—a vector with X, Y, and Z components.

This leads to the first key mechanism of flight simulator network synchronization: velocity interpolation. Rather than sending precise coordinates every millisecond, you can use known velocity information to extrapolate the other player's position. If the last received position was X and the velocity is V, then after time T, the other player is most likely at X + V×T. This simple extrapolation can dramatically reduce the packet frequency needed—updates are only required when the other player deviates from the predicted position.

UDP and the Trade-offs of Unreliable Transmission

Flight simulator network synchronization is almost universally built on top of UDP. The reason is straightforward: position packets are being sent continuously, so occasionally losing one or two doesn't matter because the next packet arrives immediately. TCP's reliable transmission mechanisms actually introduce unnecessary latency and overhead in this high-frequency, small-packet scenario.

There's an elegant symmetric design here. The sender is also doing the same interpolation calculation: if, based on velocity and the last sent position, my current actual position is close enough to the predicted position, then just don't send the packet—because the receiver can calculate it themselves. Only when the aircraft begins turning or performing aggressive maneuvers does prediction fail and an update need to be sent.

But UDP means packet loss is the norm. The network has the right to simply drop these packets when under high load. Servers under heavy load also deprioritize sending, thinking "this person's position information isn't that important right now, send it later."

Each packet also carries a timestamp. If a packet arrives late, the receiver discovers "I've already processed this information" and simply discards it. This is also the root cause of players complaining about lag and "you're not where I see you."

The Essential Difference Between UDP and TCP: TCP (Transmission Control Protocol) provides a reliable, ordered data stream, guaranteeing complete data delivery through mechanisms like acknowledgment, retransmission, and congestion control—but at the cost of unpredictable latency. A single lost packet blocks delivery of all subsequent data (head-of-line blocking). UDP (User Datagram Protocol) is a "best-effort" transmission that guarantees neither arrival nor order, and has no congestion control. For aircraft position updates sent dozens of times per second, a lost old position packet is worthless—the next packet immediately brings a newer position, so retransmission is just wasted bandwidth. TCP's reliability mechanisms actually introduce extra latency by waiting for retransmissions, resulting in a worse experience. That's why flight simulators typically use a hybrid approach: high-frequency state like position and velocity goes over UDP, while one-time events like navigation light switches and weapon firing go over TCP or reliable UDP channels.

Interest Bubbles: Only Synchronize What You Need to Know

Coordinate precision is another thorny problem. Racing simulations only need the origin at the track center, but in a flight simulator, aircraft can fly in any direction. The more extreme case is simulations covering the entire Earth like Microsoft Flight Simulator—floating-point precision simply isn't enough.

The solution is a hybrid coordinate system: set up multiple local origins across the globe (say, London is one origin), and record offsets relative to a particular origin in packets, thereby achieving higher precision. Earth's curvature must also be factored in—mapping latitude/longitude to 3D space requires additional mathematical handling.

What truly demonstrates design wisdom is the "interest bubble" mechanism. You don't need to know the position of every aircraft in the world—only aircraft within a certain range around you need precise synchronization. Data inside the bubble is kept at high-frequency updates, while aircraft outside the bubble only need rough position estimates, or can even be represented by a single point on screen.

This range isn't fixed. For a World War I-style simulator, visibility might only be five to ten miles, so the bubble can be set very small. But modern air combat has beyond-visual-range weapons and radar that can scan forty to fifty miles, so the bubble must be very large, and the problem difficulty skyrockets accordingly.

This also explains how Level of Detail (LOD) design works in conjunction with network synchronization: when aircraft are very close, even aileron positions, landing gear deployment, and navigation light switches need to be synchronized; at greater distances, only a rough position and heading are needed; even further, it degrades to a single point. One-time events like navigation light switches typically go over reliable channels like TCP, because they're state changes that can't be inferred through interpolation.

This mechanism actually mirrors the logic of real-world air traffic control. Controllers don't tell you the position of every aircraft around you—they just alert you: "There's an aircraft ahead crossing left to right, a thousand feet below you." The interest bubble does the same thing: filter out the information relevant to you, ignore the rest for now.

Floating-Point Precision and Coordinate Origins: 32-bit floating-point numbers have only about 7 significant decimal digits. When coordinate values reach millions of meters (e.g., global scale), two nearby positions may be rounded to the same float value, causing jitter or collision detection failures. Multi-origin schemes (similar to "floating origin") dynamically set a local origin near the player, and all coordinates are expressed relative to that origin, keeping values in a small range and maintaining precision. As the player moves, the origin shifts accordingly, recalculating relative coordinates for all entities when necessary. This technique is used not only in flight simulators but also in Microsoft Flight Simulator and space games like Star Citizen.

Latency Compensation and the Cost of Smooth Interpolation

When a new position suddenly arrives after a network interruption, jumping directly to the new coordinate would look very jarring. So clients typically perform smooth transitions—gradually interpolating from the old position to the new one.

But this smoothing has side effects. You sometimes see other aircraft rising up from the ground on the tarmac, precisely because the system thinks it "should be elsewhere" and then slowly moves it from the wrong position to the correct one, visually appearing as if it's emerging from underground.

As for whether to synchronize acceleration data, the answer is it's not worth it in most cases. Constant acceleration is extremely rare in real flight—pilots are constantly adjusting throttle and changing attitude, so the acceleration term is almost always changing. Combined with the inherent unreliability of the network, the predictive benefit of sending acceleration is very limited.

Space simulation is a different matter. Take Elite Dangerous, for example—distances between star systems are so vast they're measured in light-years. The game uses inter-system "jumps" to switch coordinate origins, cleverly sidestepping the precision problem of extremely large-scale coordinates.

If you want to implement a simplified multiplayer flight synchronization yourself, the starting point isn't complicated: maintain each entity's X, Y, Z position and three directional velocity components; each frame, extrapolate the new position by adding velocity times the time interval to the position; only send updates when the extrapolated result deviates from the actual by more than a threshold. From this minimal viable approach, you can progressively layer on interest bubbles, level of detail, reliable channels, and other mechanisms to build a basically usable multiplayer flight experience.

Level of Detail (LOD) and Network Synchronization Interaction: LOD is traditionally used for rendering, reducing polygon counts for distant objects. In network synchronization, LOD determines the frequency and content of state updates. Nearby aircraft need all movable parts synchronized—ailerons, landing gear, navigation lights—because players might be observing closely; at medium distance, only position and heading need to be synchronized; at far distance, even a single point suffices. This tiered strategy must be coordinated with interest bubble range: the larger the bubble radius, the more high-detail entities need to be processed, and the greater the computation and bandwidth pressure on servers and clients. In modern air combat simulations, radar can detect dozens of miles, and the bubble covers a wide area, but through the LOD mechanism, only a few nearby targets need high-detail synchronization, while distant targets can still be handled efficiently.