Hacker News Reader

Comment by hypercube33 | Hacker News Reader

Game clients need to have zero trust. there has never been a truly working anticheat that doesn't punish the user in some way.

Be it you can't game on Linux (steam deck) or if you have some specific software installed you're flagged as a cheater (autohotkey) or other dumb things.

That said even in some AAA games it feels like the game cheats anyway either intentionally or unintentionally (read about how modern warfare basically decides the outcome of an encounter before it happens to keep your k/d ratio close to 1)

View on HN

"Game clients need to have zero trust"

Good luck implementing anything fast this way.

Have you thought about a bit, what this means?

Only ever give the client what it can see?

With common real world ping times around 60 ms?

It would result in very slow shooters. Where you have to wait a bit to see what is around the corner after going there. Not that practical.

In my opinion most anti cheat is BS anyway and even if some gets banned, the main problem is, game companies seem happy with the solution of just selling new accounts to cheaters.

Your last paragraph is spot on. From a players perspective, more than one MMO I played clearly had bot/script problems that the devs always addressed publicly but never took the easiest and obvious solutions.

Hard to not see it - esp in smaller games - as the bots and cheaters providing too much revenue to cut out completely.

> It would result in very slow shooters. Where you have to wait a bit to see what is around the corner after going there. Not that practical.

I think ideally you'd send players only what they could possibly see before next the next packet comes in. If their ping is 60ms and the game's tickrate is 128Hz, each tick they'd be receiving everything visible from within 68ms walking/running/jumping/etc. of their position 60ms ago.

Could be combined with server-side behavior analysis to detect players seemingly using information their client was sent but they shouldn't have seen. Packets from the client of what they actually did in that 60ms should be half received by the server and half in flight to the server by that point, so the client can't retroactively lie.

Wouldn't eliminate the advantage of this kind of cheating entirely, but might make it small enough that for many current cheaters it no longer justifies the risk.

"I think ideally you'd send players only what they could possibly see before next the next packet comes in."

That still makes wallhacks possible if standing close to a corner.

And otherwise what you describe makes netcode way more complicated, than it already is. Resulting in a worse game experience.

I am annoyed by any lag or stuttering and find it immersion breaking.

> That still makes wallhacks possible if standing close to a corner.

That's what I'm thinking with the server-side behavior analysis to detect players seemingly using information their client was sent (in case they made a certain movement) but they shouldn't have actually seen (because they didn't make that movement). Though even without that, restricting wallhacks to corners that you could already almost immediately see around would already be a significant improvement.

> And otherwise what you describe makes netcode way more complicated, than it already is. Resulting in a worse game experience.

It's what I think is the ideal and would definitely take some work to implement in practice, but if implemented well I'd argue the measures would be invisible to players in almost all scenarios, and game experience would be superior to solutions that have rampant wallhackers and/or don't work on many machines due to invasive client-side anti-cheat.

Reply on news.ycombinator.com