calculating and saving latencies for multiplayer game

Question

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?

Answer 1

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.

Answer 2

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.