[MUD-Dev] How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It by Matt Pritchard

[Greg Underwood]

<way OT>
try number three...  remedial email for Greg if this fails... :P
</OT>

I'm surprised this article didn't appear on Gamasutra sooner.  It
ran in Game Developer Mag. a couple months ago, and they're usually pretty
good about synching the two up.  It doesn't seem to differ radically from
the magazine version, though I didn't do a thurough check.  *shrug*

On to the meat of the topic.  All of Matt's suggestions on how to counter
cheaters are quite excellent, and I have that particular issue of GDMag
filed in my "special" pile... :)  I found the stuff on peer-to-peer
approaches to be particularly brilliant in it's simplicity:

J C Lawrence writes:

> http://www.gamasutra.com/features/20000724/pritchard_pfv.htm
> 
> --<cut>--
> How to Hurt the Hackers: The Scoop on Internet Cheating and How You
> Can Combat It
> 
> By Matt Pritchard 
> Gamasutra
> July 24, 2000
> URL: http://www.gamasutra.com/features/20000724/pritchard_01.htm

[...]

> The Client Is Always Right

[...]
 
> Fortunately there are several steps that a game developer can take
> to eliminate most problems with authoritative clients. A first step
> is to install a mechanism in the game that verifies that each player
> is using the same program and data files.

Rather simple, as he says, but a good first line of defense.  I view it as
similar to the reasoning behind those tiny luggage locks... more to keep
stuff in than to keep determined theives/hackers out.  And it discourages
the less than determined.

[...]
 
> For peer-to-peer games, cheating can be made difficult by changing
> from a game engine that issues commands to one that issues command
> requests. 

[...]


This kind of approach would work spectacularly well for even games as
simple as card games.  Basically, dealing the cards becomes the point of
concensus - each machine deals one card in turn, building a communal pool
of cards.  Any cheaters would be spotted instantly, when they play cads
that were'nt agreed upon as dealt to them.

Thinking about it, I think I see why this method works so well. 
Essentially, that communal-concensus is how real-world games work.  We all
agree that, as cards are dealt, the dealer isn't picking who gets what
cards, and the deal is passed from one dealer to the next (unless you're in
vegas... but that's client-server :).  It's distributed in nature, and
that's why mapping it to the computer that way minimizes large chunks of
cheats.

[...]

> Alternatively, you can make life even more difficult for the hacker
> by easing up on the received command request evaluations. By
> allowing command requests to bypass the verification check only on
> the machine that issued it, you're deliberately allowing the game to
> go out of synch 

[...]
 
I love this too... entrapment!  Let them hang themselves! :)

-Greg



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev