Question

I am making a client server MMO style game. So far I have the framework set up so that the server and clients interact with each other in order to provide state updates. The server maintains the game state and periodically calculates the next state and then it every once in a while (every n milliseconds) it sends out the new state to all the clients. This new state is able to be viewed and reacted to on the client side by the user. These actions are then sent back to the server to be processed and sent out for the next update.

The obvious problem is that it takes time for these updates to travel between server and clients. If a client acts to attack an enemy, by the time that update has gotten back to the server, it’s very possible the server has progressed the game state far enough that the enemy is no longer in the same spot, and out of range.

In order to combat this problem, I have been trying to come up with a good solution. I have looked at the follow, and it has helped some, but not completely: Mutli Player Game synchronization. I already came to the conclusion that instead of just transmitting the current state of the game, I can transmit other information such as direction (or target position for AI movement) and speed. From this, I have part of what is needed to ‘guess’, on the client side, what the actual state is (as the server sees it) by progressing the game state n milliseconds into the future.

The problem is determining the amount of time to progress the state, because it will depend on the lag time between server and client, which could vary considerably. Also, should I progress the game state to what it would currently be when the client views it (i.e. only account for the time it took the update to get to the client) or should I progress it far enough so that when its response is sent back to the server, it will be the correct state by then (account for both to and from journey).

Any suggestions?

To reiterate:

1) What is the best way to calculate the amount of time between send and receive?

2) Should I progress the client side state far enough to count for the entire round trip, or just the time it takes to get the data from the server to the client?

EDIT: What I have come up with so far

Since I already have many packets going back and forth between the clients and server, I do not want to add to that traffic if I have to. Currently, the clients send status update packets (UDP) to the server ~150 milliseconds (only if something has changed), and then these are receive and processed by the server. Currently, the server sends no response to these packets.

To start off, I will have the clients attempt to estimate their lag time. I will default it to something like 50 to 100 milliseconds. I am proposing that about every 2 seconds (per client) the server will immediately respond to one of these packets, sending back the packet index in a special timing update packet. If the client receives the timing packet, it will use the index to calculate how long ago this packet was sent, and then use the time between packets as the new lag time.

This should keep the clients reasonably up to date on their lag, with out too much excess network traffic.

Sound acceptable, or is there a better way? This still doesn’t answer question two.

Answer 1

2) Should I progress the client side state far enough to count for the entire round trip, or just the time it takes to get the data from the server to the client?

Let’s assume that the server sends the state at time T0, the client sees it in time T1, the player reacts in time T2, and the server obtains their answer in time T3, and processes it instantly.
Here, the round trip delay is T1-T0 + T3-T2. In an ideal world, T0=T1 and T2=T3,
and the only delay between the observing time and the processing of the player’s action is the player’s reaction time, i.e., T2-T1.
In the real world it’s T3-T0.
So in order to simulate the ideal world you need to subtract the whole round trip delay:

T2-T1 = T3-T0 + (T1-T0 + T3-T2)

This means that a player on a slower network sees more advanced state the a player on a fast network.
However, this is no advantage for them, since it takes longer till their reaction gets processed.
Of course, it could get funny in case of two players sitting next to each other and using different speed networks.
But this is quite improbable scenario, isn’t it?

There’s a problem with the whole procedure:
You’re extrapolating in the future and this may lead to nonsensical situations.
Some of them, like diving into walls can be easily prevented, but those depending on player’s interaction can not.¹

Maybe you could turn your idea upside down:
Instead of forecasting, try to evaluate player’s action at the time T3 – (T1-T0 + T3-T2). If you determine that a character would be hit this way, reduce its hit points accordingly.
This may be easier and more realistic then the original idea, or it may be worse, or not applicable at all. Just an idea.

---

¹ Imagine two players running against each other.
According to the extrapolating they pass each other on the right side.
In fact, one of them changes their direction, and at the end they passes each other on the left side.