Absolutely, do your best to ensure that you have checks on the server but sometimes you cannot, like say in the sword clanning community, they used linked swords which can be resized on the client and since .Touched replicates, you can basically reach farther with the weapon than others can, you can’t check it on server, so you need to do some kind of check on the client. No one likes having to deal with client security, but saying it’s useless is an opinion honestly and that is all it is.
Of course you can check this on the server. Do distance and timing checks on the server with reasonable margins of error and you’ll catch most of the exploiters already. How do you think any triple A competitive game that attempts to fight hackers does melee/bullet hit detection? They certainly don’t rely on client-sided detection since that can be completely circumvented if the hacker is sophisticated enough.
It’s not a matter of opinion, it’s a well-grounded technical argument. Every kind of behavior can be checked against on the server in some shape or form. Any kind of check you do on the client can be circumvented.
2 Likes
Whilst it is true that you can always bypass client-side detection/prevention measures, it is not true that there is no place for them. It’s definitely not an industry consensus that such measures are useless because nearly every competitive multiplayer game uses them (BattlEye, VAC, Vanguard) - though it’s definitely a point of debate about how effective these systems are. You can also see similar client-side protection in quite a few popular games like Jailbreak and Phantom Forces.
I think the questions you should frame any development security decision with is:
- (Most Importantly) is there any other way of detecting this behaviour except through the client?
- How long does it take me to implement this?
- How long would it take for a motivated attacker to bypass this?
Not all behaviours are detectable on the server - at least, not reasonably. We are constrained by limited server resources and access to internals. Some exploits would be far too expensive to detect compared to the gain you would get.
I’ll give you an example - Animation exploits. They’re annoying and leave a bad impression on your game, however they are not harmful to your gameplay. They are effectively undetectable on the server, unless you put significant amounts of work in fingerprinting animations (which is both development and computationally expensive). So, I’d argue that adding a few lines of code locally that detect non-whitelisted animation IDs is worth it. Yes - it can be bypassed, however it will eliminate most of the animation attacks from your game, and required minimal effort on your part.
Don’t get me wrong though - I don’t recommend client-side detection for anyone who is not experienced enough to already have a good grip on their client-server implementation.
1 Like
I’m arguing against the notion of spending significant amounts of time on client-side detection as the primary method to prevent exploiting. Adding client-side detection after you’ve made sure all of your important remote communication is secure on the server seems okay, but I don’t think most of the other people talking in this topic are thinking along the same lines as you are.
In addition to that I’m saying the “complete waste of time” against the traffic encryption part specifically. That’s totally different from logic checking against bad behavior client-side, which is actually functional.
2 Likes
You’re onto something I’ve thought of for a while - is client-side sanity checking actually security? Or should it fall under something else? That’s a discussion for another time though.
I totally agree with your assessment there - Base64 “encryption” (or more accurately encoding) is no security at all. Any “secure” system should be secure even if the entire codebase is readable and understood by an attacker, and anyone who uses such methods as the footing for the rest of their security posturing should expect it to fall through below their feet.
1 Like
I agree there might be other workarounds but distance checks don’t help because the exploiter can turn their sword into a ball-shape and increase the size barely which basically will attack anyone that touches the ball-shaped sword. I also agree that it’s not the best idea to only depend on client-side detection to stop exploiters.
The main point I was trying to get across is that you can make a check on the server that validates that the sword touch is legitimate. The detail here on how that would be implemented is not really interesting to discuss about, you just implement it when you implement it.
1 Like
That still wouldn’t matter, some exploits have a built-in function to fire .Touched events. But anyways, this was somewhat of an eye-opening conversation.
Again, it shouldn’t matter if they do that. Your check should live on the server. You would check on Touched that the logic is reasonably valid from the server’s perspective and the hit should be dealt.
1 Like
Checks that “live” on the server will result in issues regarding latency on the client and delayed attacks even more than normal.
This is why any good combat system will predict things on the client that claimed to have made the hit (directly modify health / show effects on the client on local hit), but have the server validate and then replicate the effects to other clients. 
Everything you point out are long-solved design problems. I recommend that you read up on how games outside Roblox approach this. I’ve personally implemented this in Roblox games as well such as in City of Rolantis - Roblox, hits appear instantly on your client and the server validates.
1 Like
Ah yes, possibly. That’s a pretty nice game by the way.
1 Like