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

Re: Game idea....



On Tue, 6 Jul 1999, Paul Anderson wrote:

> On Tue, 6 Jul 1999, Dennis Payne wrote:
> 
> > How much control is the player given?  What stops him from designing a
> > kill everything on screen for no energy weapon?  
> >
> Why should he be stopped?  If he did that, then the game would no longer
> be challenging, and no longer enjoyable.

I have read the following posts, and most seems to point out, that people
will not play a game, that is not fun - where people here agree that
cheating is not fun, and an unfair advantedge for one player is liek
cheating.

One poster pointed out multiplayer issues. A single player that has no
morale and gets a kick out of cheating, can completly ruin a dm game of
Quake with 16 people in it. In Denmark, and particulary Sweden, these
players exists. The real trouble here, is that they use bots/proxies, that
is inserted between the client and the server, like this:

quake client <--> bot/proxy <--> quake server

There is hardly any limit to what kind of "change" you can do with this
kind of setup - examples:

- the proxy can change what models is displayed on the players screen, by 
  modifying the contents of the game packets.
- the proxy can transform information - enemy players can be made to glow.
- Since quake uses potentially visible sets to determine what information
  needs to be send to a given client, the information set is larger then
  it "should" be. The real quake client will only display the visible, but
  the proxy can display meta information - like the number of enemy
  players in range, by inserting messages in the information stream.

And so on. I believe it is -really- hard to solve this effeciently. Unless
you start encrypting the stream, someone will reverse engineer your
network protocol, and there you go. Even if you encrypt it, you could
probably have problems.

This is a problem in todays world. I run The Danish Quake League at 
http://dql.challenge.dk/ - we have had to restrict the allowed proxies to
a small set of wellknown proxies, and still some people find ways to
cheat.

Oh, and in case you did not know, let me tell you of a few client side
model modifications that have been used troughout time;

- changing the rocket model to have a looong green pointing thing in the
  beginning of the rocket. It will not harm you, as the collision
  detection takes place on the server, but will let the player see the
  rocket far earlier on the client side, thereby identifying the shooter
  faster, and increase his changes to aviod the rocket.
- changing the lightning from the ligthning gun into a straight line - 
  makes aiming a lot easier
- changing the eye model (used when invisible) into a fully visible man, 
  possible with a shooting dart on the chest and back.

and so on.

id software has made wonderfully configurable games. But their clients
lack solid control of cheats. Worth thinking about when you design you
networked game for Linux.

And, for OSS games; add to the previous that the players have access to
the source. I do not believe in security by obscurity, but there is a
definitive downside to source access here.

Mads

P.S. I have never seen any articles aboout this particular issues. Has
anyone?

-- 
Mads Bondo Dydensborg.                               madsdyd@challenge.dk
Good luck to all you optimists out there who think Microsoft can deliver 35
million lines of quality code on which you can operate your business.
                                        - John C. Dvorak, zdnet.