Comment by gjsman-1000 a day ago
- … but successfully, more or less, prevents most cheating attempts which would also make the game unplayable regardless.
For anyone saying “just do server side,” no, it’s physically impossible to stop all cheating that way until we have internet faster than human perception.
Fully agreeing with this. I think there are two different approaches when people think of "server side":
The first is "never trust the client", i.e. realtime validation and having the server be the sole authority on the current game state. This is the straightforward solution to think of for programmers, but it's also practically infeasible due to latency, etc.
But what the server could do is a "trust but verify" approach: accept data from the clients when they submit it, but have some background processes that can analyze the data for anomalies and, if too much of it was detected, trigger a ban.
The only problem I see with this approach is that cheaters might react by repeatedly making new accounts and playing as them until the verification process has caught up and bans the account.
Cheating would be more obvious - as cheaters would have to start over with a beginner character every time - but it could still be annoying.
So the problem of ban evasion would become even more important. And I don't really see how a purely server-side solution could work there.
Sure, but you could stop the most blatant wallhacks at least, but most times I see a video of a cheater, it's something stupid like that. It can't be that hard to do occlusion calculations server-side, right?
Don't let perfect be the enemy of good.
>It can't be that hard to do occlusion calculations server-side, right?
I think you already know the answer. Yes, it's bottlenecked by latency and jitter (of the laggiest player, no less), and in addition to that the maximum possible movement velocity makes it much much worse in fast paced games. It's been attempted a few times since at least late 90's, with predictable results.
In other words, complete server-side calculations are a fantasy. Besides, they won't even remotely make cheating impossible or even harder! Even complete hardware lockdown won't.
It can be rather difficult, mostly due to the occlusion calculations having to be conservative (must count visible things as visible, allowed to count invisible as visible, or things pop) and latency (must account for every possible position within max move speed * max latency, or things pop)
The naive raycast from player camera to other player would be fine for perf but may count partially visible as invisible, so its unacceptable. You'd have to raycast every pixel of the potentially visible player model to stay conservative. With movement + latency this expands to every pixel the player model could potentially occupy during your max latency period, and you need to consider the viewer moving too!
In practice this expands to a visibility test between two spheres with radius max_latency*max_movespeed + player_model_radius. Now, you could theoretically do a bunch of random raycasts between the spheres and get an answer that is right some of the time, but it would be a serious violation of our conservativeness criteria and the performance would get worse with more rays/better results. Also keep in mind that we need to do this for every single player/player pair a few dozen times per second, so it needs to be fast!
To do this, you need a dedicated data structure that maps volumes to other volumes visible from said volume. There are a few, and they are all non-trivial and/or slow to build well. (google for eg. potentially visible set, cell-portal graph + occlusion). You also trade performance for precision, and in practice you walls might become 'transparent' a bit too early. With all this being done, we can actually "do occlusion calculations server-side".
There's just one problem with this that I still don't know a solution for, namely precision. With fast players and imprecise conservative visibility, things you care about are going to count as visible pretty often, including stuff like enemies peeking from behind a corner (because they could have moved at full sprint for 100ms and the end of the wall is rounded away in your acceleration structure anyway) so all this complexity might not get you that much, particularly if your game is fast paced. You'd prevent some wallhacks but not the ones that really matter.
TLDR yes, it's actually hard and might not be good enough anyway
When it comes to cheating, perfect is the enemy of good. This is one of those rare cases where the phrase doesn’t hold.
The problem is that server-side occlusion is only a small piece of the puzzle. A naïve implementation means hundreds of thousands of raycasts per second, which doesn’t scale. Real engines rely on precomputed visibility sets, spatial partitioning, and still have to leak some data client-side for responsiveness.
Basically - the kernel level check is not laziness, but for unsolvable problems without huge compute costs or latency.
Fine, then let's not bother with anti-cheat at all, since an aimbot can work by just filming the screen and sending HID events over USB. Anti-cheat is like DRM: You have to make do with a compromise.
Hundreds of thousands of raycasts per second sounds doable to me, but couldn't you just use a GPU and some simplified level geometry? That ought to scale well enough. It's not free or perfect (knowing the position of a hand a cheat will be able to estimate where the head is anyway), but that's not the goal, right?
In a 2d game? Sure, no problem, all Dota types have them. In games like CS and Valorant? Yes, they already do that, they have maps with simple geometry so its possible. Games with open world geometry with buildings with windows etc? Will be almost useless to implement anyway. You need to avoid pop-in effects so positions needs to be sent 1-2m before they are visible, its what they do in cs/valorant but it doesn't really work with complex geometry.
I actually think this is one area where AI and statistics applied to player behavior are actually the right answer, similar to how they catch chess cheaters.
I've seen videos where cheats are particularly easy to detect if you are also cheating. I.e. when you have all the information, you can start to see players reacting to other players before they should be able to detect them. So it should be possible to build a repertoire of cheating examples and clean examples using high level players to catch a fair amount of cheating behavior. And while I understand that there are ways to mitigate this and its an arms race, the less obvious the cheats are, the less effective they are, almost by definition.
If someone is consistently reacting outside the range of normal human reaction times, they're cheating. If they randomize it enough to be within human range, well, mission accomplished, kind of.
If they're reacting to other players in impossible ways by avoiding them or aiming toward them before they can be seen with unusual precision or frequency, they're cheating.
A lot of complex game dynamics can be simplified to 2D vectors and it shouldn't be that computationally intensive to process.