Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Riot Games Approach to Anti-Cheat

engineering.riotgames.com

Post reply on HN
Print view View original

241–250 of 412 posts

Re: Riot Games Approach to Anti-Cheat

#241

Post by invalidOrTaken »

vkou wrote: post #235
invalidOrTaken wrote: post #175

Earlier quoted context omitted.

>With such a cheat, roaches punch way above their weight, completely breaking the rock-paper-scissors balance of the game. Against marines, sure. But against siege tanks/disruptors? Sirlin's spiel about there being more counters than people think ( http://www.sirlin.net/ptw-book/introducingthe-scrub ) seems applicable here.

Yes, they start punching way above their weight against tanks, too. Even moreso if you throw in an auto-scatter script. https://www.youtube.com/watch?v=IKVFZ28ybQs

What about tanks on high ground and out of reach? What if the roaches have to funnel through a walled choke guarded by some MMLib as well?

That might seem contrived, but there is a player whose job is to contrive it!

No, I don't think the next patch should include "improved" roach AI. But deep strategy games like Starcraft tend to have multiple levels on which to do battle, and you can often nullify an opponent's insurmountable advantage on one level by doing battle on another level. I honestly think that if super-roaches like we've been discussing were patched into the game, with no further changes made, winrates would stabilize around 50% in a few years (assuming everyone hadn't quit in disgust).

Now, that might not be the game you'd want to play. I'll freely admit I wouldn't want to play it. But that's you and me---perhaps whoever's into chess would love it. And "This would no longer be fun for me," while perfectly legitimate, is a very different claim than "the game balance breaks."

Re: Riot Games Approach to Anti-Cheat

#242

Post by matttb »

exgamedev wrote: post #212

Back when I worked in games we would detect cheaters and then shadow ban. Quarantine them by only matching them into games with other cheaters. You may still have to ban them from certain elements of your game, like player economies (auction house, etc). But the more legitimate their experience looks the better. The idea is that instead of fully banning them and triggering the next iteration of the arms race, you tra…

What game did you do this for?

> It's actually fun for them to compete with each other at who can cheat the hardest and no one else gets hurt.

This part reminds me of 'Open' Battle.net for Diablo 2. Everyone used hacked items in pvp and just tried to have better fake items than their opponents.

Re: Riot Games Approach to Anti-Cheat

#243

Post by stcredzero »

Here's my project's approach to Anti-Cheat.

1, 2, 3) Everything on the server. Server's version always wins. Server is the authoritative source. Granted, I have a mathematical advantage in the game's particular movement mechanics which makes this easy to get away with. The other game mechanics are also designed with facilitating this in mind. Corollary: The client is almost nothing and trusted with nothing. It's pretty much a dumb terminal for displaying moving things, syncing their motion with the server.

4) Scripting -- if you can't beat 'em, join 'em! We're going to publish an API to allow for user scripting. We plan on releasing the client as Open Source, allowing people to modify and extend the client.

5) Cryptographically hard RNG and procedural generation. If you want to know what's in Star System 7, Galaxy Grid 123987236-87324958, you're going to have to go there yourself. We don't even know ourselves!

Regarding #4 -- This is going to be a design philosophy. Anything we can't enforce, we will allow and co-opt into the game!

Re: Riot Games Approach to Anti-Cheat

#244

Post by ABCLAW »

invalidOrTaken wrote: post #175
vkou wrote: post #155

Earlier quoted context omitted.

With enough mechanical aides, the game balance breaks. For example, SC2 has a very cheap unit called the roach. When burrowed, it can't attack, but regenerates health incredibly quickly. It's trivial to write a cheat that will, whenever one of your roaches starts taking damage, causes it to burrow, and whenever it stops taking damage, unburrow. The unit is balanced around human control - no human can, with perfect ac…

>With such a cheat, roaches punch way above their weight, completely breaking the rock-paper-scissors balance of the game. Against marines, sure. But against siege tanks/disruptors? Sirlin's spiel about there being more counters than people think ( http://www.sirlin.net/ptw-book/introducingthe-scrub ) seems applicable here.

Is it, though? Sirlin's scrub is a strawperson player that will not adapt to any changes in the game, instead asking that the game itself is changed to suit them. Running cheats is the ultimate scrub move - you change your play experience asymmetrically to benefit yourself rather than practicing at the game as offered to get better.

There are a ton of interactions in games that are degenerate if performed at TAS level. These aren't areas looking for disruption; they're just impossible to perform with human inputs and they confer game advantages that are not surmountable by non-assisted players.

