Re: Game Loop and Simulation

[Mads Bondo Dydensborg <madsdyd@challenge.dk>]

On Wed, 9 Feb 2000, Alan Chen wrote:

> I should note that there are related problems with a
> standard client-server setup. A dishonest client can
> cause just almost as many problems as a dishonest or
> malfunctioning peer.  Does anyone have info on
> solutions for that?

There has recently been a lot of discussion about this on the QuakeForge
mailing list, given that cheating in the current implementation of Quake 1
is very possible.

You will have to divide the cheats into 2 classes:

a) cheats like : client side "bots" that plays instead of the server
   (also timers etc).
b) cheating directly with the game state; running faster then allowed, 
   etc.

Due to a tradeoff between clientside prediction and security, cheats like
b) are very possible in Quake (at the moment). Moving all game logic to
the server seems to be the only way to stop this.

a) is unstopable (in theory). Only if you can find a way to ensure the
client player uses the correct client, OS, drivers, hardware, etc. can you
guarentee cheating wont happen. In practice various levels of obfusication
may help for various periods of time. (Like binary only releases,
encrypting the datastream, hiding the decryption key in the binary, etc).

Mads

-- 
Mads Bondo Dydensborg.                               madsdyd@challenge.dk
Pretty cool, the kind of power information technology puts in our hands
these days. 
    - Securityfocus on probing 36000000 hosts for known problems in 3 weeks