DoctorWh012 / Client-Side-Prediction-Physics

Client Side Prediction With a RigidBody Movement System
MIT License
35 stars 4 forks source link

How to prevent cheating #3

Open Azengar opened 4 months ago

Azengar commented 4 months ago

Hi,

I've been implementing a similar system following different resources online and stumbled on your code.

The problem I notice in your code, that I also suffer from, is that if a cheating client is sending more inputs than 1 per tick, they could do gain infinite speed and do more actions (as many as they want).

I've struggled to solve this for a while and was wondering if you were aware about this and possibly knew a way to solve it?

Admitting that the server always knows about the client tickrate, or that the client tickrate is constant and perfectly stable, it would maybe be possible on the server to keep the time of the last valid tick and then estimate how many other ticks would be possible in that timeframe, but even then since clocks are not synchronized it might sometimes result in the server randomly dropping an input for a client that has a clock a little bit faster.

That's my only idea and it doesn't sound very promising practically.

Azengar commented 4 months ago

The only way I see is scrapping the Inputs sending and instead only send actions, e.g:

And so on..

You could then calculate with the average latency approximatively when the client pressed on their side and, in this case, find out the (mostly) correct duration and timeframe of the move forward.