This is so funny because rust has one of the worst cheating situations and majority of their players are windows users, and theres lots of games that have anticheat that allows linux and have notably less significant cheating problems like marvel rivals. in reality rust doesn’t take cheating very seriously because if they did they would have more server side software that detects illegitimate behaviour like tons of other games do successfully… even most popular Minecraft servers have better functioning anti cheat that is completely server side than rust has while getting kernel access to your pc. its pathetic and lazy development tbh and this entire post from them reads like such extreme cope…

  • wols@lemmy.zipEnglish
    16·
    2 days ago

    Not a game dev either but my guess would be the main reason is server performance/compute cost.
    Any checks that are done on the client run on the users’ hardware instead of the publisher having to pay for more/better servers and electricity.

    I think the disconnect with most other types of developers stems from the respective goal hierarchies. In most fields of computing, correctness isn’t just a high-value goal - it’s a non-negotiable prerequisite. With online multiplayer games, one of your chief concerns is latency and it can make sense to trade some cheating for a decrease in lag. Especially if you have other ways of reducing cheating that don’t cost you any server processing power.

    Also, aren’t many of the client side anti-cheat solutions reused in several games? If you’re mainly checking that the player is running exactly the same client that you published, I imagine the development cost for anti-cheat is lower.

    TLDR: Money. It’s always money.

    • KubeRoot@discuss.tchncs.deEnglish
      3·
      13 hours ago

      I think you’re wrong about one thing - it’s not about compute cost, but about complexity of accounting for latency. You could check if the player can see the enemy they’re claiming to have shot, but you really need to check if they feasibly could’ve seen the enemy on their computer at the time they sent the packet, and with them also having outdated information about where the enemy was.

      The issue gets more complex the more complex the game logic is. Throw physics simulation into the mix and the server and clients can quickly diverge from small differences.

      Ultimately, compensating for lag is convoluted, can still cause visible desync for clients (see people complaining about seeing their shots connect in CS2 without doing damage), and opens up potential issues with fake lag.

      More casual games will often simply trust the client, since it’s better for somebody to, say, fly around on an object that’s not there for other players, than for a laggy player to be spazzing out and rubberbanding on their screen, unable to control their character.