[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Bit on cheating: was: Re: Introductions
Am Mittwoch, 10. Dezember 2003 17:24 schrieben Sie:
> On Tue, 9 Dec 2003, Gregor Mückl wrote:
> > > 2)The main engine is a balanced tree with “game time” as the key. Each
> > > player will run his own tree and only check in with a central server
> > > periodically to stay in sync. When a unit is moved it must publish
> > > events locally, if it moves onto enemy ground, it must publish on both
> > > the local and remote event tree.
> > This is a *very* problematic approach. This way you open barn doors for
> > cheaters. Because each player has the only authoritative copy of his map
> > locally it is on him/her to edit it as he/she likes and noone would even
> > have a chance of noticing that.
> You could fix it though, by storing all events on the client, and having
> the server replay all events when syncing. Only if the states match, the
> player is allowed online. And obviously, other clients would check from
> time to time, that the hashed state of the clients matched the server
> hashes. (This way the server could check the rules, reducing the load on
> the clients). This is doable, I am sure.
That sounds like a nice approach for simulations.
> > The only measures against cheating that I am aware of are rather
> > drastic:
> > - use a server that decides on *everything*. If a citicen in a player's
> > city wants to poop, the server must confirm it.
> But, in non FPS games, where player interaction is rarer, you can actually
> "just" check that the rules were followed once in a while.
Yes, you can definitvely play some tricks here. But since my focus is on an
action game, I am not really aware of too many techniques.
> > - encrypt/obfuscate network traffic.
> Wont work with open source though :-)
Ah, this hits the weak spot of open source games: Once you get hold of the
source code, you can do anything with it, especially adding cheat code within
the actual game logic. So the bottom line is that you can trust neither
server nor client by default, which is a very unpleasant situation.
I think that the easiest countermeasure is to provide players with the means
to rate - and maybe even ban - players that are obviously cheating. However,
this must be done in a democratic process, or the cheaters themselves might
use it in revenge on honest players. Such a model does not need a very
sophisticated design, but will need some kind of moderation to actually work.
> > - never release the sources for your network code. This is not as
> > far-fetched as it might seem: it's very likely that the people at Valve
> > are rewriting their Half-Life 2 network code totally from scratch after
> > the sources leaked in October. The release date hasn't been moved for
> > nothing.
> Other methods, includes what the nethack people does; blessed binaries,
> with embedded (randomly accessed) digital keys.
This is an interesting approach. However, I do not understand how they are
able to hide the key in their binaries. Given the statistic characteristics
of a cryptographic key (quite a lot of keys look like they are an almost
perfect stream of random numbers, mostly because how they are generated), you
should be able to make it out within the file within minutes. Using strace or
gdb on a nethack session might give you quite some extra hints on the
location of the key.
To the key to this approach is to effectively hide the key from prying eyes,
within a region, on which the user has the ultimate control. How can you
possibly do that?
Additionally, this is not possible with true free software licenses like the
GPL, as the binaries and sources that you distribute must actually correspond
exactly. So you would be force to publish the unobfuscated key along with the
code. The only alternative I see now is to use the BSD license. IIRC, nethack
is under a BSD-style license, right?
> And, you could authenticate the players: Won't stop cheating, but allows
> you to distinguesh between players you trust, and do not trust.
See above. Some time ago I've started to design some sort of generic
metaserver along with a player database, which would essentially become some
sort of single-sign-on environment for players.
What I wanted to do was to make a database-backed server that is able to
distribute lists of currently running games along with their states. The
protocol would allow for a filter on the game name to allow the server to be
shared between totally different games (for example, both atlantik and quake
games) and would allow each game server to store and update additional
essentially free-form game specific data with the reference to itself (such
as current map, number of players, etc...).
The second part would have been a centralized player "management" facility
together with means to rate individual players. The players do not need to
enter a lot of information in the registration process: a nick, a password
and a working email address should be enough.
My idea was to provide game programmers with a framework that covers all of
the above. A game that fully supported the framework would even have the
possibility to show each player's current fairness rating (and possibly even
high scores or leage ranking or ... whatever, actually :-) when the player
enters the game.
When I look at all the database work in the backend I think that this might
even be a fun project to tackle. Would anyone be interested?