Re: Cheating in OS games?

[Jan Ekholm <chakie@infa.abo.fi>]

On Mon, 15 Dec 2003, Gregor [iso-8859-1] Mückl wrote:

>Am Montag, 15. Dezember 2003 12:51 schrieben Sie:
>> On Mon, 15 Dec 2003 madsdyd@challenge.dk wrote:

>> The moment you start considering adding extra complex bloat that adds
>> basically nothing but draws tremendous amounts of developer time, the game
>> goes dead.
>>
>
>How much developer time this takes is actually a matter of how you do it. If
>it takes too long, the project is doomed anyway.  Usually, anti-cheating
>measures are part of the networking code, which should be fairly contained
>and therefore easy to replace or alter. So if implementing some anticheat
>measures takes too long the source code wasn't modularized enough beforehand.

>So if the team actually wasted time with that it's likely that they wouldn't
>have finished the game at all. Or isn't it?

My point, even if it wasn't at all clear was that when developers start
adding non-essential functionality to a game before it is released they
have a much higher chance of never getting it done. I know from
experience. :) It's not about modularized code vs spaghetti code. I
personally have no idea what I should do for anti cheat in our game, so I
silently ignore it until 1.0 is done and I can sit back and relax a bit.
If I had to start thinking about that and "generic security" I'd easily
waste some months of precious development time.

The first few years of development time should be focused on getting a
tight and well defined feature set done and actually get the game out
there to the players.

>> >IMHO, you need to at least _consider_ cheating, and understand what
>> >you need to do to prevent, very early on, or your design will have a hard
>> >time fixing the problems. So, if people start cheating, you can change
>> >your program to fix as much as possible.
>>
>> This I can agree with, you can add an empty method call to a antiCheat()
>> method and fill it in later when the game has reached 1.0 and is released.
>
>If it only were that easy! :-)

It wasn't meant seriously. :)

>I think that making something cheat-proof is rather a running than a single
>step. You should always keep in mind while writing your game code and ask
>yourself: Is it safe to send this data? How much does the game rely on this
>information? Is it a bad thing if it gets modified on the way? Finding
>answers to this questions is relatively easy while you are coding on the
>protocol and is not much extra effort in my oppinion.

Well, finding out that 99% of all data is important is probably simple. A
few hours work maybe. Then to actually start researching and trying to
come up with some idea is a few weeks. Then actually coding it and
verifying it is another few weeks. And the issue remains: if someone wants
to cheat they can probably cheat no matter how much stuff I add in to
counter it.

-- 
   Crowley was in Hell's bad books. Not that Hell has any other kind.
                           -- Terry Pratchett & Neil Gaiman, Good Omens