←back to thread

Anticheat Update Tracking

(not-matthias.github.io)
124 points not-matthias | 1 comments | 29 Jun 25 21:06 UTC | HN request time: 0.238s | source
Show context
varun_ch ◴[30 Jun 25 08:54 UTC] No.44420989[source]▶
Forgive my ignorance, but why don’t game developers put more effort into limiting the amount of data accessible to the client (restricting it only to what’s reasonably necessary)? For example, couldn’t more movement physics be validated or handled server side? Cheats might still be able to read some data from the game process, but ideally, they’d be limited to issuing inputs like any other player, based only on the same visible output everyone sees. Is it cost? Does this model just not align with how the client/server split looks in games?
replies(7): >>44421072 #>>44421118 #>>44421970 #>>44422049 #>>44424067 #>>44425711 #>>44427400 #
1. CJefferson ◴[30 Jun 25 11:29 UTC] No.44421970[source]▶
Making sure that movement is validated on the server really is a reasonable requirement.

There are two main issues:

1) You typically want to let player's machines have a little knowledge the player doesn't, because if they peak around a wall, they should see an enemy, without having to wait for a round-trip before getting the information of the enemy they can see. Games often give out too much of this kind of information, but that's because it is computationally hard to figure out if a player can "almost" see an enemy.

2) Aimbots are basically impossible to check for on the server -- you can play a cat+mouse game (and games do) of seeing if players are consistently too accurate (or more likely, consistently too mechanical), but it's very hard, and player-side anti-cheat is part of trying to control this.