• tal@lemmy.today
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    2 hours ago

    The burden should be on the developers and a server side solution.

    There are some fundamental limitations on what you can do with purely server-side solutions. If you’re playing online card games, sure, you can do viable pure server-side stuff to resist most cheating. That’ll get everything short of using, say, a calculator to compute probabilities or count cards or something.

    But with, say, FPSes, that’s not really practical. You need to have some information on the client that the player shouldn’t be privy to to mitigate things like latency. For example, if another player runs around the edge of a wall and becomes visible, your client needs to know that it’s behind the wall and rounding the corner to rapidly show the opposing character becoming visible. And that means trusting client side code. And that entails trusted hardware to do reliably, and that can’t be done by the game developer — it’s gotta have support from Valve if you want that.

    • warm@kbin.earth
      link
      fedilink
      arrow-up
      1
      ·
      1 hour ago

      It’s practical, VACnet has existed for over a decade. It might not be perfect, but it’s a start and any company serious about anti-cheat could take that premise further.

      The downside is that cheaters have to play at least a game before they are detected. Client side stuff is better for initial prevention, but even that’s becoming trivial as most good cheats dont even run on the same computer as the game anymore, circumventing all AC software anyway. If your game costs money to play, that’s already one of the biggest hurdles, so prevention isn’t worth chasing at the expense of privacy and security of users.

      Any downsides from server-side are nothing in comparison to the downsides of client side anti-cheat.