[banachtarski]

Humans can and do in fact do all the things you suggest. False positives are generally to be avoided, and mitigations for reverse engineering are still required (anti debuggers, anti dll injection measures).

All the stuff mentioned like not sending positions of people who aren’t visible are typically already done, but sometimes the position is needed for reasons you don’t understand. Like some gameplay ability to suddenly see through walls, etc.

This thread just has a lot of backseat programming.

I think I would find your post a little less irksome if you approached it from a neutral questioning tone as opposed to “what about these obvious things every junior engineer learns” :/

[Youden]

I'm not trying to condescend or be a backseat programmer, I apologize if my tone suggested otherwise. I know that I have no idea what I'm talking about and I know that there are plenty of competent game developers in the industry.

The problem is that I don't know what I don't know, so I can't directly ask it. The best thing I can do is to present the flawed results of my current understanding so that somebody more knowledgeable (such as yourself) can tear them apart and show me what it is that I'm missing.

> False positives are generally to be avoided

This sounds like the biggest difference to me. Generally in my limited experience in handling abuse on web platforms, the value of a single user is so low that a false positive doesn't really matter too much.

I suppose when it comes to games, each user represents a ~$60 investment and potentially a lot of time and emotional investment, so a false positive can't be so easily tolerated and there's an incentive to go to extreme ends (like intense client-side validation) that wouldn't make sense for say Twitter likes.