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
Explain something to me. It’s a multiplayer game anything that affects all players should be handled on the server side, not the client. So if I make a cheat it can only be installed client side, not server side.
So if my hypothetical cheat looks at object placement and any time I sees a small object approaching at a high velocity it can say “I’m going to assume that’s a bullet based on what the server told me about it.” Then my cheat would say “your character moves from here to here until the bullet passes by, then moves back. I will tell the server you moved to the left 20 inches in the blink of an eye then moved back”
This works because the server just trusts what it’s told in this example.
So there are two options here to resolve this. Either the server sets thresholds and denies any placement changes look like the Flash is playing rust, or the server evaluates suspicious placement changes later when the cpu load it’s under is lower. The first approach stops much of this instantly but is computationally expensive and could not scale well for lots of players. The second would work well enough. You need to catch cheaters but it’s doesn’t have to be within the same exact cpu cycle.
In either case, these work because the server is taught to look for something that shouldn’t be possible. The enforcement happens server side. The client doesn’t fucking matter.
There is zero reason to put anti cheat on the client side when it’s not a P2P instance. Target a few servers, not thousands of players.
Your head is in the right place, but your example is very wrong. First, unless it's a very slow projectile that's not how bullets work in games, second movement takes place in the server, to do so in the client is nuts. Client sends inputs, sever moves, gives back player location, client adapts. While waiting for a reply the client simulates the movement expected, but sometimes the server doesn't receive the package and so tells you you haven't actually moved and you teleport back.
What's usually not done is calculate vision cone, instead the server gives you everyone's position and you calculate whether you can see them on your GPU. Which is why if you can get access to the GPU pipeline you can tweak it so it shows you objects through walls. If you move the LoS calculation to the server you completely eliminate wallhacks, however that is very expensive to do (although ray tracing GPUs might provide a good approach in the future)
For the vast majority of games, it’s in between, because the latency if you waited for the server every frame you moved would be way too much.
It’s something like you have a local model of where everything is, and send updates to the server of where your local model says your character (and whatever else your inputs affect) are. The server receives that data, potentially validates it (server side anti cheat checking that your movement makes sense, similar to the OP post, for example), and then forwards that info to all players. The client side positions of everything are updated based on that info. Usually some interpolation is added to make things move more smoothly.
Yes I meant movement happens server side, which is why this example cheat couldnt work. it would be telling the server what to do, and the server could always say "no, fuck off, thats not something you were coded to be able to do". Sorry if I didnt convey that clearly.
I also understand the client has to draw things faster than the server can respond "okay, I moved you 12 inches to the left" so it guesses the outcome and if the server later responds with "denied, no teleportation in rust" it will just snap you back to the last position the server approved of.
My point is anticheat client side suggests bad code server side.
Yeah but this approach makes the game stutter and/or sluggish for everyone. Client side computation isn't just cheaper, it also ensures that you have a smooth gaming experience.
As someone else said, most games do a middle way here. Compute on client side. Verify on server side.
Yes but if you are verifying server side anyway, why do you need anti cheat client side?
Well, first off: Money. The more you verify, the more it costs you to run your game's servers.
But also because you cannot detect every kind of cheat via server side anti-cheat. How does a server detect if my flick-headshot (which won this crucial round) in counter strike was luck, or if I had help from a program running on my machine? Maybe it didn't even make me react faster, just nudged the cfosshair another few pixels to ensure the hit.
Of course you can run statistics, and can flag outliers. But it's no proof. If someone always cheats you won't catch them, while you will flag someone have a good day (or a friend playing on their machine).
This sounds like a super clever argument, until you think about the scale.
If the cost to host a game went up by 50% it probably wouldn't make it into an investor call. Its a small price. It could be 10x as much and still be completely affordable to many games companies.
How does the client detect that when running said cheat on another machine? It doesn't. The current solution isn't perfect either.
I think the one who's not thinking about the scale is you. As the server owner you pay (compute) for every additional player. This goes directly against the wish to have as many players as possible playing your game.
This discussion spun of from a company stating specifically they don't want to invest more into anti cheat solutions. And that's from a company which absolutely could afford it.
You make it sound like I said that, but I didn't. In fact I'm very much against kernel level anti cheat.
This is the sort of annoying pseudo-intellectual smarmyness that gets old quickly.
You point out that you pay for every additional player as if no one has ever thought of that or as if my initial comment didn't consider it and that's wild.
You're one step away from saying "every little bit adds up" as if my literal point wasnt that the cost of running servers is minimal to most games to the extent that multiplying them still wouldn't make them a dominant cost center.
You've literally made no arguments against anything I've said. You've just point out the obvious as if it were a point or wasn't considered in the comment you replied to.
This doesnt help your argument at all. That one company, that we both agree could afford it, didn't want to spend, absolutely does nothing to hurt my argument and is actually only you agreeing with one of the main tenants of what I'm saying.
I don't make it sound like you said that at all. I'm literally pointing out (as in, its my point that I brought up) that there are weaknesses in client side anti cheat as well, and that only pointing out differences and exaggerating their worth is disingenuous.
The client side anti cheat is a low effort hack that was good enough. Video game anti cheat devs are cheap as fuck because looking at client bits cost nothing compared to expensive machine learning pipelines that need to analyze all player performance. This is not a tech problem but a product/skill one.
You don't need machine learning for this we've had perfectly good server-side anti-cheat for a while now and none of it's been AI-based until recently. If we know the top speed the game should allow players to move any movement greater than that speed must be a cheat or lag, either way it shouldn't be allowed.
There's more to cheating than moving quickly.
Obviously. They gave one of a thousand examples. That doesnt mean their point is weak, it means they didn't have the will (reasonably) to make their comment 50000 characters long.
If you have a specific example that doesn't work to a reasonable extent, post that rather than this short, vauge retort.
It's a huge part of cheating though. Fast movement, auto aiming, and wall hacks are the three biggest problems in cheating and all three can be solved algorithmically, without resorting to AI which is inconsistent and processor intensive.
You check whether the movement is possible for the allowed speed in the game.
You count the hit to miss ratio per weapon and build up statistical averages, anybody using auto aiming is going to be consistently out of that average, obviously you do this with each weapon in the game separately, snipers are obviously going to have a better hit rate than LMGs.
Finally you don't send data for players that are out of sight. Wall hacks can't work if the client isn't given this information.
The great thing about all of these techniques is that it's method agnostic, it doesn't matter what method the cheaters are using to inject their cheats, because you're not looking for the injection, you're looking for the end result.
Battlefield 6 has kernel level anti-cheat and it's straight up doesn't work because the cheaters are always ahead of the game. It also doesn't help that the game is glitchy on its own.