Originally published at: Server admin stalks cheats | Boing Boing
…
3 Likes
I’ve been watching people play Rust on youtube. I’ve never played it myself, but the CDNBLOOD channel runs some servers and isn’t above using their admin privs to grief cheaters before banning them.
1 Like
Maybe it’s these?
Fixed it, sorry
4 Likes
Rust, the game, is incredibly hardcore and I just can’t muster the energy to give it a try.
In that way it’s much like Rust the programming language.
2 Likes
Watching that video was almost as entertaining as watching rust form.
2 Likes
Too bad that it’s usually impractical to partition the game information better.
i.e. if the game servers determine that a player can’t see another player who’s out of sight, behind a rock or sneaking up on them from behind, then don’t give that player’s computer that information. And why should the player’s computer have the information that another player is trying to snipe them?
It’s a lot harder to cheat if they just don’t have the information.
2 Likes
Reminds me of my days being a senior admin for a TF2 community. All I could do was ban people but I would watch people like a hawk, the global admins had additional powers like making hackers deal zero damage, self destruct, burst into flames, etc. Sadly when Valve pushed the matchmaking to prioritize their servers over private servers the community was unable to deal with hackers directly so I stopped playing
Yeah, that exponential increas in complexity with increasing players just makes it impractical for the server to do it. 
So, we work on the honor system. And, surprise, some people aren’t honerable.
WRT this type of video, these are a full up genera on youtube. There are thousands of videos like this for nearly every game with any kind of administration by players. I’ve been watching a guy named Comomo_10 who admins a bunch of Rust servers and he’s pretty funny.
Many games do something like this, but realities of networked games undermines how well it works as a anti-cheat feature.
The games I’m most familiar with are the Quake series, but the techniques were not unusual. The QuakeWorld and later servers used the same visibility data in the maps that was used to avoid drawing hidden parts of the map, to limit data send to the client, but the checks were deliberately more relaxed. For rendering it would try to only draw a surface that had at least some part visible, but for network updates you were sent anything in that visible area, and the visible areas directly adjacent to it. The intent of this extra data is that a player that has moved around a corner should not need to wait for their client to send that movement to the server, and for the server to respond with what they can now newly see, before they can show who is around the corner.
This was never really done for anti-cheat reasons, but to reduce network traffic, if your sending every client updates for every player, bullet, rocket, etc. then there is a chance that an update for something critical to that player will get delayed behind updates for things on the opposite end of the map.
A modern game with a big open map and not a lot of hallways and tunnels this becomes more about distance then specific position, further reducing the value as an anti-cheat tool.
What you’re describing is the difference between server-authoritative game engines and client-authoritative ones. Server-authoritative is always the preference from a security and revenue standpoint, but it isn’t technically possible for some game types. Most free-to-play mobile games, for example, are fully server-authoritative because their real-time elements are minimal so it’s straightforward to do. Server-authoritativeness is no guarantee of security though. Cheaters in those games still exist because you can spoof server traffic, execute man-in-the-middle attacks, repeat API calls, decode protobuf packets, etc. It’s a lot harder to cheat, but still possible.
Server-authoritative games are more difficult to write however, and not all game teams have the expertise and experience to do it. It also necessarily creates some limits on game design which a lot of teams aren’t willing to accept. There’s a lot more nuance here than can be covered in a BBS post, but the short answer is that you’re right, it’s better, but it’s not always practical.
3 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
