5 ms·

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

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.
      - wizzwizz4 5y ago
        > The data that the client uses to make those heuristic predictions is the same data the cheats, No, it's not. https://en.wikipedia.org/wiki/Lag#Make_clients_extrapolate https://en.wikipedia.org/wiki/Lag#Make_clients_extrapolate > plus youve added an intermediate network hop for your remote rendering I never said anything about an intermediate network hop. It's not that expensive to cull a few tris, diff the geometry and then send it – especially if you can compress the information, which you can, because you control the client and server. (In fact, you likely don't even need to go down to the tri level to get the effect; all you need to do is turn locating obscured players into a computer vision problem.) I don't know where this “intermediate network hop” comes from. > spending thousands of dollars on secondary rigs Think €60. An HDMI splitter, a USB HDMI capture card, a Raspberry Pi and a USB cable. Not that expensive. > but right now the cheat vector is people running cheats installed inside the kernel. It's functionally equivalent. Your “anticheat” is taking control of other people's computers, stopping a lot of people from being able to play the game entirely, because it was easier for the developers.
ruined 5y ago
because the alternative is server-side rendering of every frame, which would introduce unacceptable latency to input and also likely significantly reduce graphical detail, given the existing huge investments in consumer rendering hardware that have not yet been duplicated serverside google stadia exists. nobody playing competitively uses it, and that's exactly the demographic that cares the most about anti-cheat and, it still doesn't prevent computer-assisted input
- fud7r7rgtf 5y ago
  Speaking as an avid Stadia user, I think this has a lot more to do with Stadia's library being garbage compared to the non-Stadia options. I can't imagine a reason an e-sport pro would want to go from the entire competitive ecosystem as a choice to just what's on Stadia. Even for casually competitive players, there's a massive lack of mainstream competitive titles on Stadia. Maybe the latency input is the problem but it seems like a big assumption with how miniscule the library is.
  - DynamicStatic 5y ago
    I'm very much a competitive fps player, i have low latency to the closest stadia server and I'll tell you: It's absolutely unplayable for me due to the input lag. I'm normally in top 1-2% and on stadia I'm closer to top 30% it's a huge difference.
robertlagrant 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. Think about the case of seeing an enemy onscreen and headshotting them instantly.
- TheCraiggers 5y ago
  I think you misunderstood my post, and considering the surprising number of downvotes on it, I wonder if others did too? Can you explain further though? I don't understand your case. It sounds like an aimbot, which is what would be prevented by not sending the client more info than is needed.
  - AdrianB1 5y ago
    I guess it is the case where the info begs to the player, the player reaction time is in tens or hundreds of milliseconds (time to render the image, display it on the screen, player to see, move the mouse to aim and shoot) versus an aimbot that does not need to wait and can react in a few milliseconds. This is cheating if the cheater's aimbot is using an advantage normal players don't have (unless everyone is using aimbots and this is no longer a human-played game but a bot game).
  - maccard 5y ago
    The thing about aim bots is that they're quicker than you and they don't make mistakes. A monitor and a rendering engine will introduce up to 3-5 frames of latency (double buffering, refresh rates). Your client likely has the next 1-3 frames of data ready to go so it can do client side prediction/interpolation/smoothing, which means the cheat has access to that data. All of the data that's required to make modern games look and _feel_ good is the data you're talking about throwing away here
  - robertlagrant 5y ago
    As far as I know an aimbot can work just with pixels that it can see.

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.
    - wizzwizz4 5y ago
      > The data that the client uses to make those heuristic predictions is the same data the cheats, No, it's not. https://en.wikipedia.org/wiki/Lag#Make_clients_extrapolate https://en.wikipedia.org/wiki/Lag#Make_clients_extrapolate > plus youve added an intermediate network hop for your remote rendering I never said anything about an intermediate network hop. It's not that expensive to cull a few tris, diff the geometry and then send it – especially if you can compress the information, which you can, because you control the client and server. (In fact, you likely don't even need to go down to the tri level to get the effect; all you need to do is turn locating obscured players into a computer vision problem.) I don't know where this “intermediate network hop” comes from. > spending thousands of dollars on secondary rigs Think €60. An HDMI splitter, a USB HDMI capture card, a Raspberry Pi and a USB cable. Not that expensive. > but right now the cheat vector is people running cheats installed inside the kernel. It's functionally equivalent. Your “anticheat” is taking control of other people's computers, stopping a lot of people from being able to play the game entirely, because it was easier for the developers.

ruined 5y ago

because the alternative is server-side rendering of every frame, which would introduce unacceptable latency to input and also likely significantly reduce graphical detail, given the existing huge investments in consumer rendering hardware that have not yet been duplicated serverside google stadia exists. nobody playing competitively uses it, and that's exactly the demographic that cares the most about anti-cheat and, it still doesn't prevent computer-assisted input

fud7r7rgtf 5y ago
Speaking as an avid Stadia user, I think this has a lot more to do with Stadia's library being garbage compared to the non-Stadia options. I can't imagine a reason an e-sport pro would want to go from the entire competitive ecosystem as a choice to just what's on Stadia. Even for casually competitive players, there's a massive lack of mainstream competitive titles on Stadia. Maybe the latency input is the problem but it seems like a big assumption with how miniscule the library is.
- DynamicStatic 5y ago
  I'm very much a competitive fps player, i have low latency to the closest stadia server and I'll tell you: It's absolutely unplayable for me due to the input lag. I'm normally in top 1-2% and on stadia I'm closer to top 30% it's a huge difference.

robertlagrant 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. Think about the case of seeing an enemy onscreen and headshotting them instantly.

TheCraiggers 5y ago
I think you misunderstood my post, and considering the surprising number of downvotes on it, I wonder if others did too? Can you explain further though? I don't understand your case. It sounds like an aimbot, which is what would be prevented by not sending the client more info than is needed.
- AdrianB1 5y ago
  I guess it is the case where the info begs to the player, the player reaction time is in tens or hundreds of milliseconds (time to render the image, display it on the screen, player to see, move the mouse to aim and shoot) versus an aimbot that does not need to wait and can react in a few milliseconds. This is cheating if the cheater's aimbot is using an advantage normal players don't have (unless everyone is using aimbots and this is no longer a human-played game but a bot game).
- maccard 5y ago
  The thing about aim bots is that they're quicker than you and they don't make mistakes. A monitor and a rendering engine will introduce up to 3-5 frames of latency (double buffering, refresh rates). Your client likely has the next 1-3 frames of data ready to go so it can do client side prediction/interpolation/smoothing, which means the cheat has access to that data. All of the data that's required to make modern games look and _feel_ good is the data you're talking about throwing away here
- robertlagrant 5y ago
  As far as I know an aimbot can work just with pixels that it can see.