UDP in X-Wing vs TIE Fighter (Networking for Games)

 (Note: this post was made for a Networking for Online Games course.  It is intended to describe one game's approach to networking, as well as the various advantages and disadvantages of using UDP or TCP.)

X-Wing vs TIE Fighter is a multiplayer space combat simulation game released in 1997.  The developers wanted to create an experience more complicated than a deathmatch that could be played over the internet.  This posed a series of significant technical challenges from the start:

1. The engine had not been designed for the Internet.
2. There was more data involved in simulating missions than in simulating deathmatches.
3. They were not able to use a dedicated server, relying instead on a peer-to-peer system.
4. There are latency and bandwidth issues to deal with over the Internet.

 The developers decided on a host-client system.  One player acts as host, processing input from the clients and dispatching game state data to the clients.  The clients send information about their inputs to the host, instead of changing the game state and sending information to other players.  The host-client model worries about synchronizing players with the host, instead of with every other player.

When dealing with synchronization problems, the developers found the system of recording and playing back user input on the host machine was not entirely reliable.  Inputs that could have different effects depending on the state of given variables could quickly result in diverging simulations depending upon when said variables were updated.  They attempted to fix up these types of bugs and implemented a system of detecting out-of-sync issues, resending the data that had diverged.  They also had the game store two copies of the world state.  One would represent the state based on the actions of each player, and the other would represent the currently available state.  The latter was based upon predictions of each player's actions and was the only state rendered to the screen.

Upon conducting some real testing over the Internet, the team discovered heavy latency issues, usually within the range of five to ten seconds but occasionally upwards of fifty seconds.  They quickly came to realize that TCP was not the correct protocol for their system.  It relies on a system of acknowledgements and will only accept data in the correct order.  This makes it a reliable, but ultimately slow, system to use for rapidly-exchanged game data.  They switched to using UDP but encountered dropped packets.  With every resent packet more bandwidth was consumed.  Their solution was to send a copy of the last packet with the current packet, making it more likely that the data would be delivered.

When dealing with lost connections, the team implemented a time-out feature.  Players whose connections worsened, sometimes to the level of only three or four packets in twenty seconds, would have their game stopped and resume only when the connection had been cleared.  The host would, if necessary, drop any player's input that took too far long to arrive and send out the game state information without it.  This was not usually the case, however, and the speed of the game would often depend upon the speed of the slowest connection.  This created an effect the team dubbed "star-field warping", wherein a player's position would suddenly jump from their predicted position to their actual position in the simulation due to lag.  To help smooth this effect over, the team implemented an algorithm to move players' ships from their current predicted position towards their last known position, resulting in a smoother, if less accurate, representation of the game state.

(Source: Gamasutra - The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter )