Why isn't server-side anticheat a possible solution? Cheats can spoof inputs purely through visual output as well, meaning there cannot be full trust client-side.
We're mostly talking about FPS here, you've got 2 main cheat categories: aimbots and esps (visibility hacks)
Esps are purely client side, they read actors from game's memory and draw a client side overlay. It's impossible to protect against these on the server. Even if you had perfect culling from the server (didn't send players behind walls for example) you'd still have semitransparent surfaces like foliage and smoke. There are people making good money in PUBG just making enemy textures that are easier to see. You need kernel anticheat to prevent the cheat reading the memory. Also you want to take screenshots periodically and detect overlays.
Aimbots in the olden days could be detected on the server because their movements were instant, precise, unnatural snaps. But these days cheat developers have wisened up. Again the best protection is to prevent the cheat from reading the games memory in the first place, some anticheats go as far as to try to prevent input from any artificial device (so the cheat can't create mouse movement)
There are also movement hacks, but I don't think that these are really common these days. You can detect protect against these on the server side
Just adding that occlusion only works with games that have simple geometry, 90 degree corners, straight corridors, enclosed areas and no large difference in elevation. So its useful in games like CS or Valorant, but will not work well in open games like Battlefield or Escape from Tarkov.
There's also DMA based cheats that will read memory with another computer which can then output an ESP overlay to a HDMI or DP merge box that will show both the game and overlay on your monitor. They can also do aimbot by adding mouse inputs to a device you connect your mouse.
Websites sell DMA cards and these other devices together.
Not an expert but I've done a little reading and basically the combination of real time actions and a network makes it intractable, you end up just having to trust the client on some things (or having to make trade offs like a client potentially not having the information needed to display the game state to the player, or choppy/unresponsive gameplay as a function of latency).
Any specific examples? I hear this said all the time and it's almost never true.
Movement, for example: many decide to just let clients be fully authoritative over their positions and then act shocked when teleport hacks drop. Just keep track of the player's max move speed server-side, continually validate, and flag if they consistently move faster than is possible according to the server. No one is ever saying you have to validate inputs server-side in lock step with zero client-side prediction whatsoever and enforce 200ms of input lag for all players.
It's not teleporting that's hard to deal with, it's aimbots and wall hacks. You have to trust the client with enemy position information that it shouldn't be able to see yet, and trust their shot position inputs.
Also, constantly flying around and teleporting is easy to catch, but using it in small bursts is very powerful and harder to catch.
>You have to trust the client with enemy position information that it shouldn't be able to see yet
That seems like something that would be solvable with location-style differential privacy. Report a number of plausible locations to the client small enough that it can efficiently anticipate them all, but large enough to prevent being able to auto-aim or wall hack. Run some bots or actual player movements recorded from other matches, originating from roughly the same point where you last saw the real opponent.
>constantly flying around and teleporting is easy to catch, but using it in small bursts is very powerful and harder to catch
Even small violations of continuity seem like they'd be observable server-side, no? I've not studied this, but presumably clients must be constantly phoning home with their position.
> That seems like something that would be solvable with location-style differential privacy. Report a number of plausible locations to the client small enough that it can efficiently anticipate them all, but large enough to prevent being able to auto-aim or wall hack. Run some bots or actual player movements recorded from other matches, originating from roughly the same point where you last saw the real opponent.
Has already been done in COD: Warzone. Varying levels of success, cheat developers end up heuristically eliminating fake players.
> Even small violations of continuity seem like they'd be observable server-side, no? I've not studied this, but presumably clients must be constantly phoning home with their position.
This issue usually is game/game-engine dependent and is achieved either by exploiting bugs or manipulating lag compensation. Not exactly a very common thing.
> Even small violations of continuity seem like they'd be observable server-side, no? I've not studied this, but presumably clients must be constantly phoning home with their position.
Jumps in position are not always illegal: network issues, quirks from physics-based forces, glitches in the game, are all very common and can all cause unexpected positions. Differentiating from bannable offenses is not easy. Yes, there's always heuristics you can use to narrow down possible issues, but you have a limited CPU budget: You need to be running multiple instances per machine, each updating 60 times a second, serving dozens of players, sending and receiving constant updates to and from all players 30-60 times a second, while simulating physics, large worlds, complex player states, and synchronizing the states of thousands of objects. It's tricky to get everything right and performant. And people will get extremely mad if you make a false positive.
> That seems like something that would be solvable with location-style differential privacy. Report a number of plausible locations to the client small enough that it can efficiently anticipate them all, but large enough to prevent being able to auto-aim or wall hack. Run some bots or actual player movements recorded from other matches, originating from roughly the same point where you last saw the real opponent.
But what is the client suppose to do when actually seeing the real position? At someone the waveform needs to collapse and reveal the real location. The only way to make the fake locations indistinguishable from the real ones is to make them a real enemy player from the client's point of view. But then you stumble across all these fake enemies that don't do anything? You could place them in unreachable positions so normal players wouldn't ever find them. But then the heuristics for checking if a client "knows" about the position is still quite fuzzy. Also, visuals aren't the only giveaway of an enemy location. Audio is also location based. Playing fake audio would be detrimental to normal players' experiences.
Having said that, the unreachable-fake-player technique is not bad, it can cut out some low hanging fruit. But it's only part of the equation of a robust anti-cheat solution. It's complex to implement and only gets you some cheaters.
A simple example is clock timing in chess, you have to trust the client about when it received and when it sent if you want to avoid treating everyone as a cheater and penalizing genuine latency.
If I remember right an anecdote from someone in the trenches was along these lines for a more complicated real time game, though I think the peer comments have the more typical types of problems. I looked for the thread I was reading this in but came up dry, sorry!
