this post was submitted on 14 Nov 2025
560 points (97.0% liked)
Linux Gaming
22067 readers
2437 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
WWW:
- Linux Gaming wiki
- Gaming on Linux
- ProtonDB
- Lutris
- PCGamingWiki
- LibreGameWiki
- Boiling Steam
- Phoronix
- Linux VR Adventures
Discord:
IRC:
Matrix:
Telegram:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm not a gaming dev, but a full-stack web dev; is it not common sense that data needs to be validated on the server side, not client? I don't really get why client-side "anti-cheat" is a thing, but may be missing something.
Not a game dev either but my guess would be the main reason is server performance/compute cost.
Any checks that are done on the client run on the users' hardware instead of the publisher having to pay for more/better servers and electricity.
I think the disconnect with most other types of developers stems from the respective goal hierarchies. In most fields of computing, correctness isn't just a high-value goal - it's a non-negotiable prerequisite. With online multiplayer games, one of your chief concerns is latency and it can make sense to trade some cheating for a decrease in lag. Especially if you have other ways of reducing cheating that don't cost you any server processing power.
Also, aren't many of the client side anti-cheat solutions reused in several games? If you're mainly checking that the player is running exactly the same client that you published, I imagine the development cost for anti-cheat is lower.
TLDR: Money. It's always money.
You can also just check 1 in every 10 or 100 player actions
I think you're wrong about one thing - it's not about compute cost, but about complexity of accounting for latency. You could check if the player can see the enemy they're claiming to have shot, but you really need to check if they feasibly could've seen the enemy on their computer at the time they sent the packet, and with them also having outdated information about where the enemy was.
The issue gets more complex the more complex the game logic is. Throw physics simulation into the mix and the server and clients can quickly diverge from small differences.
Ultimately, compensating for lag is convoluted, can still cause visible desync for clients (see people complaining about seeing their shots connect in CS2 without doing damage), and opens up potential issues with fake lag.
More casual games will often simply trust the client, since it's better for somebody to, say, fly around on an object that's not there for other players, than for a laggy player to be spazzing out and rubberbanding on their screen, unable to control their character.
Aimbots and esp is client side only.
hmmm I see; could not at least aimbots still be detected on the server side?
Not 100% no. And any evaluation method you do will either allow more cheaters or catch very good players. Not to say this isn't done because it totally is just that it's very far from perfect.
Hell I've heard of cases where some really good streamers had to be an a special list of people to not kick/ban from this kind of detection because they've repeatedly been falsely detected. If you aren't a streamer you will have a lot harder of a time to get unbanned though not just because you aren't famous but also because it's harder to prove your innocence.
I remember Valve placing honeypots that would be impossible for a honest player to see or reach, and banning in mass the players who fall for it after some time to avoid the adaptation of the cheaters. And that is a cheap yet effect way to clean the player base.
Other interesting strategy is to limit the client information available, of the character is not looking with a scope, the client doesn't need to know if there is another player far in that direction.
Probabilistic analysis is not the only way.
But I know that some strategies would demand major reworks or good planning from the development phase.
Honeypots are not an easy solution either though unless you only really do it as a one off thing. And to be worth it you have to allow those cheaters to continue for some time before banning. You shouldn't underestimate how adaptable cheats developers are.
Limiting information is easier said than done especially for circumstances that matters the most. And don't forget people can still hear others through walls.
Hello game, yes, I am indeed actually on the other side of the wall, now inside the enemy's base.