Online Multiplayer - cheating w/ delta time movement

Question

I'm making a multiplayer game with basic linear movement and interpolation. I've read gabriel's article about client-side prediction and server reconciliation and have tried applying it to my own. My server is supposed to be authoritative, but I am worried clients can still exploit the system.

The system works like this:

1. the client sends timestamped input to the server at 60hz
2. the server runs at 30hz. Each tick it applies all the input since last tick and uses a time delta calculated from the client side input packets to determine movement (e.g. entity.x += message.delta * speed). The server then sends a timestamped state back to all clients.
3. the client receives a timed state from the server and applies the "authoritative" positions.

My concern is with step #2. Because player movement relies on the client's delta time, I'm afraid they can cheat by sending a "fake delta time" to the server and additionaly spam input messages quicker to make them move faster in-game. If I remove the delta time altogether, the game will appear "jumpy". How can I resolve this issue?

Answer 1

If you are relying on client information to calculate position, YES this can be cheated. =(

Since you didn't sent information about what kind of game is this and you didn't mention fixed timestep, I'm assuming you are doing some kind of FPS that doesn't require that every client, runs the same frame, at the same time.

I think a good solution is to use PING to sincronize position between server and client. I'll explain:

• Server needs to run without waiting for clients, he is authoritative.
• If needed, server can implement a controlled delay of 1, 2 or 3 frames (at 60fps, 1 frame = 16ms).
• Client should PING server to check latency between him and server.
• Client calculate his current position + N frames ahead using last control input. So he will predict his position and update locally.
• Client also needs to calculate other players position using same method (according to his own ping, no to them).

If latency is low (<100ms) and your players are not moving too fast, this method works great. With latency > 250ms or player is really fast, your prediction starts to jump from place to place.

Another solution would be to calculate at server the maximum distance this client can move from frame to frame, if it's higher than this, apply some anti-cheat measure.

Anyway, need more information!

Answer 2

If you treat each move message as a move unit, you don't need delta in this message at all. Whenever server receives a move message, apply it with a hardcoded delta (say 15ms in your case).

However this is still vulnerable to message "spam" hack. Such that a client can send double or triple the amount of move messages. If the server unconditionally handles them all, the player will get 2x/3x speed.

Server side check like maximum location delta involves RTT measurement. Eg, max_input_message = (RTT/2 + 1000.0) / SERVER_FRAME When RTT is high this check is very loose, and a cheater can try to manipulate the RTT ping to yield higher RTT.

Maybe you can try to model your message as full state snapshot, while you are still able to adapt the prediction/reconciliation/interpolation demonstrated in Gabriel's tutorial.