[Freeciv-Dev] Re: release plans

["Claus Leth Gregersen" <leth@xxxxxxxxxxx>]

----- Original Message -----
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
To: Claus Leth Gregersen <leth@xxxxxxxxxxx>
Cc: Artur Biesiadowski <abies@xxxxxxxxx>; Freeciv Dev
<freeciv-dev@xxxxxxxxxxxx>
Sent: Friday, September 24, 1999 9:19 PM
Subject: Re: [Freeciv-Dev] Re: release plans


> On Fri, Sep 24, 1999 at 07:41:13PM +0200, Claus Leth Gregersen was heard
to say:
> > Actually at some point in the development, we tried to merge client and
> > server into one executable.
> > That would in my opinion be the ideal solution.
>
>   Far be it from me to argue with someone who's been with this project for
that
> long -- but, well, I'm going to.  IMO, there are a number of good reasons
to
> separate the two, ranging from aesthetic (having one 'special' client that
> doesn't have a real connection is a pain) to stability (having the server
> die and kill the game if the host's GUI blows up is not so good) to
> responsiveness (doing server stuff and client stuff in the same thread is
> pretty much guaranteed to cause delays for one or the other.  What if I
decide
> to display a huge zoomed-out picture of the map right while two other
people
> are having a pitched battle?  We get stuck in the map-drawing routine and
their
> packets pile up until it finishes..
>
> > One of the most cool things about having client/server in one
executable,
> > would be that it would be quite easy to active the server part on
another
> > client. Say we have a setup like this:
> >
> > 4 players (a,b c and d) play the game on a's server.
> >
> > now a has to leave, and he shuts down the server. Now today the game is
> > totally over.
> >
> > Instead with a client/server all in one solution, there could be a
transfer
> > command, instead of just quitting.
> > transfer would send a savefile to one of the clients say b.
> > b would then take this savefile package and use it as input for his
until
> > now inactive server.
> > There would have to be some closing and opening of connections, the
other
> > clients, should get the ip of b
> > from a, and close there connection and reconnect to b.
> > All this could be done with just a few lines of code.
> > Actually it's still doable, but will require a little more work.
>
>   Huh?  This is MORE of a problem if the servers are 'integrated' with the
> clients.  How to do this now:
>
>   A closes his/her client, then backgrounds the server and logs out.
>

1) I pay for internet access for every minute i'm connected , i wouldn't put
it in the background.
It'll change to pay/mbyte traffic, and that won't matter, i would still kill
it.
Only people with free internet access like students would be able to do
that.

2) Can B,C or D save the game, that is control it like A can.

> > Another bonus of having server and client in one, would be that a
> > singleplayer game would take less resources, and there could be a dummy
> > network layer, so it would work on machines without tcp/ip.
> >
> > /Claus Leth Gregersen.
>
>   I'm not convinced that a singleplayer game would take significantly less
> resources -- how much data is really duplicated between the client and the
> server?  Maybe the map?  Most of my memory seems to go to storing pixmaps
when
> I do a single-player game..
>
I'm not advocating to do it, i don't think it's worth the trouble,
but removing the network layer would give you a performance boost.

Interesting polls would be:
* Do you play single or multiplayer freeciv?
* What kind of connection do you have?

Freeciv was and is still primarily a multiplayer game, and as such it's not
very tuned towards
playing solo. Maybe a few polls could tell what type of players there is out
there, so it could help
pinpoint for future keyfeatures in development.

>   Daniel
>
> --
> Who is General Failure, and why is he reading my hard drive?
>