Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
[Freeciv-Dev] Re: release plans
Home

[Freeciv-Dev] Re: release plans

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Claus Leth Gregersen <leth@xxxxxxxxxxx>
Cc: Artur Biesiadowski <abies@xxxxxxxxx>, Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: release plans
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Fri, 24 Sep 1999 15:19:20 -0400

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.

> 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..

  Daniel

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

[Prev in Thread] Current Thread [Next in Thread]