Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Client/Server Implementation





"Eric A. Anderson" wrote:
> Mark Wedel <master@rahul.net> writes:
> > 1) Finish the client/server split as soon as possible, and whether it
> >    doesn't handle things particularly well (or in a limited fashion), or th
e
> >    protocol is not documented is not important.  IT may also mean that
> >    the clients become frequently obsoleted as additional commands are added
.
> This gets my vote.  [...]

Me too. I think it is best to get a working client/server version ASAP and 
then add bells and whistles. Expect to cycle through several versions in
a short period of time.

> > 3) There should be good documentation on what the protocol is, good
> >    documentation on what the code does, as well as keeping the code readable.
> This is a good idea too; but if writing documentation stalls the
> release of the client for too long, I'd rather release an interim
> version.

Ditto. At least have a description of the protocol (which we do have at the 
moment). Details of the implementation can wait until the code has settled 
down.

> > B) Client should have fast startup.
> Yes, a startup on the order of 5 seconds I think is important.

I disagree here. I don't think fast startup is particularly important. Most
Crossfire play probably lasts hours, so taking 30 seconds at the start is 
no big deal (Even creating a character takes longer than that).

> > C) Client should be able to take advantage of local image files so that
> >    they then do not need to be transmitted.
> Without this, B is violated over 14.4 modems.

It's a good idea anyway.

>  E) Playing with the client over 14.4 should be possible and should
> not directly result in the players death because too much data needs
> to be transmitted.

I don't think we should worry about slow connections to start with. Get it
working first, then make sure it works adequately over slow links.

>  F) Different speeds of connections should not substantially slow down
> other players.

Yup.

>           -Eric 
--
Rupert G. Goldie, Research Scientist                rgg@aaii.oz.au
Australian Artificial Intelligence Institute        
/\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia