Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2000:
[Freeciv-Dev] Re: timeout patch
Home

[Freeciv-Dev] Re: timeout patch

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Robert Rendell <rob@xxxxxxxxxxxxxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: timeout patch
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Tue, 25 Apr 2000 17:12:18 -0400

At 2000/04/18 01:39 , Robert Rendell wrote:
>
>Hi - I've hacked the version of freeciv a bunch of us have been using for
>our own nefarious purposes, and then thought it might be of more general
>interest.
>
>The basic intent was to allow us to run a game with predictable updates
>(after a more rapid initial stage), so we could have, say, 2 turns run a
>day, and people could connect and do their turns and disconnect again...
>True, civ isn't as well suited to this style of play as PBEM and other such
>games which typically have weekly updates, but we thought it might be worth
>a go (having burned three afternoons while at work playing turn-turn-turn
>:)
>
>Anyway, so, I added an option to the server, fixedlength, which means that
>the only way the turn advances is through a timeout - it ignores players
>hitting the "Turn Done" button.  I also increased the maximum timeout you
>can set, which in turn required some changes to the timeout display in the
>client, so it comes up with, say, 40m rather than 2400 (seconds).
>
>Then we noticed that a connecting client doesn't start the timeout clock,
>because it doesn't know when the turn started.  So, I changed the way
>timeouts work, removing the static time_at_turn_end, and putting a field in
>the game structure, turn_start, which is sent to the clients.  This also
>meant that changing the timeout would affect the current turn, which I also
>wanted.

This is all a good idea.  But, I see some potential problems with the
implementation.

First, and most serious, is that your implementation seems to assume that
the clocks on the server and clients are synchronized fairly closely.  I've
found that assuming that any two computers' clocks are synchronized to
closer than about two centuries is a bad assumption ;-)  I see machines
that are off by 100 years every few months; machines off by hours are
common; machines off by a minute or few (which would, I believe, really
mess up the client/server synchronization) are the norm, not the exception.

Rather than communicating the time of turn start, send the time remaining
in the current turn to the client (i.e., compute seconds_to_turndone in the
server, and ship it to the client).

Second, you need to internationalize your strings.  Since they are short,
nondescript strings, I'd recommend something like the following:

  for minutes, use "?minutes:%dm"
  for fractional hours, use "?hours:%.1fh"
  for integral hours, use "?hours:%dh"

(wrapped with _(), of course).  This way the various translators can
translate the suffix characters.

Third, since you've changed the protocol, you need to add a capability
string.  It's best if you can make it optional.

Finally, rather than repeating the countdown string formatting code, you
should put it in one place, and call it from both clients.  In
./common/shared.[hc] is the typical place for these little helper functions.

jjm




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