Let's propose for a minute where we have a game using something like the Virtuix Omni. You track feet movement. You track the speed at which they run. Now, let's suppose we want to translate this into game movement and velocity relative to the speed the player is moving. Now, suppose the game is multiplayer. How can a server validate that the input is reasonable? Most architectures described often tell us to validate the input - but in this case we truly want the player to tell us how fast they're running.

How can I we ensure sane values and not some hacked "always turbo" device?

  • 3
    \$\begingroup\$ Pick a maximum pace and enforce it? ;) \$\endgroup\$
    – House
    Commented Jul 22, 2013 at 15:47
  • 1
    \$\begingroup\$ I don't think letting all the hackers run around as Usain Bolt is a great idea. ;) \$\endgroup\$ Commented Jul 22, 2013 at 15:49
  • \$\begingroup\$ I thought the standard way to handle this is to have the sever do all the calations and have the client pass along input. Doing anything else seems like too much trust of the client and it seems like a history analysis would break under connection issues. \$\endgroup\$ Commented Jul 22, 2013 at 16:10
  • \$\begingroup\$ @ClassicThunder There are some classes of processing that are too intensive to completely rely on the server for. Movement, in particular, responds very poorly and feels laggy if it isn't done client side. That's why movement is very often just spot-confirmed and verified out of band instead. \$\endgroup\$
    – user1430
    Commented Jul 22, 2013 at 16:50
  • \$\begingroup\$ Not to mention @ClassicThunder in this case we truly want the client it's movement while still clamping within human bounds and accuracy. \$\endgroup\$ Commented Jul 22, 2013 at 16:53

3 Answers 3


What you want to do is record everything. With that corpus data, you want to do two things:

  • Implement rapid-response validation that checks the input against known boundary conditions (for example, the top speed of a human is about 45 kilometers per hour over a short stretch) and situations you've identified as potentially malicious.

  • Build longer-term, slower-running reports that build up data about averages (for example, average player speeds, average clicks-per-minute, et cetera) and other statistics you can use to feed into your rapid-response verification.

The result of a verification test that concludes an action is potentially malicious should not necessarily be to ban the originator of the action. Instead you should increase a "cheat score" (which may decrease over time), such that users who hit a cheat score over a certain threshold are flagged for a more in-depth review (possibly by a human).

It's important to make these verification checks highly tunable, especially to correct situations where any long-running feedback loop has crept into the tests in a way that starts generating false positives for cheat score increases. You may also want to consider not verifying every action every player does all the time, but randomly selecting them or other distributing the processing to avoid wasting too much server CPU validating input instead of actually serving the game.

There isn't a hard-science answer to this problem, it's going to involve lots of iteration on your part and tweaking of fairly fuzzy variables. Having good metrics and good tunability is critical.

  • \$\begingroup\$ Excellent ideas! In my head, there was no way to validate perfectly but I knew there had to be a way to raise some red flags. Thanks for the tips and ideas. \$\endgroup\$ Commented Jul 23, 2013 at 14:54

Apart from logging the data and analyze it (either directly or after somebody flags another player as potential cheater), I would try to measure "imperfection" of data. Input generated by a bot/script is most likely flawless, with almost linear acceleration, while an actual persons acceleration and stopping most likely isn't.

Maybe you can gather some reference data of people that are moving on the device and use it to compare against the incoming data. Ideally in a level that is pretty linear and with a controllable pace.. something like an introduction or tutorial level.

Another idea to measure imperfection is to do a Fourier-Transform of the incoming data. A bot will most likely create rather clearly distinguishable peaks (same frequencies), while a human will have different speeds and a "noisier" frequency domain.

  • \$\begingroup\$ Tracking imperfection is a really good idea. \$\endgroup\$
    – user1430
    Commented Jul 22, 2013 at 17:25
  • \$\begingroup\$ If I were attempting to circumvent this, I would just scale my real inputs. Still a good idea to have this in the suite of other detection strategies. +1 \$\endgroup\$
    – House
    Commented Jul 22, 2013 at 17:46
  • \$\begingroup\$ Interesting - although, @Byte56 has managed to ruin it. ;) Even so, abnormally high transforms for long periods of time is probably a red flag so thanks for the idea. :) \$\endgroup\$ Commented Jul 23, 2013 at 14:54

The way how I see this you have 2 options:

  1. Define a rule / set of rules that state what is considered "reasonable input".
  2. Forget validation just accept what you're given and roll with it.

Surely the "speed the player is moving" is something you can "acquire" from all this data you are gathering or calculate in some way?

Without knowing more about your solution it's hard to be precise.

  • \$\begingroup\$ -1: option 2 is not an option, which is why this question was asked. The rest of the answer is hopelessly vague. \$\endgroup\$ Commented Jul 22, 2013 at 17:26
  • \$\begingroup\$ The question is vague so it requires a vague answer, it is imposible to be specific when given a vague context. Option 2 may be a valid option if you knew more about the scenario in question, we cannot tell that from the information given. \$\endgroup\$
    – War
    Commented Jul 22, 2013 at 21:21
  • \$\begingroup\$ @Wardy I don't think the question is vague (I'm bias) - I'm asking how you to detect hackers when input is subjective and from the user in a particular context. There is no solution here - this is a theoretical question. The above guys have nailed it. :) \$\endgroup\$ Commented Jul 23, 2013 at 14:53
  • \$\begingroup\$ Fair enough ... maybe just my interpretation of it was vague. when input is subjective though does that not mean there are by definition varying lines to be drawn around what is correct? That I consider vague ... maybe vague was the right choice of wording ... um ... obscured in some way? \$\endgroup\$
    – War
    Commented Jul 23, 2013 at 22:10
  • \$\begingroup\$ @Wardy That's exactly the issue at hand, Wardy. :) The idea of this question was try to find out WHAT that line is on a per individual case. \$\endgroup\$ Commented Jul 24, 2013 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .