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

Re: Game Loop and Simulation



Mads Bondo Dydensborg wrote:
> 
> 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).

The problem under Linux is that all the infrastructure is OpenSourced and
the provisions of GPL guarantee that you shall be able to re-link the
binary against new library code.

Hence, even though you have no sources - and no desire to reverse engineer
the binary, cheating is still possible.

One hack that would be very easy (for example) would be to change Mesa
to render every polygon at only 80% of it's normal opacity.  This would
allow you to see through walls at people hiding behind them. (Well, maybe)
This would only take a couple of lines of code.

I'm sure that an inventive mind with nothing better to do than cheat
on computer games could come up with a variety of similarly creative
hacks.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)