Networking: Smoothing and Prediction

Networking: Smoothing and Prediction

Home

Latency is the bane of networked simulations. Even simple data, such as a player's current position and velocity, suffer delays when sent (or resent) over the network. These status updates are the heartbeat of a networked simulation, because they are essential to providing smooth and realistic object animation.

To start, let's identify the most common update problems caused by network latency and errors, then we can discuss ways to avoid or reduce their effects:

Ghosting: Latency increases the distance between the apparent and the real position of an object.
Jumping: Periodic status updates are only discrete snapshots of an object's movement.
Stalling: Lost packets leave the simulation with no information on what the object is doing.

We see a kind of ghosting when we notice a jet flying overhead, but the sound of its engines seem to originate from far behind it. The distance between the apparent and the actual position of an object depends on the latency -- longer delays increase the effect.

The easy workaround for ghosting is simply to draw every object where it was at some point in the past, perhaps 100 milliseconds before (or some value based on the network latency). Unfortunately, users expect their inputs to have immediate effect; because they are actually observing past events, however, their controls will also seem to be delayed. Imagine trying to drive a car when the steering and pedals don't respond until well after you've applied them.

The real solution is not nearly as elegant or as substantial: put a hard limit on the latency, force objects to move slowly, and adjust the collision detection to compensate. A player will tolerate a bit of error as long as objects move smoothly and his controls are responsive when he needs them. Ruthlessly enforce a maximum 500ms latency (although 150ms is ideal) and limit the maximum speed at which the player can move. You will need to experiment with the settings to find a balance you find tolerable for your simulation, but these can greatly reduce the distance between an object and its ghost.

The next problem, jumping, is caused the intermittent nature of status updates, which provide discrete position data but do not describe the entire path of the object. While sending more packets would reduce the effect, it's not practical to flood the network and it still doesn't solve the problem.

A typical simulation updates the screen 30 times per second, but for practical reasons, it shouldn't send more than 5-8 status updates per second. The modeling layer calculates a path between the previous and the current position, called smoothing, so that the graphics layer can animate the object frame by frame in smaller steps than the networking provides.

Calculating a smooth path between discrete position data is rather easy: plot a cubic spline from the start to the end point, using the respective velocities to pick control points. It is then straightforward to calculate a location for each frame using a parametric equation.

Finally, modeling remote objects in real time requires a steady stream of update packets. Packet loss puts the simulation on uncertain ground: does it stop the action and wait for the information to arrive, or does it continue processing and fake the behavior for a while? While some applications must sacrifice responsiveness to provide accurate modeling, many players of "twitch" games will tolerate minor errors to avoid annoying pauses in the heat of battle.

Instead of stalling, the simulation should use whatever resources it has to predict the path the object will follow. Obviously, prediction depends very heavily on the data to be modeled. The most popular prediction technique, called "dead reckoning", assumes that an object will proceed along its current path at the current speed (as if no one controlled it). In fact, most simulations are modeled according to the laws of physics. Where driving simulators may rely on the conservation of momentum, other software can easily predict object paths using other Newtonian laws -- think pinball or golf.

In addition, the application can help the modeling layer predict by sharing any high level information it has about the object. Automated objects can advertise the entire path they plan to take (assuming a static map and no collisions), even before they start moving, so that every host can replicate the desired behavior without a barrage of incremental direction changes. This can be as simple as driving in a straight line until it reaches a certain location, or as complex as accessing the path finding or artificial intelligence module to better follow terrain features and avoids barriers.

To get real time performance, a simulation pumps data across the network as fast as possible. These are just some of the problems it must cope with to simulate smooth and continuous motion when information packets are slow or lost. Fortunately, these 3 problems are also simple enough that the basic features or limitations of the engine can offer dramatic improvements with a bit of coding and clever shortcuts. As we'll see in the next paper, however, there are some problems you simply can't code around.