Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few thoughts on client/server in multi-player games
Eric A. Anderson writes <eanders+@CMU.EDU>:
> "Carl Edman" <cedman@cedman.remote.Princeton.EDU> writes:
> > Eric A. Anderson <eanders+@CMU.EDU> 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