5 ms·

So whats your solution? Let cheaters run around?

wizzwizz4 5y ago
Anticheat without malware has been around for ages: simply don't trust the client. Even Minecraft servers manage it. Instead of playing a constant game of cat-and-mouse trying to prevent forbidden code from running when you can just plug in a USB rubber ducky, put the logic server-side. Ban problematic behaviour, as opposed to methods that might result in problematic behaviour. It takes some ingenuity, but what are gamedevs known for if not ingenuity? (Well, apart from withstanding abusive working environments for long enough that they can be profitably discarded, traumatised, after they can no longer function as effectively as a green new intern… but let's focus on the ingenuity.)
- moultano 5y ago
  Aimbots need no trust from the server. As long as the client knows things the player doesn't, and there isn't a chain of custody from the physical mouse to the server, you can cheat.
  - TheCraiggers 5y ago
    Why would a client need to know of such things? If the player can't / shouldn't know of something, then the client shouldn't either. There are some interesting repercussions of this train of thought though. Take an enemy hiding in brush in an FPS game. The player would have line of sight to their hiding spot, and current games (I think) just leave it to the player's eyeballs' ability to see them through the brush. That's kinda cool in that it raises the skill ceiling and it's obviously immersive. However, there's a whole host of reasons it's bad. First, there's the aim bots and other cheating it allows for. Second, what if the player has bad eyesight? So there's an accessibility issue there. Third, you get people doing a... lighter form of cheating where they turn their graphics settings down to the lowest setting (sometimes even editing INI files to lower them down below what is possible via the GUI) that would lower foliage quality, making it easier to see the enemy. Probably some other things too. There are perhaps many interesting ways to fix this. D&D has their own way with random chance, but I can see players of skill-based scoffing at this, and I don't blame them. But I feel the current approach is lazy game design, and perhaps something interesting could be thought up.
    - wizzwizz4 5y ago
      Alternatively, you could provide the geometry without providing the semantic information. I'm not sure how viable that is, but it'd make aim-bots a bit harder. > First, there's the aim bots and other cheating it allows for. You can make an aim bot by connecting the output of your monitor to a hardware-emulated mouse. Unless the server can detect this, kernel-level anticheat is building a really tall wall with the door unlocked. (If it worked I wouldn't object so much.)
      - maccard 5y ago
        > Alternatively, you could provide the geometry without providing the semantic information. Yes - cloud rendering. It's _a_ solution but comes with tradeoffs. Namely, it introduces large amounts of latency, and costs a dumpster truck of money. > You can make an aim bot by connecting the output of your monitor to a hardware-emulated mouse. Anticheat is a cat and mouse game, and raising the barrier to entry improves the experience no end. There's a _big_ difference between downloading and running an exectuable, and buying specialist hardware to cheat at a game.
        wizzwizz4 5y ago
        > Yes - cloud rendering. Only a very small part of the rendering needs to be done on the server; notably, the camera could still move, and the client could still make the usual heuristic predictions about where things are, so it wouldn't feel laggy. > and buying specialist hardware If you have a streaming rig, you already have nearly all the hardware. Just add a Raspberry Pi Zero or something, and you're good to go. (But yes, the barrier-to-cheat is still higher… at the cost of also increasing the barrier-to-play-at-all.)
        maccard 5y ago
        > Only a very small part of the rendering needs to be done on the server; notably, the camera could still move, and the client could still make the usual heuristic predictions about where things are, so it wouldn't feel laggy. This is just nonsense. The data that the client uses to make those heuristic predictions is the same data the cheats, so once you send that extra data over you've undone the benefit of not sending the client any extra info it needs, _plus_ youve added an intermediate network hop for your remote rendering, _and_ you've now required that your game has essentially a hardware DRM in the remote computer that you're rendering. > If you have a streaming rig, you already have nearly all the hardware. Just add a Raspberry Pi Zero or something, and you're good to go. The number of people out there who are spending thousands of dollars on secondary rigs to hook up emulated mice via a raspberry pi to run custom cheats has got to br vanishingly close to 0 for even biggest games in the world. Given that _these_ are the measures youre suggesting to bypass the anticheat, it sounds like they've sufficiently raised the bar to me. When people writing AI driven hardware mice is a common cheat vector let's talk, but right now the cheat vector is people running cheats installed inside the kernel.
