# Sending state diffs (deltas) and unreliable connections

We're building a realtime multiplayer game, in which each player is responsible for reporting its state on every iteration of the game loop.

To minimize state data sending, we've come up with a system that will send only deltas (whatever state data that was changed).

This method however is flawed, since a lost packet will mean that other players will not receive the delta, making the game behave in an unexpected way.

For example:

Assume that state is comprised of: { positionX, positionY, health }

Frame 1  - positionX changed --> send a packet with positionX only.
Frame 2 - health changed // lost !
Frame 3 - positionY changed --> send a packet with positionY only.


// Other players don't know about health change.

How can one overcome this issue then? sending the entire data is not always feasible.

Even though you are sending data using UDP, you will still need to add in your own form of reliability to handle situations like this. UDP just gives you the flexibility to do what you want, rather than deal with the reliable but less flexible format of TCP communication. Confirmation messages, or acknowledgement packets of a sort should be used when receipt of information is necessary, otherwise your client has no way of knowing if the data it sent needs to be resent. For instance, if you send critical information, and dont see a response within a set period of time confirming the receipt of that data, resend it.

• Beat me to it. However, it should be noted that fairly volatile values, like position and other physics data, doesn't need to be guaranteed. Even on the off-chance that it's wrong on a given frame, it'll be fixed next frame anyways. Oct 28 '13 at 22:18
• Good point, this is seen most often in games when suddenly a character moves to a new location very rapidly (or teleports there all together). Most games handle it in a few different ways, but the goal is the same. The server simply updated the entity position, and your client is either immediately updating, or updating it with a very high delta time over a few frames.
– Evan
Oct 28 '13 at 22:22

You can also work around the problem by sending a full state update from the server to the clients, say every second. If a client did not receive a packet, it will behave incorrectly until it receives the full state update. Then it will be in sync again.

Many games use both UDP and TCP/IP for sending/receiving data and depending on how often the data is sent, different protocol is used.

For example:

UDP: positional updates, and anything else that could potentially be sent/received multiple times per second.

TCP/IP: inventory actions, spell/ability actions, (most user performed actions)

It really depends on the quantity of traffic of each item. If you find you are sending HP updates quite frequently then maybe they do need to be on UDP.

• TCP is generally not used for anything that requires real time precision because its ability to cause large lag spikes. Oct 29 '13 at 13:34
• It's good if you want to make sure that your packet gets there. Stuff like positional updates aren't good for that but if you want to make sure your user pressed a button at a specific time TCP handles all the error checking and other things that you would have to implement for UDP in order to avoid packet loss. Oct 29 '13 at 15:20
• Valid point; I'd just prefer to modify UDP. Oct 29 '13 at 18:43

If you read the Quake 3 source code review, he explains the networking model which is very similar to your design, but with a solution for the dropped packets.

Essentially, in your model you are sending deltas against the directly previous state. In the quake3 model, you send deltas against the last acknolwedged state from the peer.