Re: A few thoughts on client/server in multi-player games

["Carl Edman" <>]

Eric A. Anderson writes <>:
> "Carl Edman" <> writes:
> > Eric A. Anderson <> writes:
> > [ not easy to setup a server not a problem because smart hacker
> >   types will be maintaining the server ]
> Why make it hard to setup a server?  Ease of having servers is a good
> thing because the more people that run servers, the more people will
> play.

Nobody said that it _should_ be hard to set up the server.  All that  
was said was that it is OK to expect a certain degree of technical  
competence of the part of server gods.  It is not OK to expect more  
technical competence on the part of a client user than is e.g. required  
to install a typical shrink-wrapped MS-DOS or Mac program.

> > I think we can build a good protocol which assumes nothing more of
> > the   client than that it has a bidirectional 8-bit channel to
> > server with a   bandwidth of at least 1-2 kBytes/second and round
> > trip time of at most   100-200 ms.  The class of such machines is
> > vast and the rest can be   built on top of that basis.
>
> Which bring back my earlier point of 4 fps.  You'd need to change the
> style of the game to play with 200 ms of net delay.  Especially if a
> packet gets dropped, and you suffer a round trip to get it resent.
> Unfortunately, 4fps means less of the arcade feel that some people
> want to have.

200 ms _round_trip_ at the outer end of playability.  That means 100 ms  
to drop a packet one way or 10 fps.  And nobody said that all servers  
have to run at that speed for all users.  I just picked those numbers  
out of the air as what a good protocol can be designed to accomodate.   
Most people will of course have far better net connections.

	Carl Edman