In the Multiplayer Programming Quick Start here
The declarations and definitions/implementations are as follows
Here StartFire is called locally whereas HandleFire is called on Server.
It is written in the docs that
If the user binds the “Fire” command to a scroll wheel or similarly inappropriate input, this function will still execute at an acceptable interval of time
But what if the Client(Hacker) changes the FireRate in the StartFire function locally? Can it happen(I guess yes)? How can we prevent that?
Should StartFire function be also called on server or should we check the time between consecutive calls to HandleFire on server, which might not be a good idea.
It would be really helpful if someone could actually show how these function should be implemented.
Yes it’s normally a good idea to validate client requests in the server code, to make sure the client isn’t doing anything too suspicious. Most tutorials don’t really cover this, as they’re more focused on teaching you how these kinds of systems typically work, than trying to create something that’s shippable.
How you want to handle this is up to you, but at a minimum I’d maintain some kind of weapon state on both the client and server side. If your weapon code sets a timer on the client to block you from firing again, it should also set that timer on the server to block you from firing again on the server if the server receives another request from a hacked client.
It’s also worth bearing in mind that due to latency, the client also doesn’t necessarily have a 100% accurate view of the world. Its view of other players in the world is just a little bit in the past, so typically games will give you a little bit of leeway if you said that you shot someone that is now behind a wall. “Favour the Shooter” is a very common approach that some of the most polished games take when it comes to making games feel good/fair over the internet (Overwatch for example, follows this rule).
A more polished implementation might take account of the fact that there’s some variable level of latency between the client and server, and let the client take a shot slightly early if it seems reasonable that they were following the rules, given their last recorded ping at the time of firing. Imagine the initial packet containing the fire message was delayed significantly, but then the next fire message that gets sent after that doesn’t get delayed that much. It’s conceivable that the server might block a valid fire message then, because it set its fire timer quite late. I wouldn’t worry about that initially though, it’s just something to bear in mind.
So yes, it’s definitely a good idea not to put too much trust in information that’s coming from a client, as that client could have been modified, or the user could be running cheat software. Just don’t be too strict about checking clients if you want your game to feel good, it’s a compromise.
1 Like
