• FEATURED

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

## Protect against movement cheating

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

3 replies to this topic

### #1rpiller  Members

Posted 09 January 2013 - 03:29 PM

I have players moving around in my networked game, and now it's time for some cheating prevention code. The game is a casual 2D MMO with no fighting or anything so things are pretty relaxed. Currently I send position/direction info to the server 4 times a second (every 250 ms). I have 2 ideas to prevent movement style cheating and curious if they are effective or any loopholes in them, or any others people can think of to protect against.

1) Check the distance between each position update. If > tolerance then ignore update and send back correction to old position. This one will make sure someone doesn't alter the position to be much farther apart than what is possible on the default client side moving at the rate defined in the client code.

2) Check the server time between position packets per client. If < 250ms then ignore and send correction of last known position to client. This one protects against someone sending small movement packets (to meet the first check requirements) but at a faster rate.

Am I missing anything?

### #2swiftcoder  Senior Moderators

Posted 09 January 2013 - 03:55 PM

This one protects against someone sending small movement packets (to meet the first check requirements) but at a faster rate.

It's simpler just to check distance/time in the first place, and threshold based on speed, not distance.

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #3bennettbugs  Members

Posted 09 January 2013 - 04:52 PM

When I implement some kind of cheating checking, I would look to see how far the player moves in an amount of time. Maybe distance/time, and if the value is greater than slightly faster than the max, then they are moving too fast. Or you could send in a packet what the player pushed and let the server handle it, which could greatly reduce cheating more than a distance/time ratio.

### #4ApochPiQ  Moderators

Posted 09 January 2013 - 05:27 PM

You need to handle three basic categories of cheating:

• Sending too few updates ("starvation")

• Sending too many updates ("flooding")

Starvation is tricky, because you want to only penalize clients who are trying to move without telling anyone about it. However, you don't want clients who are sitting still to send you 4 packets per second (or whatever) if you can avoid it. My general trick here is to send a "start/stop" message pair any time the player wants to begin or end movement. If the client claims it should be moving but starts missing required updates, lock them in place until they begin behaving again. This is also an effective anti-packet-loss solution if done carefully, since players whose connections drop will quickly come to a halt instead of just wandering away into infinite space.

Flooding is simple: if I see more than, say, 2 seconds worth of position reports from you within a 1 second period, I just boot your client entirely. There is no excuse for this and it helps avoid a class of Denial-of-Service attacks. If you want to do this right, rig it up so that your latency compensation code "knows" how bursty the client's connection has been recently. If you have a really smooth client that all the sudden starts spamming you position reports, kick the bastard ;-) The flip side of course is that you may easily get, say, 6 position updates in 1 second instead of 4 updates, due to network hiccups. So intelligent lenience can be a little tricky.

Forging is where it all gets messy, though. A common approach is to send commands from client to server, such as "move north at 1 m/s for 3 seconds" and then report your position along the way. This allows you to verify that the client is doing what it asked to do, and you can easily boot anyone who exceeds a tiny threshold of discrepancy from this planned path. Again, intelligent latency compensation can be complex, but is by no means hard to do if you think through all the edge cases on paper before writing your code.

Basically, for defense against forging, you have to follow a "promise/expectation" model. The client promises it's going to try to do X, and the server then carries on with the expectation that the client will do what it said. Any deviation and you get booted.

How difficult that really is depends on the complexity of your game simulation, but from the sound of it, that should be pretty easy to pull off in your case.

Wielder of the Sacred Wands

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.