- gjsman-1000 5y ago
  As a Minecraft server operator, I can tell you there are plenty of client-side cheats that are hard to stop server-side. Also many players end up complaining about false positives typically caused by movement errors from internet lag on their end. Also, all these anti-cheat methods are not supported by Mojang but are third-party plugins. Stock Minecraft Server hardly tries to prevent many of the hacks.
  - wizzwizz4 5y ago
    > Stock Minecraft Server hardly tries to prevent many of the hacks. It would require stuff like server-side chunk culling, which doesn't jibe with the way Minecraft is designed. However, there's nothing stopping a new game from being designed like that. I named Minecraft because it's fundamentally flawed for server-side anti-cheat (you're limited by a client that requires a lot of theoretically-unnecessary information, and doesn't send enough requests for you to provide this lazily), and people manage to catch enough cheating to keep things fun for everyone else. If you control both the server and the client, you don't really have much of an excuse.
    - maccard 5y ago
      > However, there's nothing stopping a new game from being designed like that. Modern games do network culling. UE4 supports it out of the box. The _millisecond_ that information is replicated to the client, (which has to be before the client views it on screen to allow for hardware latency), a cheat will have access to it and will be able to act on that information. Even if you have the fastest monitor known to man, and no rendering buffering there's 6ms before you can draw the player on screen, or 1ms to poll your mouse/gamepad, so the cheat wins.
      - wizzwizz4 5y ago
        So don't let clients react on information until 8ms after they get it? If it's a game where you can't do that, collect probabilistic evidence on players until you have a lot of evidence that a player is cheating, and add them to the “we'll ban later, but let's mitigate the damage for now” list. Cheating players are statistically distinguishable from really good non-cheating players most of the time – and when they're not, we're at the level of cheating where it's unlikely your anti-cheat will help, because they'd just fork out the €50 for cheating hardware.
- gizmondo 5y ago
  And how server-side detection of aimbot can look like? If the latter is not written by a retard, you're very quickly down to statistical detection. Which is also cat-and-mouse, but the cat is crippled.

Anticheat without malware has been around for ages: simply don't trust the client. Even Minecraft servers manage it. Instead of playing a constant game of cat-and-mouse trying to prevent forbidden code from running when you can just plug in a USB rubber ducky, put the logic server-side. Ban problematic behaviour, as opposed to methods that might result in problematic behaviour. It takes some ingenuity, but what are gamedevs known for if not ingenuity? (Well, apart from withstanding abusive working environments for long enough that they can be profitably discarded, traumatised, after they can no longer function as effectively as a green new intern… but let's focus on the ingenuity.)

