Hello,
We experienced this exact situation in Paragon and Unreal Tournament. A common term for this sort of exploit is “speed hacking”.
We have added time discrepancy detection and resolution (aka speed hack protection) natively to CharacterMovementComponent to help protect against these types of exploits in CL2907678 in //UE4/Main, which is available on GitHub right now if you need it ASAP, or else it is included as a feature in the upcoming 4.12 engine release. You can quickly check if your current version of the engine has the required code by going to BaseGame.ini and looking for “bMovementTimeDiscrepancyDetection” variable - if you see it listed, you have it, otherwise you will need a newer version or integrate the changelist manually.
The following is an overview of how it works and what config variables you can use to tune the prevention to your specific project:
Detection works by the server comparing client ServerMove RPC timestamp deltas against the known server authoritative time delta since the last ServerMove RPC was received and keeping a running tally on this difference. When this time discrepancy reaches a configurable threshold we trigger detection and optionally resolution logic.
Resolution works by overriding future client ServerMove RPC delta times to server time and having a portion of those move deltas be used for “paying back” the stolen time (the total time discrepancy detected) until the time difference has equalized.
Time discrepancy protection is disabled by default, configurable options live in the GameNetworkManager - base values can be found in BaseGame.ini and can be overridden in your project-specific game config file. These options are the following:
-
bMovementTimeDiscrepancyDetection: Enable detection (triggers warning logs and resolution if enabled)
-
bMovementTimeDiscrepancyResolution: Enable resolution (correcting clients and making them pay back time)
-
MovementTimeDiscrepancyMaxTimeMargin: Maximum time client can be ahead before triggering detection/resolution
-
MovementTimeDiscrepancyMinTimeMargin: Maximum time client can be behind
-
MovementTimeDiscrepancyResolutionRate: Rate at which to “pay back” stolen time during resolution, defaults to 100%
-
MovementTimeDiscrepancyDriftAllowance: Accepted drift in clocks between client and server as a percent per second allowed (to help burst packet loss/performance hitches from triggering false positives)
-
bMovementTimeDiscrepancyForceCorrectionsDuringResolution: Whether to force client updates during resolution, needed for projects that have lenient movement error tolerances or ClientAuthorativePosition enabled
These settings will need to be tuned for your project and represent a starting point for the ongoing battle for online games that is cheat prevention.
Testing this logic out at a base level can be done without a cheat program using the slomo cvar on individual game clients, which is equivalent to what popular cheat programs effectively do. The new p.DebugTimeDiscrepancy cvar enables log spew of time discrepancy state on servers for help in tuning the above values to your project.
Please note that all of this is specifically for protecting against users moving too quickly and root motion happening too quickly. Any project-specific game logic outside of movement that users are able to exploit using these speed cheats will come down to making sure the “final say” is handled by the server, and is a much larger topic.
I hope this helps, thank you.