The speed running community segregates TAS content from played content specifically because of this. You will not beat the robot that can perform a 60 input 1 frame trick that gives you a .5 second time save.

Re: Riot Games Approach to Anti-Cheat

#245

Post by megaman22 »

I sorta miss the way cheat codes and exploits were seen back in the long ago days when I started gaming. They were fun little easter eggs and things to mess around with if you got stuck and couldn't progress past a certain point. Or just weird things to have fun with. Of course, pretty much everything was single-player, so it didn't impact anybody else if you wanted to turn on no-clip mode to get around some pain-in-the-ass jumping puzzle in Half-Life, or spawn a nuke-launching spaceman in Age of Empires. And the hours and hours spent button-mashing trying to get new and unusual finishing moves in Mortal Kombat...

Re: Riot Games Approach to Anti-Cheat

#246

Post by Twirrim »

m3rc wrote: post #238
VectorLock wrote: post #224

Earlier quoted context omitted.

This is an interesting approach because even though they may be cheaters they are _still_ people that are interested in your game. The percent of cheaters with the objective to utterly destroy the game they're cheating at is probably negligible.

I mean... sure but they're also only willing to interact with the game when they're making the experience bad for everyone else.

In the case of Riot / League of Legends, these are still potentially customers willing to pay for skins etc, which is their income stream.

I wonder if cheaters are as likely to pay for that stuff as non-cheaters?

Re: Riot Games Approach to Anti-Cheat

#247

Post by unknownid »

mikekchar wrote: post #239
bitexploder wrote: post #149

Earlier quoted context omitted.

I think you are missing my point. This concept in client computing security basically chains back to the halting problem. You can't /know/ what I am doing with my computer. You can build a very elaborate trap / obfuscation and it might be hard, really hard, to defeat it or circumvent it, but it is a certainty that I can. The block-chain has absolutely nothing to do with client code security because it has a network e…

You are absolutely correct, but it occurs to me that CPU designers could actually implement a kind of RSA style memory fetch instruction. The CPU would generate a public/private key pair, where the private key is not accessible by any means. The client would send the public key to the server, which would in turn encrypt the memory location(s) that it wishes to inspect. There would then be an instruction on client's C…

How do you prevent the cheat doing a MITM attack and changing keys?

Re: Riot Games Approach to Anti-Cheat

#248

Post by mikekchar »

unknownid wrote: post #247
mikekchar wrote: post #239

Earlier quoted context omitted.

You are absolutely correct, but it occurs to me that CPU designers could actually implement a kind of RSA style memory fetch instruction. The CPU would generate a public/private key pair, where the private key is not accessible by any means. The client would send the public key to the server, which would in turn encrypt the memory location(s) that it wishes to inspect. There would then be an instruction on client's C…

How do you prevent the cheat doing a MITM attack and changing keys?

Yes, you are right. That's what I was missing :-)

Re: Riot Games Approach to Anti-Cheat

#249

Post by RussianCow »

paulmd wrote: post #232
RussianCow wrote: post #191

Earlier quoted context omitted.

I think what you are getting at is that it's impossible to 100% fully prevent cheating. This is true, but I don't think that's the goal; the goal is to make it difficult enough that it's not worth the effort. The value gained from cheating in a video game is low enough that the vast majority of people would not be willing to go through such lengths to do so.

The average user doesn't have to go to such lengths, they just subscribe to a cheat company that does. That's literally how it works today. Cheats are big business.

Okay, but my comment still stands: You don't need to make it impossible, just hard enough that it's not worth the effort. This applies whether we're talking about individuals or companies.

As an aside, I don't know anything about the market for game cheats. Do people really pay a significant amount of money for that?

Re: Riot Games Approach to Anti-Cheat

#250

Post by Thaxll »

sthomas1618 wrote: post #114
Thaxll wrote: post #103

Earlier quoted context omitted.

> open-sourcing anti-cheat libraries (that won't be defeated by knowing the details). This doesn't make any sense. Anti cheat rely on the fact that it's not known. There is no such a thing as open source in the anti cheat world. It's all very secret for a good reason.

I'd curious to know what strategies make secrecy a necessity. I come from a WebDev background and open-source libraries are almost always always secure and safer then your own (due to the sheer amount of developers and ingenuity working on one repo). Admittedly, game development is a different beast and has to deal with far more client-code so I'm admitting my ignorance here.

The attack surface is not only on the game but on the operating system that the client controls. I mean the game is just a process, the process runs on your computer, you control the computer so you can do anything.
Post reply on HN