RE: [GD-Design] Off-line vs. on-line play and cheating

[Daniel C. <dan...@an...>]

Three techniques the come to mind:

- Balanced Characters
- Social validation
- Statistical validation

*Balanced Characters*
Balanced characters are the easiest conceptually.  You set up the game =
so that every character has tradeoffs.  There is no linear character =
growth, where a final character is more powerful than an advanced =
character.  Instead Character A has bigger weapons, but is slower and is =
taxed heavily by the local police force.  Character B has smaller =
weapons, but they aren't taxed so they can make more money as traders.=20

In the single player or multi-player game, you quest in order to adapt =
your character to your particular style of play. If you cheat, you are =
just changing your character around.  You aren't gaining an advantage =
over anyone.=20


*Social Validation*
Social validation is a process of storing data on your character =
throughout all the other existing player machines, not based off the =
local machine.  Imagine you play with 5 other people and you win.  The 5 =
other machines record encrypted versions of your win.  A central server =
can generate an individual's 'reputation' score based off who is playing =
at any one time.  This system is difficult to hack assuming a large =
number of players.  You can use player ranking as part of this.  "I =
enjoyed playing with him.  I didn't enjoy playing with him"  This can be =
reported as well. =20

What happens to a new player who logs on with an uber character and no =
history?  They are marked as newbies.  (There is nothing more damning to =
a cheater than to be marked as a newbie. :-)  The only way they can make =
a name for themselves is by playing and having their reputation =
propagate throughout the network.=20


*Statistical Validation*
This is the most theoretical, but I'd love to see it done.  Imagine a =
peer-to-peer network and a statically derived model of player =
advancement.  The player ends up generating a character history based =
off playing the game.  This history is then submitted to a central =
server that does a statistical comparison to other histories.  Anomalies =
tend to pop out.  When combined with a social validation system, it =
becomes far more difficult for a user to 'suddenly' get an uber =
character.  Unfortunately, this particular system does not work with the =
offline-online system you described.=20

-Danc.=20



-----Original Message-----
From: Alain Hamel [mailto:ah...@re...]
Sent: Monday, July 22, 2002 12:34 PM
To: Brian Hook; gam...@li...
Subject: Re: [GD-Design] Off-line vs. on-line play and cheating


> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.

Attempting to solve via design. I have to say that I don't see how it =
can be
done. I mean if you want some items in your game to have value (eg: the =
ub3r
starship) then I don't see how it won't be trivialized by hacks. But =
that
doesn't mean it can't be done, I'm about as far from omniscient as one =
can
get.

> Hackers have more time than game developers, so it's a
> losing battle when you try to fight them on their turf.

I don't know if they will always win. For example, I think, but I'm not
sure, that intertrust has not been hacked yet. Of course that could have
something to do with no one adopting their technology... And you have a
somewhat easier problem. If, for example, you required that the client =
log
in (for a new binary) every month or so you could make things much =
harder on
the hackers.

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, July 22, 2002 11:15 AM
Subject: RE: [GD-Design] Off-line vs. on-line play and cheating


> > Wow. Attempting to make an always on line game cheat free is
> > already VERY hard.
>
> I am aware =3D)
>
> > However you are attempting to solve a much harder problem:
> > off line games.
>
> Correct.
>
> But, I think the approach is to solve by design, not by technology
> (which is why I posted to design instead of say algorithms), since
> trying to solve it technologically is a losing proposition since the
> client is inherently untrustworthy.
>
> > Oh, and I would change my binaries as frequently as
> > economically feasible. And make sure that each biniary is
> > different in some fundemental way (eg: automate the process
> > that changes the structures).
>
> This is why I don't want to solve it with technology: the time =
committed
> to trying to fix it is usually disproportionately longer than the
> benefits gained.  Hackers have more time than game developers, so it's =
a
> losing battle when you try to fight them on their turf.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D556
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D556