Hi, I'm working on a realtime multiplayer game.

I want to do movement prediction to compensate for network latency.

In order to do that, I need to know how much latency there is between players.

For instance, player 1 sends a message to player 2. How much time did it take for the message to be transmitted?

Player 2 could send back a response to player 1, and player 1 could know an approximation of the latency by

taking the total time and dividing by 2. That could be a good approximation or maybe not. If it takes more time

in one direction compared to the other, then that approximation is not good enough.

Are there other more accurate ways to estimate latency between players?

Thank you.

edit:

The game I'm working on is peer-to-peer, and some movement predictions will be accurate because some movements will follow a predefined sequence.

My game is a fighting game. Example of "easy-to-predict" movements: parabolic jump, throwing fireballs, special moves. That's why movement prediction will work well in some cases.

Timestamp the initial message, player 2 takes a diff and sends it back.

Yeah, but if player 2's clock is slightily different from player 1 (+- 100 ms), that wouldn't work, wouldn't it?

Why do you think you need uni-directional latency? Did you measure any actual problems with using bi-direction latency measurements, or are you just hypothesizing without any proof?

Just take half the average RTT.

Measuring uni-directional latency will otherwise require you to sychronize clocks. And periodically resynchronize them. There are protocols for this. Unsurprisingly, they rely on techniques like taking half the average RTT to estimate latency when doing the synchronization.

I don't know yet. If there are simple ways to get unidirectional latency, I will use it because it's closer to what I need.

Maybe half bi-direction latency will be acceptable if uni-directional latency measurement is too complex.

If there are simple ways to get unidirectional latency, I will use it because it's closer to what I need.

Simply, there are not.

There are complex methods to get it. There are expensive methods to get it. For example, you could synchronize two atomic clocks and move them to the different locations and use those to compare the difference each direction, including accounting for dilation of time as you moved the clocks from one place to another. Or you could determine the exact distances of fiber cable and distances of copper cable and the exact devices in the middle, then run though some complex equations.

Far easier is to just find the round trip and divide by two. This is close enough for most things.

Alright, I guess I will use half of total latency.

Short of shipping a precise GPS-based time source with each copy of your game, there's no good way to get one-way latency :-)

Note that what matters is that all players see the same events in the same sequence/order -- not the exact time at which they see the events. You need a monotonic clock for your simulation, but the clocks don't actually need to be exactly in sync, and trying to make them in sync is hard, and gives no extra value.

Note that what matters is that all players see the same events in the same sequence/order -- not the exact time at which they see the events. You need a monotonic clock for your simulation, but the clocks don't actually need to be exactly in sync, and trying to make them in sync is hard, and gives no extra value.

It depends on what sort of game you're making and what exactly you're trying to do with it. Motion prediction and other anti-lag features for fast-motion real-time gaming (which Abraham did say he was trying to do) do very much require knowing precise timestamps to do properly. Just knowing the order of events usually does not work well for this at all.

As for the original question, however, do note that for these sorts of calculations, it seems at first like you would want to know one-way latency, but really when you do the math it all comes down to round-trip-time for almost all of it anyway. The important point is not whether the client screen exactly matches the server's state at a given absolute time, but that the server's idea of when user input happens matches up with the same server state as what the the screen showed when the user made the action. If you predict-forward just based on the one-way latency, then the client screen will (theoretically) match up with the server state (to some impartial third-party), but when the user does an action, you still have the latency to send the action back to the server, and when the server receives it, its state will be different than what the user thought it was based on the screen image when they pressed the button, etc.

So you actually would want to predict a full round-trip-time ahead, so that what the user sees on the screen matches (as best it can) what the server state will be when their action finally makes it back to the server.

Also note, however, that the further you try to predict ahead, the more error you will inevitably have in your prediction, which is why a lot of networked games attempt to handle this other ways (or do it only partially this way, with other compensating measures as well). As just one example, you might want to take a look at the "Lag Compensation" section of https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking to see how the Source engine does it (which is basically to have the server look into the past instead of trying to have the client predict the future), etc..

It depends on what sort of game you're making and what exactly you're trying to do with it. Motion prediction and other anti-lag features for fast-motion real-time gaming (which Abraham did say he was trying to do) do very much require knowing precise timestamps to do properly.

Yes -- you need high resolution in time stamps. The highest resolution for most fixed-step engines is the physics step/tick count. Some engines (like Unreal) use variable step size, which is bad for physics stability, and also makes ticks happen at different times on different clients, so those engines need high-resolution time stamps in fractional seconds instead. I much recommend fixed tick size!

Trying to get the wall-clock-time to be the same for the same simulation-step-time for all players at the same time, adds no value, and requires expensive hardware. Not to mention that "same time" literally becomes relative at a global scale -- speed of light becomes a factor even in defining what "same time" means! Who's reference frame? All the lag compensation techniques are basically just ways to deal with this, although the real-observed delay is an order of magnitude higher than the speed-of-light best case.