moultano 5y ago
Aimbots need no trust from the server. As long as the client knows things the player doesn't, and there isn't a chain of custody from the physical mouse to the server, you can cheat.
- TheCraiggers 5y ago
  Why would a client need to know of such things? If the player can't / shouldn't know of something, then the client shouldn't either. There are some interesting repercussions of this train of thought though. Take an enemy hiding in brush in an FPS game. The player would have line of sight to their hiding spot, and current games (I think) just leave it to the player's eyeballs' ability to see them through the brush. That's kinda cool in that it raises the skill ceiling and it's obviously immersive. However, there's a whole host of reasons it's bad. First, there's the aim bots and other cheating it allows for. Second, what if the player has bad eyesight? So there's an accessibility issue there. Third, you get people doing a... lighter form of cheating where they turn their graphics settings down to the lowest setting (sometimes even editing INI files to lower them down below what is possible via the GUI) that would lower foliage quality, making it easier to see the enemy. Probably some other things too. There are perhaps many interesting ways to fix this. D&D has their own way with random chance, but I can see players of skill-based scoffing at this, and I don't blame them. But I feel the current approach is lazy game design, and perhaps something interesting could be thought up.
  - wizzwizz4 5y ago
    Alternatively, you could provide the geometry without providing the semantic information. I'm not sure how viable that is, but it'd make aim-bots a bit harder. > First, there's the aim bots and other cheating it allows for. You can make an aim bot by connecting the output of your monitor to a hardware-emulated mouse. Unless the server can detect this, kernel-level anticheat is building a really tall wall with the door unlocked. (If it worked I wouldn't object so much.)
    - maccard 5y ago
      > Alternatively, you could provide the geometry without providing the semantic information. Yes - cloud rendering. It's _a_ solution but comes with tradeoffs. Namely, it introduces large amounts of latency, and costs a dumpster truck of money. > You can make an aim bot by connecting the output of your monitor to a hardware-emulated mouse. Anticheat is a cat and mouse game, and raising the barrier to entry improves the experience no end. There's a _big_ difference between downloading and running an exectuable, and buying specialist hardware to cheat at a game.
      - wizzwizz4 5y ago
        > Yes - cloud rendering. Only a very small part of the rendering needs to be done on the server; notably, the camera could still move, and the client could still make the usual heuristic predictions about where things are, so it wouldn't feel laggy. > and buying specialist hardware If you have a streaming rig, you already have nearly all the hardware. Just add a Raspberry Pi Zero or something, and you're good to go. (But yes, the barrier-to-cheat is still higher… at the cost of also increasing the barrier-to-play-at-all.)
        maccard 5y ago
        > Only a very small part of the rendering needs to be done on the server; notably, the camera could still move, and the client could still make the usual heuristic predictions about where things are, so it wouldn't feel laggy. This is just nonsense. The data that the client uses to make those heuristic predictions is the same data the cheats, so once you send that extra data over you've undone the benefit of not sending the client any extra info it needs, _plus_ youve added an intermediate network hop for your remote rendering, _and_ you've now required that your game has essentially a hardware DRM in the remote computer that you're rendering. > If you have a streaming rig, you already have nearly all the hardware. Just add a Raspberry Pi Zero or something, and you're good to go. The number of people out there who are spending thousands of dollars on secondary rigs to hook up emulated mice via a raspberry pi to run custom cheats has got to br vanishingly close to 0 for even biggest games in the world. Given that _these_ are the measures youre suggesting to bypass the anticheat, it sounds like they've sufficiently raised the bar to me. When people writing AI driven hardware mice is a common cheat vector let's talk, but right now the cheat vector is people running cheats installed inside the kernel.
gjsman-1000 5y ago
As a Minecraft server operator, I can tell you there are plenty of client-side cheats that are hard to stop server-side. Also many players end up complaining about false positives typically caused by movement errors from internet lag on their end. Also, all these anti-cheat methods are not supported by Mojang but are third-party plugins. Stock Minecraft Server hardly tries to prevent many of the hacks.
- wizzwizz4 5y ago
  > Stock Minecraft Server hardly tries to prevent many of the hacks. It would require stuff like server-side chunk culling, which doesn't jibe with the way Minecraft is designed. However, there's nothing stopping a new game from being designed like that. I named Minecraft because it's fundamentally flawed for server-side anti-cheat (you're limited by a client that requires a lot of theoretically-unnecessary information, and doesn't send enough requests for you to provide this lazily), and people manage to catch enough cheating to keep things fun for everyone else. If you control both the server and the client, you don't really have much of an excuse.
  - maccard 5y ago
    > However, there's nothing stopping a new game from being designed like that. Modern games do network culling. UE4 supports it out of the box. The _millisecond_ that information is replicated to the client, (which has to be before the client views it on screen to allow for hardware latency), a cheat will have access to it and will be able to act on that information. Even if you have the fastest monitor known to man, and no rendering buffering there's 6ms before you can draw the player on screen, or 1ms to poll your mouse/gamepad, so the cheat wins.
    - wizzwizz4 5y ago
      So don't let clients react on information until 8ms after they get it? If it's a game where you can't do that, collect probabilistic evidence on players until you have a lot of evidence that a player is cheating, and add them to the “we'll ban later, but let's mitigate the damage for now” list. Cheating players are statistically distinguishable from really good non-cheating players most of the time – and when they're not, we're at the level of cheating where it's unlikely your anti-cheat will help, because they'd just fork out the €50 for cheating hardware.
gizmondo 5y ago
And how server-side detection of aimbot can look like? If the latter is not written by a retard, you're very quickly down to statistical detection. Which is also cat-and-mouse, but the cat is crippled.