[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Open Source Games and Cheating - a paradoxum?



Hi,

Am Die, 2003-01-21 um 19.42 schrieb H. S. Teoh:
> Um, I'm not following the logic here. Why would they "need" to be closed
> source? I'm assuming that you're equating "closed source" to "cannot
> cheat". That's not really true, y'know.

No I don't (and now I notice I wasn't clear enough), but some companies
might think so. If they could be persuated that open source is even
better against cheating (better software, bugs found faster and faster
evolving quality) they might think about open source and maybe own money
by providing a network of servers - just a scenario that crossed my
minds)

> It just takes proper game design
> so that the game *server* is trusted, but the game *client* is not. The
> reason a lot of online games suffer from cheating or "hacks" is because
> of bad design: i.e., trusting the game client.

That, of course, is the most elegant, efficient and simple solution. But
it is not possible in every case - how would you defend against some
kind of bots?

> [snip]
> > My train of thought starts here: Open Source will not require local
> > changes to the game to run and modified versions will have to to be able
> > to connect to certain servers.  But the mainstream which will get stable
> > packaged versions must be stopped from running modified versions on
> > public servers (the servers you usually play and where tournaments -
> > partly with real money prizes - are held). So we need a way for the
> > server to tell if the client is modified.
> 
> This is a legitimate problem, but I disagree that licensing is the answer.

This would just be an example of a semi-open way which would (might)
reqiure different licensing. This (bad) solution is still a close source
obfuscated anti-cheat part, but at least the game could be open source.
.
> But of course, for multi-server games, this becomes a legitimate problem: 
> how to prevent a hacked server from joining a server network. One way,
> based on your suggestion, is: every time a new server connects to the
> existing network of "trusted" servers, to generate a one-time key, and the
> new server must checksum itself using this key (something like MD5
> checksumming but with the key incorporated as an integral part of the
> calculation), and then send the result back to the trusted servers. The
> trusted server then can verify if the new server is "legitimate". This
> method also makes it difficult for a hacked server to fake the reply just
> by caching what the "legal" checksum should be.

Now if that would work (probably would not), why not use the same
process for the client authenticating itself as "legitimate" to the
network?

MfG
Joachim
-- 
Joachim Breitner 
  e-Mail: mail@joachim-breitner.de | Homepage: http://www.joachim-breitner.de
  JID: joachimbreitner@amessage.de | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
            PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Terrorists can take my live.
Only the government can take my freedom.

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: