Complete.Org: Mailing Lists: Archives: freeciv-dev: February 1999:
Re: [Freeciv-Dev] Patch to improve persistence of games
Home

Re: [Freeciv-Dev] Patch to improve persistence of games

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Billy Naylor <banjo@xxxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Patch to improve persistence of games
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Mon, 1 Feb 1999 22:33:26 -0500

On Mon, Feb 01, 1999 at 04:13:57PM +0000, Billy Naylor was heard to say:
> On Sun, 31 Jan 1999, Daniel Burrows wrote:
> 
> >  Hi.
> >
> >  I think that a bug--or at least a missing feature--in freeciv is the 
> > ability
> >to play games that take a long time, and in which the participants are likely
> >to not be connected often. 
> 
>   I think this is very important.

  Good, glad to see someone else does. :-)

> >* Server autosaving 
> 
>   have 2 files, this_turn and last_turn, for a server this is all we need.

  What about the following situation:

  (a) a turn starts
  (b) player X connects, moves stuff, and then disconnects.
  (c) a few hours later, an X server crash takes the computer down.

  A realtime-periodic saving of games will save state even in this case
(assuming the data gets synced to disk); if we only save each turn, this will
result in toasting of the game.  :)

  (or is this what you meant--put the latest state in this_turn and move that
to last_turn when we start a new turn?)

> >* Dealing with transient connections -
> >                   The default behavior when a player drops connection is
> >              to skip them each turn; with my patch, the game waits for them
> >              to move.  This can be disabled by a server option.
> 
>   Will goto's etc be dealt with by the server, so that if you miss
>   some turns, (Real Life etc) you're forces still act on default orders.
> 
>   I think the speed could be set as 1 turn per X hours (where X can be
>   4 or 12 or whatever).

  I hadn't thought of this, mainly because I felt that missing turns shouldn't
be an option for a longer-term game. ;-)  Hmm.  Good point, I'll look into it.

> >  Displaying the moves could be handled by storing the info about the last
> >move made on the server until each player has gotten it, including players
> >who are temporarily disconnected. (is this done already?)
> 
>   couldn't moves that would have been sent to a player, be stored in a 
>   file (buffer) until the player retrieves them ?
>   Even several turns worth of data.

  Yes.  That occured to me after I sent the message. :-)

> >  -- The ability for a client to keep multiple sets of authentication for
> > games.
> 
>   Yep, both servers and clients need to be able to handle being involved
>   in multiple games.

  This is pretty much a problem of making a linked list or two and then
writing glue code to the GUIs.  I got the GTK+ client to compile on my system
and I'd like to avoid any further Xaw tinkering if possible.  If this patch
goes anywhere, someone who enjoys Xaw may have to help me merge any client
changes into the Xaw tree. :-)  (it shouldn't be too difficult, most of what
I'm doing will be backend)

> >  (the major barrier to my playing a game of freeciv against a human so far
> >is that it's hard to coordinate matters so that you are both connected
> >to the server at the same time for a prolonged period of time.
> 
>   yep, i'd prefer the option where you could have a turn every 4 hours.
>   The diplomacy (email) of 14 players playing a low key game over a 
>   couple of months, would suit me.

  Ok.  In case anyone's interested, I have a new patch against the version
of 1.7.2 containing the GTK+ client.  Both clients work with my modifications
to the best of my knowledge, but I'll probably make most of my further changes
to the GTK+ code.

-- 
  Daniel Burrows

  Nothing is hopeless.

  PROOF:
(a) Assume the opposite.
(b) If something _is_ hopeless, then its condition can only improve.
(c) If its condition can only improve, then there must be hope for it.
(d) Therefore, nothing is hopeless.  QED.

Attachment: pgp0e71IFpK9c.pgp
Description: PGP signature


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