The point here is that the anticheat solution needs to be written for a specific operating system because it runs “outside” the game in a privileged way to try and detect cheating.
So they have anticheat on Windows, and their own consoles will have a different anticheat system that is specific for the console OS.
Running games on Linux via Proton is effectively an emulation or translation layer, and the Windows-specific anticheat is not going to work with that.
If Sony wanted to provide multiplayer support on Linux they’d also have to provide a native Linux implementation of the whole game, rather than relying on Proton, which sadly not many publishers are doing at all. So its technically quite understandable why this isn’t possible.
Now, personally I think client anticheat is garbage and they should not be depending on that as a solution anyway, but that’s a separate argument!
The issue isn’t that the ACs can’t work. It’s that they don’t run at the kernel level under linux and so some developers have concerns that the ACs wont be as secure.
Though given how things have been lately with MP games. You have to wonder if theyre even secure to begin with.
Isn’t there some way to design the multiplayer to not trust the client? Assume the client has aimbot and all can see through walls, etc. Design it with those things being expected instead of all this draconian pwn the user’s system nonsense.
Exactly, and that’s why I expressed the sentiment that client anticheat is a poor solution. If you really really want to stop cheating, you have to do it on the infrastructure that you as the game developer have guaranteed and trusted control over, and that is the server.
Primarily by not sending non-visible information and by detecting unrealistic/impossible motion. If the aimbot has to limit itself to what humans can do, it doesn’t really matter anymore.
It does matter though. If you program the aimbot to act as if they were the best human, the aimbot is still going to beat everyone else, same as if it was behaving unrealistically superhuman. But you can’t simply ban the best human from your game.
Then program some inconsistency into the aimbot. it’ll still win against everyone most of the time, still being a problem.
Manual review is always possible, but this requires a lot of people. And if someone really looks at the best players, they seem like an aimbot all the time.
Client-side scanning forces hackers to run the input through hardware, which increases the level of entry and investment necessary to start cheating. Of course everything is always avoidable, but it’s about reducing the amount of cheaters by detecting the lazy/stupid people. If you just don’t client-side scan at all, there will be a lot lot lot more cheaters. It’s about reducing the volume so much that the amount is not that bad anymore and can better be dealt with manually.
It’s about forcing cheat developers to spend time/money finding new ways to hide, reducing the value of trying to create cheats.
Of course there are privacy and security concerns. But client side detection in a limited manner does make sense.
Server side anticheat is mostly implemented in all popular games. An aimbot however can’t be detected on the server side, it could just be a user moving their mouse perfectly. There’s lots of client cheats like that, which is why clientside detection still makes sense.
You should read about statistics. An aim-bot will be consistently accurate, humans are not consistently accurate. If your aim-bot is purposefully inaccurate then it’s useless. Long story short, your cheating has to be indistinguishable from human, which is HARD to accomplish, and if you do you’ll lose 50% of the matches against other humans.
Not to mention a game with server side anti-cheat could purposefully send fake data, e.g. send a position for an “invisible” enemy, if you aim/fire to it you get tagged. It can do lots of similar stuff that would make the aim-bot less accurate than a human, e.g. every time an enemy enters line of sight add another enemy just outside of the frustum culling, or send an enemy behind a wall that has no visible parts. Cheaters will act on that information, regular users won’t. At that point the only way to bypass that is with external hardware that acts on the same information an actual user does (which also bypasses client side anti-cheat anyways), at that point you have a robot playing the game for you and losing 50% of the battles…
Mmn yeah. I described it as a translation layer also, which is more accutate, but I used The Bad Word because more people have an understanding of what an ‘emulator’ is in common usage and it felt appropriate in this context.
So are PlayStation consoles running Windows? FFS this is short sighted tying yourself to your competitor like that.
The point here is that the anticheat solution needs to be written for a specific operating system because it runs “outside” the game in a privileged way to try and detect cheating.
So they have anticheat on Windows, and their own consoles will have a different anticheat system that is specific for the console OS.
Running games on Linux via Proton is effectively an emulation or translation layer, and the Windows-specific anticheat is not going to work with that.
If Sony wanted to provide multiplayer support on Linux they’d also have to provide a native Linux implementation of the whole game, rather than relying on Proton, which sadly not many publishers are doing at all. So its technically quite understandable why this isn’t possible.
Now, personally I think client anticheat is garbage and they should not be depending on that as a solution anyway, but that’s a separate argument!
Except we have a few ACs that work with proton. battleye and EAC being the notable examples.
https://areweanticheatyet.com/
The issue isn’t that the ACs can’t work. It’s that they don’t run at the kernel level under linux and so some developers have concerns that the ACs wont be as secure.
Though given how things have been lately with MP games. You have to wonder if theyre even secure to begin with.
Isn’t there some way to design the multiplayer to not trust the client? Assume the client has aimbot and all can see through walls, etc. Design it with those things being expected instead of all this draconian pwn the user’s system nonsense.
Exactly, and that’s why I expressed the sentiment that client anticheat is a poor solution. If you really really want to stop cheating, you have to do it on the infrastructure that you as the game developer have guaranteed and trusted control over, and that is the server.
How do you suppose to block an aimbot on the server side?
Primarily by not sending non-visible information and by detecting unrealistic/impossible motion. If the aimbot has to limit itself to what humans can do, it doesn’t really matter anymore.
It does matter though. If you program the aimbot to act as if they were the best human, the aimbot is still going to beat everyone else, same as if it was behaving unrealistically superhuman. But you can’t simply ban the best human from your game.
No human has perfect consistency, and it’s always an option to manually review data if it’s questionable.
What good is client-side scanning, when you can just run the aimbot outside the client and send the inputs directly through hardware?
Then program some inconsistency into the aimbot. it’ll still win against everyone most of the time, still being a problem.
Manual review is always possible, but this requires a lot of people. And if someone really looks at the best players, they seem like an aimbot all the time.
Client-side scanning forces hackers to run the input through hardware, which increases the level of entry and investment necessary to start cheating. Of course everything is always avoidable, but it’s about reducing the amount of cheaters by detecting the lazy/stupid people. If you just don’t client-side scan at all, there will be a lot lot lot more cheaters. It’s about reducing the volume so much that the amount is not that bad anymore and can better be dealt with manually.
It’s about forcing cheat developers to spend time/money finding new ways to hide, reducing the value of trying to create cheats.
Of course there are privacy and security concerns. But client side detection in a limited manner does make sense.
Server-side anticheat is more complicated to implement, so companies go with the lazy ckient-side rootkit instead
Server side anticheat also requires trusted servers.
A lot of games are mostly P2P with minimal stuff actually happening on their own hardware.
Good point, I hadn’t thought about that
Server side anticheat is mostly implemented in all popular games. An aimbot however can’t be detected on the server side, it could just be a user moving their mouse perfectly. There’s lots of client cheats like that, which is why clientside detection still makes sense.
You should read about statistics. An aim-bot will be consistently accurate, humans are not consistently accurate. If your aim-bot is purposefully inaccurate then it’s useless. Long story short, your cheating has to be indistinguishable from human, which is HARD to accomplish, and if you do you’ll lose 50% of the matches against other humans.
Not to mention a game with server side anti-cheat could purposefully send fake data, e.g. send a position for an “invisible” enemy, if you aim/fire to it you get tagged. It can do lots of similar stuff that would make the aim-bot less accurate than a human, e.g. every time an enemy enters line of sight add another enemy just outside of the frustum culling, or send an enemy behind a wall that has no visible parts. Cheaters will act on that information, regular users won’t. At that point the only way to bypass that is with external hardware that acts on the same information an actual user does (which also bypasses client side anti-cheat anyways), at that point you have a robot playing the game for you and losing 50% of the battles…
Akshually, wine is not an emulator!
I’ll see myself out.
Mmn yeah. I described it as a translation layer also, which is more accutate, but I used The Bad Word because more people have an understanding of what an ‘emulator’ is in common usage and it felt appropriate in this context.
And… Wine stands for Wine Is Not an Emulator, too.
They’re running FreeBSD (Heavily modified).