- cross-posted to:
- gaming@lemmy.zip
- cross-posted to:
- gaming@lemmy.zip
You must log in or register to comment.
Anticheat code belongs on the server, where the environment can be controlled and trusted.
You can never trust the client. Never.
One of the big problems is stuff that a server wouldn’t know is happening
A simple example is wallhacks in FPS games, if you can somehow get the client computer to not render walls properly, the player can see where everyone else is in the level.
You don’t need to mess with the game client here if you’re clever about it, you mess with the operating system and graphics drivers so that a signed binary can continue to connect and behaves entirely legitimately from the server’s perspective.
Of course there are mitigations we could come up with for this, but you’re just in a game of cat and mouse. If it was a solved problem, kernel level anti-cheat just wouldn’t be a thing for the most part. Yet it’s what the competitors demand in the top flight competitions, because there isn’t a better way to prevent a whole class of cheating.
To be clear, not defending it and I personally avoid games that use it, but I understand why it exists
This is definitely solvable, though. The server can only send the client location updates of players they should be able to see.
If someone tried to wall hack, they’d only see the last known location before line of sight was broken.
Giving the client that data at all is like playing Battleship side-by-side and telling the player not to look at the other board.
This is what I mean by mitigations
You could definitely hide far players, but as soon as a player is near enough they could be seen, particularly when dealing with humans making unpredictable input, that player’s model will need to be placed in the world before either of them are supposed to see each other because the game has no way of knowing what that unpredictable input might be.
You can’t have every permutation of a given player model being obscured by every possible combination of angles of scenery as distinct models in the GPU memory, so something client side will need to do that slicing, so a player’s obscured origin location will need to be known by the client. This could give a player seconds of time to react depending on their opponent’s strategy
A few milliseconds is the only advantage a player needs at the top level of these games to shift the balance in a given contest. And given the prizes for some of these tournaments is multiple millions, there’s definitely the motivation to go to these seemingly extreme lengths
But the server is the authority on player location. It can tell if a player is visible to another because it knows their locations (as well as any obfuscations) at any given instant. It doesn’t need to know what they’re going to do next until it gets that next input from the client.
Obviously calculating this requires more work on the server’s part, but in smaller competitive matches this is totally doable. We’re talking basic wireframe vectors.
Can’t stop aimbots and wallhacks server side.
I always thought a good way to handle a huge swath of cheating would be to see what the limits a real human could actually do, and if it’s impossible (like having a reaction speed faster than 2 miliseconds) it’s flagged. Though the one game I know for sure has done this also had a huge problem with false positives. I guess no one working on Planetside 2 thought you could ever kill 1000 people with a single grenade; despite it being a clusterfuck of an MMO with plenty of people getting stuck in a doorway for that to be entirely possible and not even too hard to pull off.
And even that wouldn’t necessarily stop wallhacks and aimbots.
Now a days, I am convinced the only way to really mitigate (and not even fully stop) cheating would be to have a human referee. Like CS’s Overwatch program. And you might also need it to use an AI agent to analyze everything for pattern recognition because it can be really easy to hide cheating from actual people.
Wall hacks, yes. See my other comment:
This is definitely solvable, though. The server can only send the client location updates of players they should be able to see.
If someone tried to wall hack, they’d only see the last known location before line of sight was broken.
Giving the client that data at all is like playing Battleship side-by-side and telling the player not to look at the other board.
Aimbots are much more complicated, because the client is the authority on player inputs. Even things like latency and mouse movement can be subtly randomized by cheats to appear less robotic.
This always grinds my gears. When I was hosting custom Minecraft servers back in 2011 we had so many server side anti cheat measures in place. Prevented people from moving too fast. Randomized blocks until you exposed them so xray wouldn’t work. Logblock to identify griefers and do immediate rollbacks.
I remember this one time we had a group get on and grief someone that didn’t set up a claim yet and they thought they were so sneaky by distributing the loot amongst friends and chests. We just followed the stacks in the logs and restored everything then banned them. We actually had more people end up joining because how much auditing we could do, they probably felt like they could invest time into the server.
Now it’s like just trust the clients for everything and “oh we can’t ban them until the next ban wave because we don’t want them to know how we caught them”. It’s lazy. Back in the pubg days I remember seeing someone get 75 kills in a matter of 3 minutes. They didn’t get banned. They didn’t even have line of sight. Ban waves still allow peoples experiences to be compromised.
Thank you for you work back then. Probably made many happy. o7
The traditional rationale, back in the time of the boomer shooters, is that the server doesn’t have enough computational power to update and control the game state for all clients at once, with acceptable latency.
Now modern servers could dedicate each player their own CPU thread (except for maybe big battle royale servers).
But it would still be more expensive, and still have a latency issue.
Imagine a public counterstrike server where there’s an extra 30-50 ms delay between when you hit the strafe key and when you start moving.
Alternatively, Counterstrike or another shooter could defeat wall hacks if the server only told the client about player positions in the client’s line of sight. But then the Counterstrike player executing a peek would see their opponent pop in 30-50 ms after they gain line of sight. Much Counterstrike gameplay is built upon the short interval between when you see someone, and when you click on their head with your hit scan weapon.
Furthermore, latency is not going to go away for Internet play. The speed of light travel time to circumnavigate earth is 125 ms. That gives a theoretical worst case minimum ping of 62.5. Actual pings I see from my ISP are approaching the speed of light order of magnitude, assuming they are only traversing North America.
Good guy Embark StudiosHow can some anticheats work only under SteamOS?
The developers that go this route (for example, the makers of Infinity Nikki) explicitly check whether the hardware is a Steam Deck or compatible, and refuse to run if not. That way they can claim to support Steam Decks while blocking Linux players, which they still consider as too much of a cheating vector to allow at all.
This still allows running linux cheats on Steam Deck.
Or even better, I’m sure it is possible to spoof hardware on Linux since it’s open.
You can absolutely configure Linux to spoof the hardware it reports to a program.
Cheaters will do anything but actually get good at the game.
Linux players, which they still consider as too much of a cheating vector to allow at all.
But… why?
Linux is a secure operating system, windows is not. Making kernel level anti-cheat for Linux is difficult, and should be functionally impossible; as kernel level anticheat is absolutely no different than malware in its attack vector on the kernel. This means, for lazy dev teams, they can’t implement the laziest possible method of anticheat, which they get upset about since they have lost all ability to actually have anti-cheat teams.
Linux makes a kernel-mode anti-cheat (that is, an application able to have above-administrator permissions and supervise all the device’s actions) more difficult to implement than on Windows.
Starcraft 2 works like a charm
It helps that StarCraft, while somewhat relying on speed, is much more about strategy, meta knowledge, and real-time adaptation when your plan isn’t working.
That’s not something you can easily script, even with LLMs. That’s why the bot players have to use cheats at higher difficulties, because decent players outsmart them pretty quickly.
For real? I’d be curious about how to get this running.
Lutris, install the blizzard battle thingy, then use that to install starcraft.
Nothing particularly fancy required
You don’t even need Lutris if you have Steam. You can install it directly through Steam by adding the Blizzard Launcher as a non-Steam game.
