> Stock Minecraft Server hardly tries to prevent many of the hacks.

It would require stuff like server-side chunk culling, which doesn't jibe with the way Minecraft is designed. However, there's nothing stopping a new game from being designed like that.

I named Minecraft because it's fundamentally flawed for server-side anti-cheat (you're limited by a client that requires a lot of theoretically-unnecessary information, and doesn't send enough requests for you to provide this lazily), and people manage to catch enough cheating to keep things fun for everyone else. If you control both the server and the client, you don't really have much of an excuse.

> However, there's nothing stopping a new game from being designed like that.

Modern games do network culling. UE4 supports it out of the box. The _millisecond_ that information is replicated to the client, (which has to be before the client views it on screen to allow for hardware latency), a cheat will have access to it and will be able to act on that information. Even if you have the fastest monitor known to man, and no rendering buffering there's 6ms before you can draw the player on screen, or 1ms to poll your mouse/gamepad, so the cheat wins.

So don't let clients react on information until 8ms after they get it? If it's a game where you can't do that, collect probabilistic evidence on players until you have a lot of evidence that a player is cheating, and add them to the “we'll ban later, but let's mitigate the damage for now” list.

Cheating players are statistically distinguishable from really good non-cheating players most of the time – and when they're not, we're at the level of cheating where it's unlikely your anti-cheat will help, because they'd just fork out the €50 for cheating hardware.

> So don't let clients react on information until 8ms after they get it?

This just delays the problem by 8ms - you still have all the same problems, except you've introduced 8ms latency. The cheats are still perfectly accurate, and are responding to perfect information. If you could only delay the information to the cheat, then you wouldn't need to do any of this because you could reliably just boot out the cheaters.

> ollect probabilistic evidence on players until you have a lot of evidence that a player is cheating, and add them to the “we'll ban later, but let's mitigate the damage for now” list.

That's what anticheat providers already do already, and yet we still have that problem.

> We're at the level of cheating where it's unlikely your anti-cheat will help, because they'd just fork out the €50 for cheating hardware.

Hard disagree here.

1) if you have an algorithm which can statistally distinguish cheating players from non-cheating players enough of the time, I'm guessing you have an algorithm or model that you can point to that does that? Because as far as I'm aware, they _help_, but don't fix.

2) People aren't forking out for dedicated hardware to spoof mice en masee, but they _are_ forking out for kernel level cheats to bypass the userland detection.