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

Re: Open Source Games and Cheating - a paradoxum?

On Tue, Jan 21, 2003 at 04:57:42PM +0000, Joachim Breitner wrote:
> You might wonder how this relates to debian. In my opinion, this problem
> might become crucial to Debian. It's games that awake computer interest
> and skills in young kids, and Debian needs them as volunteers. But if
> ...

while i think you overestimate the imprtance of games to the free
software community in general and to debian in special, i would
definitely like to see more free quality games, and i think that a
discussion about the role of games in free software would be very

the point that you gave in your post (the necessity of closed source to
avoid cheating) is wrong in my opinion however, because not releasing
source for a software might make it more difficult to understand and
modify a software, but not at all impossible. everyone with a good
understanding of assembly language will be almost as fine with the
compiled code as he would be with the source, as the experience with
cracks in the closed-source world shows. and raising the barrier doesn't
help much, as most people/cheaters won't crack the software themselves,
but use patches written by way more skilled people. as usual security by
obscurity doesn't work. and, as far as i can see, there is no crypto or
any other solution that will help you there, it's simply a black-box
problem: you have a client that communicates with a server, but you can
never trust the client. if the server gives any information to the
client that the user isn't supposed to see, or accepts any commands that
the user wasn't supposed to give, it is possible to cheat. 

as you said,  lot of "modern" games require some work on the client side 
or the server won't be able to handle the load, so they have to trust the
clients up to some point. there are some possibilities however that
could solve that problem, for example the client could do some
work for the server and send the results back as suggestions which will
be accepted by the server in most cases, but cross-checked in a few. 

if you want to have security, you need to do the critical work in trusted
code on a trusted machine, and that means not on the client. no way 

a more interesting point is that the quality of a game has many
dimensions. while games like tetris and pong obviously must have some
special qualities, most probably that it's just a good concept, there
are other qualities like eye-candy and being brand-new as well. while
the first kind of qualities fits into the open-source development model
very well, the second don't in my opinion. this might be the reason why
we have a lot of very good free games, but of a different kind than the
closed-source world has. perhaps it is too difficult to develop games
under an open-source license in a way that is profitable enough to get
them before the corresponding closed-source games are years ahead. 

on the other hand closed-source games only make money for a very short
period of time, i think much less then the time it would usually take to
develop something similiar in a open-source fashion. so perhaps we need
a special open-source game license that allows the closed-source
distribution of games for a fixed period of time but guarantees that it
is available to the public afterwards. this way game companies could
make their money on the games for some time, sponsored by those that
definitely needs the latest and hottest, and still the game will be
available to the free software community in less time then it would take
to develop something similar.

a completely different question is whether debian would be able to
handle the kind of games the closed-source world has. there is for
example an rfp for uqm (Ur Quan Masters), a star control clone. the
legal problems aside, if we pack it the usual debian way (perhaps a game
package and one for the arch-independent data) it would add 200 megs to
the debian archive. if we do this with every game, our archive will very
soon have a completely unmanageable size. 

...random thoughts
cu  robert

Reply to: