Re: Cheating in OS games?

[Jiri Svoboda <jirik.svoboda@seznam.cz>]

Hi folks!

You have a both interesting and flaming discussion on whether to make effort to prevent cheating in OS games. But maybe you should consider two essential questions first:

1. What is cheating?
2. It it possible to prevent cheating?

Sounds simple? Think again.

Let's take an example (ridiculous, stupid, yet adequate): A MUD. Let's simplify it a little: a multi-player game where the players have to find their way through a maze.

Now let's consider a most stupid implementation:
- Maps are stored on both server and clients.
- Server sends coordinates of all players to each client.
- Client displays what should be displayed, hides what should be hidden.
- Client parses keys and sends the new coordinates of the player back to the server.

Let's cheat!

1. CHEAT
--------
We'll rewrite the client so that we can pass through walls. Do you consider that cheating? Yes, I presume.

FIX
---
The client doesn't send back new coordinates, but just controls (keys). Simple.

2. CHEAT
--------
We'll modify the client as to show us even the things which should be hidden, to find the way automatically for us, to drive our player etc. Most probably that is cheating.

FIX
---
Server sends only information which is visible to the player. Somewhat complex and eats server's CPU time.

3. CHEAT
--------
We'll modify the client as to do automapping for us, more comfortable player control, enemy avoiding, etc. Still cheating.

FIX
---
We'll make the client closed-source, add some cryptographical keys/signatures to identify, whether the client is original and unmodifyed. Very complex, maybe even impossible to do.

4. CHEAT
--------
We'll take a pice of paper and a pencil and do the mapping ourselves. Is that cheating or not? Don't know. But instead of a piece of paper and a pencil we could use another computer and make a bot to play instead of us, here we go again...

FIX
---
Impossible.

----------------

My point is that cheating is difficult do define and impossible to prevent (especially with open source).

Thus trying to prevent cheating (of most of the listed types 1-4) just doesn't make sense.


My advice:

	A well written network code is generally immune against cheating of type 1 where possible. It's not difficult and it's a proof of good network code, a code that is immune to transmission errors.

	As for cheating type 2, it's not a good idea to send information totally irrelevant for the player, because of the extra bandwith consumption. But trying to send strictly only what the player can see is just not worth the effort.


CONCLUSION
----------
Not finishing the game just because you spent too much time on security is a shame. Just try to keep your code nice and clean and with some basic security aspects in your mind.

When (If) you have the game working and becoming popular, fix some security holes, if you like.

Motivate players not to cheat.

Hope thay don't cheat. Have a coffee. Be proud of your game.



Jiri Svoboda
____________________________________________________________
Zde pro Vás máme výrobky s prodluženou zárukou 2+2 roky, odborný autorizovaný servis a kvalitní poradenství techniků. http://ad2.seznam.cz/redir.cgi?instance=64770%26url=http://www.prackymycky.cz