[burnished]

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).

[FactKnower69]

>some things

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.

[lifeformed]

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.

[tga_d]

>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.

[musjleman]

> 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.

[lifeformed]

> 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.

[burnished]

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!