# calculating and saving latencies for multiplayer game

i am making a simple multiplayer puzzle game which basically presents a group of connected users some simple questions and whoever answers first wins the game. but i am having some issue in designing this game. assuming there are two players A and B connected & player A submits answers before player B but player A has some network lag, the server thinks that player B submitted the result first so player B wins.W chich is not correct.

i thought of calculating latencies for each player and store it on the server in something like in-memory database redis.

so when any player submits their answer i can just minus the latency with the time when the game started. that way i can know which player actually won.

i was thinking to use fping program to get latencies every 2 seconds and store it. but the problem is when there are 1000 players playing simultaneously calculating ping times would take more time than 2 seconds( loop for every connected player then find their ping times & store them in db) so the next run to calculate ping time will be delayed.

How is this usually handled?am i going in wron direction?

• What would prevent a user from deliberately replying late to pings, so it looks like their network latency is greater than it really is, letting them effectively send their answers back in time to beat other players from the server's point of view, even if they were in fact slower? – DMGregory Sep 20 '18 at 15:31
• @DMGregory how is a deliberate late reply to pings possible(fping uses ICMP probing to get ping times & it will sit on the server side). this is my first multiplayer game so i am very confused. – anekix Sep 20 '18 at 15:35
• A ping is asking a remote computer to reply. That remote computer could be programmed to not reply right away. By assuming replies are immediate, you're trusting the client to respect the usual convention for ping replies, something a cheater might decide not to do. – DMGregory Sep 20 '18 at 15:37

I don't know of a way to correctly trace a user's reply back to the time it was sent without being vulnerable to cheating.

(eg. a cheater deliberately sends all their replies 100 ms later than normal so the server thinks their latency is realLatency + 100ms. Then when they send their answer without this extra delay, the server back-dates it to realAnswerTime - 100ms, letting them effectively send answers "back in time" to beat other users).

Instead, I'd recommend solving this problem with game design:

Take the maximum variance in communication latency you're willing to accept between players in one match. (ie. the maximum latency you consider playable, minus the minimum latency you expect to see) We'll use this number as a tuning parameter you can choose to make a wider or narrower window of opportunity for rival answers.

When an answer comes in, wait for that maximum allowed duration to see if other answers also arrive in that window.

If multiple correct answers come in within that window, call it a tie. You can decide whether a tie means multiple players win, or nobody wins, or the players split the victory in some way.

This window can still be quite short in terms of human perception of time (even fairly bad one-trip network latencies are on par with an eye blink) so most rounds should still have a decisive winner. And crediting multiple players with a tie is generally going to be preferable, in terms of perceived fairness, to crediting the wrong player with a win due to variability or manipulation of network timings.

Here's a few examples, assuming our window is a generous 200 ms.

First, anekix's scenario: (values in ms)

Player     Latency   Answer Time   Arrival Time    Vs Window
-----------------------------------------------------------------------
Player A      50        5000          5050       First (5050 + 200 = 5250)
Player B     100        7000          7100       Too Late (7100 > 5250)
Player C      50        8000          8050       Too Late (8050 > 5250)


Here, player A's correct answer came in way before the others, at 5050 ms. We hold the window of opportunity open for an extra 200 ms after this correct answer, but both the other player's answers arrive later than that window. So Player A takes a solo victory. Which makes sense - they were first by a margin we couldn't confuse with mere network latency.

Here's a tighter scenario:

Player     Latency   Answer Time   Arrival Time    Vs Window
-----------------------------------------------------------------------
Player A      50        5000          5050       First (5050 + 200 = 5250)
Player B     100        4960          5060       In Window (5160 < 5250)
Player C      50        5300          5350       Too Late (5350 > 5250)


Here, Player B actually answered first, but because they're on a higher-latency connection, we received Player A's answer sooner. Because the window of opportunity we chose is larger than the difference between the most and least-lagged player's latencies (200 > 100 - 50), we don't hand a solo win to Player A incorrectly. Instead, we deem the 10 ms difference in arrival times as "too close to call" and we say that player A and player B tied. Player C's answer arrived outside the window though, so they still lose the round.

For conditions where you expect players to be on very different network conditions, you'll want to allow a larger window. For conditions where you expect players to be more similar (eg. in the same room as with a Jackbox Party Pack game, or a group assembled by matchmaking that only pairs players with similar pings), you can use a smaller window to have fewer ties and more timinig precision for identifying solo winners.

You can playtest with a range of tuning values and play conditions to find the level that gives you the right perceived fairness.

• thanks for the detailed answer but can you slightly explain this in more detail "Take the maximum variance in communication latency you're willing to accept between players in one match." i read it multiple times but its not clicking in my mind – anekix Sep 20 '18 at 16:02
• This is a judgement call on your part. How many milliseconds would you deem is "too slow" to play a timing-sensitive game like yours? How many milliseconds would you deem as "the fastest I'd expect"? The difference between those two numbers gives you the longest delay you'd expect between receiving two answers that were made at the same instant of real time. You use this as a parameter to set how long a window of opportunity you allow for tied answers to come in. – DMGregory Sep 20 '18 at 16:06
• suppose tha max tim eallowed for answers is 7 secs(its a quiz game so users will have to think & type). and user A took 5 sec to answer but user B took 6 sec to answer but since he had a faster internethis response was recieved first. where as it should not be the case. am i overthinking something or i am mising out on some details? – anekix Sep 20 '18 at 16:35
• That's a 1000 millisecond difference between player B and player A. That would be an exceptionally long network delay. Myself, I would probably choose the window of opportunity to be a fifth to a tenth of that, even on the generous side. Remember, this window is the time between the first answer you receive and the last answer you'll agree to count as a tie, not the total time players have to think of their answers. – DMGregory Sep 20 '18 at 16:58
• i will try to write the flow as i understood(assuming the window opportunity of 200ms). 3 users joined a match===>user 1 sends the correct answer in 5 seconds===>user 2 sends the answers in 8 seconds. there is a gap of 3000ms which is more than the set window time(200ms).==> user 3 then took 7 seconds to answer & due to a network lag of 100ms , to the server it seemed 7.1 seconds. which users had draw in this case? – anekix Sep 20 '18 at 17:11

Use timestamps. Calculate how long it is between a user seeing an answer and when they answer it. Compare these times on the server. Could be prone to cheating though.

• exactly i was trying to avoid cheating – anekix Sep 20 '18 at 15:36