Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are We Anti-Cheat Yet?

areweanticheatyet.com

Post reply on HN
Print view View original

41–50 of 197 posts

Re: Are We Anti-Cheat Yet?

#41

Post by mjevans »

psgdev wrote: post #37
mjevans wrote: post #2

I don't know enough about 'real time' netcode for games. However I have read several HN articles over the years so I've got at least a basic understanding. Why can't the servers distrust the clients? What should a 'client side anti cheat' actually prevent? The way I think I'd tackle such things is to have multiple copies of each character model moving in different locations and different ways. Such that trying to spy…

Sending copies of fake character data isn't a thing because there eventually has to be a flag that tells the client to not render that character that the client hack could simply read. It should be clear that servers already do not trust the client, they do many checks hence you don't see teleportation hacks in games like Counter strike or Valorant. There used to be cheats in the counter strike games like "nospread"…

There would be no such flag. The clients would cull the characters that are out of position. Yes that's some client load for the culling, but it's probably less overhead than 'anti cheat'.

The important reason I suggested MULTIPLE clones of a character and only forking new paths off of existing characters in the world is that it should eliminate any information oracle about which of those is the real character.

Re: Are We Anti-Cheat Yet?

#42

Post by dijit »

mjevans wrote: post #40
dijit wrote: post #26

Earlier quoted context omitted.

Delaying UI interaction until it has been verified by a server that runs at 20fps (60 is uncommon on servers unless theres no AI), with a RTT of 60 ms, means your hitmarker will take 110ms instead of 6ms if rendered locally. Apply that to every interaction that the server has to be authoritative about, movement, reloading. Your game will be unplayable. And if you want to combat aimbotting: your viewport and hit point…

Not delaying UI interaction; though conflict resolution (there are at least two involved clients, each with it's own lagged view of the other, and a server that knows it's own truth) might change the outcome of events. THAT is the part of multiplayer net code I know the least about, mostly because I don't think there is a perfect solution but I am not a subject expert on what works well as an approximation.

Then you have rollbacks and rubberbanding, and UI elements that fired which aren't valid once the physics interactions have resolved serverside.

Jt doesn't take much for people to feel like the UI is untrustworthy and “broken”.

No game wants to be a jank piece of ass, but theres no good solution here, believe me, we’ve tried.

Re: Are We Anti-Cheat Yet?

#43

Post by psgdev »

mjevans wrote: post #41
psgdev wrote: post #37

Earlier quoted context omitted.

Sending copies of fake character data isn't a thing because there eventually has to be a flag that tells the client to not render that character that the client hack could simply read. It should be clear that servers already do not trust the client, they do many checks hence you don't see teleportation hacks in games like Counter strike or Valorant. There used to be cheats in the counter strike games like "nospread"…

There would be no such flag. The clients would cull the characters that are out of position. Yes that's some client load for the culling, but it's probably less overhead than 'anti cheat'. The important reason I suggested MULTIPLE clones of a character and only forking new paths off of existing characters in the world is that it should eliminate any information oracle about which of those is the real character.

There is a high level of server load for this as well, not only placing these fake characters but making them move and act like real human players so they are believed and then culling them (server would cull them not the client to be clear because how would the client know to cull them without a flag?) only right before they are visible while taking account of lag (ping), interp, packet loss etc..

I definitely could see someone games doing this as a one-off to just catch specific cheaters they are suspicious of to confirm they are cheating (Many 3rd party anti-cheats in counter strike and the 1st party valorant anti-cheat do manual bans based on replay reviews) but also since they already do fog of war someone with wall hack seeing an enemy player pop in for 1 frame before disappearing would make it not effective on a wide scale.

Re: Are We Anti-Cheat Yet?

#44

Post by umbra07 »

qalmakka wrote: post #38

leaving aside that most anticheats are useless and constantly teetering on the thin line between legitimate software and malware, not enabling anti-cheat solutions that support Linux on Linux is really an asshole move that almost definitely stems from an unmotivated or ideological hostility to Linux in general (I'm specifically referring to Tim Sweeney here).

Another offender is Ubisoft, or more specifically the R6 Siege team. Battleye works perfectly fine on Linux - in fact, other Ubisoft teams have enabled Battleye-Linux support for their games (ex: For Honor) - but for whatever reason, the Siege team refuses to do so, even though it's one of the most upvoted issues on the bug tracker [1].

[1] https://r6fix.ubi.com/projects/RAINBOW6-SIEGE-LIVE/issues/LI...

Re: Are We Anti-Cheat Yet?

#46

Post by pyrale »

mjevans wrote: post #40
dijit wrote: post #26

Earlier quoted context omitted.

Delaying UI interaction until it has been verified by a server that runs at 20fps (60 is uncommon on servers unless theres no AI), with a RTT of 60 ms, means your hitmarker will take 110ms instead of 6ms if rendered locally. Apply that to every interaction that the server has to be authoritative about, movement, reloading. Your game will be unplayable. And if you want to combat aimbotting: your viewport and hit point…

Not delaying UI interaction; though conflict resolution (there are at least two involved clients, each with it's own lagged view of the other, and a server that knows it's own truth) might change the outcome of events. THAT is the part of multiplayer net code I know the least about, mostly because I don't think there is a perfect solution but I am not a subject expert on what works well as an approximation.

That is what early days path if exile chose to do, and players hated the rubberbanding. Nowadays everyone uses lockstep instead, because backtrack events feel worse than being blocked right when the issue happens.

Re: Are We Anti-Cheat Yet?

#48

Post by Ndymium »

ginko wrote: post #45

I don’t understand. Why would you actually want anti-cheat rootkits and spyware on linux?

You may have strong opinions on anti-cheat software and they may be correct, but it is required for playing certain online multi-player games, and people want to play those games on Linux too (especially the Steam Deck, I would presume). Ergo, people want anti-cheat software on Linux.

Re: Are We Anti-Cheat Yet?

#49

Post by BlueTemplar »

cdogl wrote: post #31
sadeshmukh wrote: post #22

Earlier quoted context omitted.

The only feasible solution is to have high-level players compete in physical tournaments or at verified centers, where the authenticity of the player is replaced with some authority. At a high enough level, there is no way to distinguish a really good player from a cheater.

Competitive games are unlikely to reach the market share necessary for a competitive gaming tournament if their casual scene is inundated with cheaters. Only a tiny handful of games even have a viable competitive scene.

But are cheaters even an issue in unpopular games that don't give out real money for tournaments ?

I have never seen cheaters being an issue (even the few times people set up tournaments with prizes), which makes me think that this might be limited to very few games (in very specific genres) ?

Re: Are We Anti-Cheat Yet?

#50

Post by hexomancer »

One thing I don't understand and I would really appreciate if someone could explain this to me.

Why do we need separate anti-cheat programs? Can't the operating systems simply have an option when creating a process that prevents all operations looking at the memory of the process (and maybe if such a process is about to be launched the user has to explicitly accept that by clicking a button)? Wouldn't that stop almost all the cheats without needing separate anti cheat programs, since I assume those programs have to use OS facilities to mess with the game anyway.

Post reply on HN