No Stupid Questions

Doing anti cheat on the server can only check for symptoms of cheating.

Doing anti cheat on the client can check for tools, attack vectors and the actual method of cheating.

Every time you double your servers' cpu usage, you'll double your server cost as well. If it were cheap I bet more companies would actually consider doing this.

The ultimate server-side anti cheat would be running the online game like Stadia where the players basically stream the game, which is very expensive to run today but might be the norm in the far future.

Couldn’t the server just check what vision a player should have and not provide any other information to prevent wallhacks or maphacks?

Definitely not how that works. The server has no idea how to tell how the GPU on the client-side is rendering anything. The server is just doing server things, which definitely doesn't include data on the "vision" of each player. There's a lot less data being transferred than you assume here.

All of these are way easier to detect client-side, because client-side you can actually check the code that is running.

A server that checked all the code that is running would be a very, very slow game. Like imagine a chess game where it took five minutes for a move to register after making a move. Servers focus mostly on "player state" like, where are they, what direction are they looking, what direction are they moving, what buttons they are pressing, and a lot less on checking the code of the remote player. Once again, because checking literally every players code remotely would slow everything way the fuck down.

A lot of people in this thread are probably going to explain to you all the reasons why it's necessary to do anti-cheat on the client.

And they'll be correct that it's not really reasonable to expect a system where data is sent to the client only when it's needed to render (in order to prevent things like x-ray vision and such) to be performant. (At least not in the most common and general case today, but more on that later in the comment here.)

All that said, I very much believe that a lot of folks don't suffifiently consider alternatives to client-side anti-cheating rootkits.

And this is all going to be a hot take, so strap in.

First off, an option that I've heard of is to require the client to send not just data like "my avatar moved to location X,Y,Z and has this velocity in this direction and etc etc etc" but also exact, specific keyboard and mouse inputs with timestamps. Then the server can a) validate that the given inputs at exactly the reported times produce the same location and velocity (this may involve running a copy of some portion of the client code on the server) and b) do better heuristic analysis on the inputs to detect things like aimbots more accurately. That would take more CPU on the server side, but it would go a long way toward making client-side anti-cheat rootkits less necessary.

But aside from that if a tabletop boardgame brought out the worst folks who played it and made it easy to cheat to the point that the game had a bad reputation, that would reflect poorly on the game designers' ability to create fun games with mechanics that ensure everyone has fun, right?

So I have to wonder when a video game has either rampant problems with cheating or a draconian rootkit to lock down the client's whole computer, how is it that people don't ever consider that the video game designers should have put more thought into how to change the mechanics, incentives, or other design aspects of the game to avoid those issues.

A quick anecdote. There's an open source Minecraft clone called "Minetest". A handful of years ago, the developers announced they were adding client-side scripting to it. A lot of the players lost their absolute shit. "How can you encourage cheating like this?" And the developers were like "a) there are already scriptable clients in the wild modified by third parties so us not adding this feature won't solve anything and b) things like x-ray vision are better solved on the server by, for instance, not telling the client which nodes are ore nodes until one face of the node is exposed - there's already server-side scripting that can be used to do that." Unfortunately the very vocal anti-client-scripting crowd won that argument just by being really loud and pitching hissy fits and the client-side scripting the developers added ended up pretty useless. (And keep in mind this even keeps single-player games from accessing the features offered by the client-side scripting effort.) And again, scriptable clients already existed in the wild.

Now, it's really hard to come up with game design principles that would deincentivise all cheating in all genres of games. But just a few ideas:

• What if there was an FPS that just gave every player x-ray vision to level the playing field for everyone?
• What if you made scripting the client to make grinding or aim bots a feature rather than trying to prevent that, but required that all bots play only on bot-allowed servers? Even if that couldn't be perfectly enforced, I'd guess it would reduce the incentive to try to play unfairly with client scripting. (Plus if there's a built-in client scripting system that reports what it's doing, or for some architectural reason has to report what it's doing to the server, it's probably going to deincentivise hacked clients.)
• Not all game designs can get away with not sending data to the client until the client needs to render it to avoid x-ray hacks, but you could certainly design a (fun) game that did allow for some version of something close to that. A team v. team FPS game where the entire map is divided in half with a big opaque wall that disappears two minutes into the match whereafter basically has line of sight to everyone else for the rest of the match. You could not send player location data for the other team's players until the wall disappeared.
• Make the games player vs NPCs rather than players vs players and predefine the NPCs' paths.
• I mentioned the Minetest "don't tell the client which blocks are ore until a face is exposed" thing above.
• Maybe player rating systems? To where if a player is obviously cheating, other players can give that player a 1-star review. Enough of those and they get put on the naughty players' server.

(I'd list some more ideas here but it's 2:00am and I really should sleep. Lol. Maybe I'll see if I can come up with more tomorrow.)

Aside from that, I'll say that, for all the talk about how server-side anti-cheat can't really work well, I'd have to submit that... client-side anti-cheat doesn't really work that well either. Folks regularly find ways around it. And there are companies out there that make anti-cheat software that have started to tip their hand about how much it doesn't/can't work by partially giving up on making bulletproof client-side anti-cheat that works (because that's not that feasible), but by bringing lawsuits against people who break their client-side anti-cheat. (It's the same trick they pulled with DRM, at least in the U.S.. It's not really possible to make DRM secure against the user who has physical access to the machine on which the DRM scheme is being executed, so instead of making DRM that works, they made laws to criminalize the breaking of DRM.)

All in all, I wouldn't personally play any game that required a rootkit. Don't care how fun it is. That's just straight up a deal breaker for me. It's my computer, dammit!

(And, even if the client-side anti-cheat wasn't a rootkit per se, I still wouldn't use anything required any client-side anti-cheat.)

It's an interesting problem. If you render everything server side and just deliver a video stream to the client, like a GeForce now only tournament. That eliminates a lot of cheating vectors.

The issue then becomes ensuring you have equal latency to all the players. So no one person has an advantage. But you could add artificial latency in that circumstance.

There's no getting away from the fact that in a distributed network, ordering of events and ensuring simultaneousness is difficult. Peakers advantage is a real thing.

Server side rendering and streaming, advantages: people only see what they're supposed to see, the server has perfect registration of all activity.

Disadvantages: more latency for everyone, AI auto aiming is still an issue. Requires excellent networking for everyone

Because the client side is the side where cheating happens.

They usually use both. Client side and server side detection together.

The problem isn't the check itself usually, but rather latency. If you shoot a player on your screen you want immediate feedback (client side), instead of waiting for a roundtrip to the server until the blood spatters.

There have been shooters where the server decides if a bullet lands. So on your screen you hit the player and then they suddenly survived. So most shooters switched to: If the client thinks it hit, it hit. Which does lead on the receiving end to running behind a wall and still dying. Overall it feels better than the alternative though.

The whole topic is pretty much game networking, it's a balance between doing it correctly (server side, slow) and faking to get it close enough (client side, immediate, easier to cheat, unfair if the player is laggy).

Of course there are some server checks that are always easy: For example if a player teleports or moves around the map faster than possible? You can flag them for review or if it happens too often kick/ban them. As long as you're super careful about automatic bans (bugs exist).

Server receives "1" for "hit registered" as sent by "client". As a client I can shove 1s all day long, how will it safeguard that?

there's both