I ask this question for the sake of a friend of mine who’s in the testing phase of a game he’s designing in memory of Zombie Outbreak - his guns work fairly well, but they suffer from latency due to being coded mostly on a server-side basis.
To remedy this, I suggested he allow shots to be directed and hits to be checked client-side and simply have the server verify, but I’m inexperienced with FPS games and their relevant code, so I’d like to ask for some opinions: what are good ways to reduce cheating when working with hitscan-based projectiles? Can you simply perform a magnitude check, or should you verify the direction of the ray?
I suggest just casting a ray in front of camera to the target hit. It the ray cannot be casted then the person had wall hacks. Now to deal with silent aim, I suggest checking if the player hits to many headshots or body shots in the same place. If they hit more than 4 in a row the give them a warning. Then if they do it 4 more times, kick them. Then ban.
Having worked with guns before, I suggest that your friend render all bullets, bullet effects (such as blood) and whatnot on the client whenever the gun is fired, and have the server do the raycasting/damaging/etc.
To replicate the bullet for the other players, either:
Render a bullet on the server
or
Use an RemoteEvent to call :FireAllClients(), followed by bullet data (speed, size, direction, etc), so that all the clients can make a local copy of the bullet
One typical approach is to have the client do the shot raycast, and send a remote event to the server with information like origin point of the shot, ray direction, what part got hit, and the hit location, and relevant velocities (e.g. of shooter character and target character). Then, you have the server do some validation checks with reasonable tolerances for how much server and client should be in agreement based on typical latency, player movement speeds, etc.The server takes the data from the client, and decides if it represents a plausable/possible client state given the server state.
This type of validation is not precise, but it catches really obvious cheats like shooting through walls, and it’s less computationally intense that storing player location history and average ping times to reconstruct a more accurate estimate of what the shooter’s client would have been displaying at the time the shot was taken.
A good aimbot script will also add random noise and intentionally miss a percentage of shots to make it harder to detect. Identifying bots is a generally difficult problem, and not one you can really hope to solve without falsely identifying some of the best players as bots.
Solving this with a low false-positive rate generally requires collection of a lot of data for statistical analysis. If the bots are super-humanly good, there will be a bimodel distribution where they have their own bump at the high-skill end of the stats. Even still, you can have a few of the best legit players overlapping this area in stats and scores. So you need historical data too, to know if a player used to be mediocre, then suddenly got amazingly good. Or you need to flag all amazing players who are very low level as suspect, and try to observe them playing, or cross reference them against reports of cheating to see if they anyone sent chat screenshots of them admitting they are exploiting. All around, still a difficult problem even with a lot of data.
