CodeWhore.com
 Networking: Strategies for Beating Latency   Home 

Latency is the bane of networked simulations. The speed of a simulation is limited by the rate at which essential data can be communicated between hosts. Careful design can minimize the latency caused by bandwidth or packet forwarding, but data is still delayed by any journey over the network. We might be able to cope with the existing latency, but how can we expect to beat it? The answer is simple: reduce or eliminate data negotiated over the network, and you shortcut the latency entirely.

User interaction causes a continuous barrage of status updates and state changes -- animation must be smooth, collision detection fast and accurate. A simulation with good smoothing and prediction is affected by latency only when it it stalls waiting for a response from the authority. The most important optimization, then, is to recognize where player interaction would be impossible and design the authority model appropriately. Let's examine these shortcuts in 3 basic groups:

Whenever there are objects that can't interact with each other, take advantage of it: reduce the number of status updates and perform state changes locally. You don't need fast, frequent updates about players who aren't visible on the screen or on the radar. Similarly, hosts which don't interact with anything under local control simply won't request any resource arbitration or collision tests.

Players located in the same room (or city or solar system) interact closely with each other, but someone in a remote corner of the world is cut off from and independent of their gun battle. He only needs to be informed when a player dies or moves into another part of the simulation. Also, by dividing authority into zones, each host can act as the authority for his player's territory, which assumes that he will spend more time in his own area than in someone else's.

On the other hand, turn-based games allow each player to become the simulation authority for a short time while the others sit by passively. The active player can modify the game state without confirming each change over the network, only telling his peers enough for them to observe and animate his changes to the simulation.

Finally, some games don't require players to fight each other in the same arena or compete for the same resources. Instead, each player solves his own puzzles to earn the highest score or best elapsed time. Since there is no player-to-player interaction, there is no need for arbitration by a dedicated simulation authority. At the end of the game, players exchange a reliable message indicating their score or elapsed time, then choose a winner.

A good example of such a game is head-to-head Tetris. A split-screen display shows the progress of both players. Each host runs its own simulation, so that all gameplay is handled locally (not over the network). Meanwhile, each player sends his opponent a periodic status update about his stack of blocks and the currently dropping shape.

In this design, each player's controls are responsive and accurate regardless of latency, but the opponent's animation depends on the quality of the network and the smoothing algorithm. Fortunately, most players will tolerate some jerky or uneven animation because they only glance at the other side for a quick tension-building comparison between dropping blocks.

There are no hard and fast design rules for beating latency, only a handful of suggestions and shortcuts. Look for instances where a message is informative but not essential to gameplay, then design the simulation so that it doesn't block on it -- and suffer the latency of a full transaction.

That said, sometimes there are no shortcuts. Players that clump together in an action game still need to interact quickly and reliably, exchanging lots of status updates and state changes. In this case, the best you can hope for is better coping skills and techniques for hiding latency.

Copyright (c) 1999-2003 Matt Slot and Ambrosia Software, Inc.