2
\$\begingroup\$

I am curious about the details of lag compensation in games. I have read a lot of articles about it, for example:

  1. Source Engine Multiplayer Networking

  2. Fast-Paced Multiplayer - Gabriel Gambetta

  3. How do Multiplayer Game[s] sync their state?

And I still have this question:

At the 1st link, the Valve developers give a formula to compute the time when the command should be executed:

Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation

But on the 3rd site, the author says that the client sends the Command Execution Time and the server does not need to use that complicated formula to calculate something that the client can give the server for free. I mean, the player will always send the correct info about Command Execution Time, so the server can believe him.

Which one is correct? Or are both suitable (for different situations)?

\$\endgroup\$
  • \$\begingroup\$ "the player will always send the correct info about Command Execution Time" - Are you sure? Could be a mechanic for cheating if the player could say "I was actually elsewhere when the bullet supposedly hit me". \$\endgroup\$ – Steve Smith Jan 22 at 14:41
1
\$\begingroup\$

As Steve Smith pointed out in the comment above:

"the player will always send the correct info about Command Execution Time" - Are you sure? Could be a mechanic for cheating if the player could say "I was actually elsewhere when the bullet supposedly hit me".

Let's say I'm a player interested in exploiting your system. If I know your server trusts the timestamp I send, and uses it to determine when to place my action in its reconstructed timeline of events, then I can use this to effectively send my inputs back in time!

Imagine I see an enemy zip out of cover, and I'm not quite quick enough on the draw to shoot them before they're out of sight again, so I click 3 frames / ~50 ms too late. That's fine. I have a little program running to intercept packets from the game and back-date my timestamps when I miss, so instead of telling the server I clicked after the player was out of sight, it reports that I clicked 3 frames earlier.

The server trusts this timestamp, rewinds the game state to three frames before my click, and verifies that a click at this (false) time would indeed be a killing shot, so it awards me the kill.

So I score a kill when, in a fair game, I'd have missed. I've successfully exploited the system to give myself an unfair advantage over players not using my back-dating tool.

So: if you want to close off any avenue to cheating you can find, follow the mantra "the client is in the hands of the enemy" and do not trust anything from a remote client that you could calculate yourself on a trusted device.

Or, if you choose to trust client-provided timestamps, just be aware that this is a vector for a hacker to exploit your system, and monitor accordingly to make sure this is not damaging the experience for players following the rules. If hackers start exploiting this and similar avenues en masse, you might need to push out a patch after the fact to restore your intended play experience, and deal with the player community reputation fallout that this can have.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.