Why is anti-cheat always client-side?

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