[Freeciv-Dev] Re: the things i dislike about freeciv

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

On Fri, 13 Oct 2000 Jamie Kawabata <kawabata@xxxxxxxxxxxxxxxxx> wrote:

> basically the problems i see are these:
> 1. poor division between client and server.

To address some of your points, I'd like to step back and discuss some
basic design decisions about client-server relations in Freeciv.  (Ie,
my retro-fitted interpretation of current situation.)

Axiom 1: The server enforces the rules.  Thus theoretically clients
(eg user-modified clients) cannot "cheat", because the server will
disallow invalid requests etc.

Axiom 2: Only the server (in general) knows the full game state.
Clients don't know about unexplored map regions, and full info about
other players etc.  Again, if done correctly this prevents "cheating
clients".

Axiom 3: Graphics belong in the client.  This allows clients to -- in
principle at least -- use different graphics formats (PNG, XPM etc)
and different tilesets (engels, trident etc).

Axiom 4: The game rules should be configurable to support various
civ-type games.

From the above basics design decisions, the points below follow:

Point 1: From Axioms 1 and 4, the rule definitions (called rulesets in
Freeciv) must be defined in the server.

There is some conflict between Point 1 and Axiom 3, since alternate
rulesets may involve alternate graphics (or different use of existing
graphics).  In Freeciv this is handled by each graphic tile having a
"name" (short string).  Rulesets refer to graphic names, which are
communicated to clients.  Each client then maps these names to
particular tiles in the client's tileset.  This does mean that if the
rulesets use completely new graphics, the clients must have the
appropriate tileset available on the client side.  This may be
considered a shortcoming, but is difficult to get around given 
Axioms 3 and 4.

Point 2: From Axiom 2, saving and loading games must be done
server-side.  Only the server has all the info.

Point 3: From Point 2, any game-specific "persistent" information in
the client should be communicated to the server, so it can be included
in savegames.  (This also allows nice effects if have multiple clients
connected to the same player, since they can share "state" via the
server, although the trick of multiple clients is only a recent and
experimental feature, and not used much.)  (Trying to save data
client-side instead would be complicated, I think.)

> 1.b. i think graphic_str and graphic_alt packet structure elements
    should be eliminated.  graphics should be pure client side.  the
    client should be smart enough to render the screen without
    hand-holding from the server.

See above; for alternate rulesets, the client cannot know what
graphics to use without some hints via the server!

> 1.d. i feel that worklists should be purely client side.  they are a
    user-interface convenience, and ought to be fairly easy to
    implement client-side only, as long as there's no penalty for
    switching production the turn after something has completed
    building.

The main problem with this is savegames, see Point 3.

> 1.e. city name suggestions and nation names should be pure client
    side.  partly this is a philosophical objection, that the server
    shouldn't be so involved with names of nations (other than
    guaranteeing uniqueness) and city names.  in Civ 1 i could name my
    country whatever i wanted.  with freeciv i'm stuck if i want a
    country called "Mathland" and cities "Cauchy" "Bernoulli"
    "Leibniz", etc.  well at least i can rename each city as i build
    it.  it would be nice if i could configure my own personal country
    name and list of city names.  the only tricky part is the flags.
    i'm not sure how to handle that one other than to have each client
    upload the tiny graphic at game start.  (but of course i should be
    opposed to that, too, since the server should take no part in
    graphics!)

Nation definitions, including city names, are done in Freeciv using
rulesets.  This is mainly because its relatively simple and
straightforward to do them that way, and there are complications if
consider other ways.  So you _can_ make customised nations, but have
to do so server-side.  It would be nice to have client-submitted
nations, but rather complicated to do it "right".  Would probably end
up with client uploading a full nation ruleset to server, and the
server then saving the contributed nation for subsequent use.

> 1.f. goto should be pure client side.  again this is mostly a
    philosophical objection, since goto is very much a user-interface
    convenience.  i guess some people would like way points and
    road-to commands.  they belong in the client too.

See other posts; its nice for gotos to be in the savegame, and to
continue effect if client disconnects.

> 2.a. in my programs, whenever i have a circular dependency, it
    indicates a logic error.  logic error or not, interdependence of
    code makes maintenance harder.  support depends on mem.  mem
    depends on support and log.  log depends on mem and support.
    suppose my very first fc_malloc fails (and i'm logging, and i
    don't have native vsnprintf).  fc_malloc fails and calls freelog,
    which calls vreal_freelog, which calls my_vsnprintf, which calls
    fc_malloc.  oh dear.

Hmm, yeah.

> 2.b. header files include other header files.  circular references,
    if any are almost guaranteed to cause problems.

Given this "guarantee" you should be able to point out a practical
problem for Freeciv, right? :-)  I think in practice most genuine
problems of this sort will be found at compile-time.  So this problem
can make development harder, but once you sort things out its not too
bad.

> 3.a. i was playing as hungary and one of the opponents was dutch, i
    think, and i could not at-a-glance distinguish my units from
    theirs.  that was a while back. it might be fixed by using one of
    the new tile sets.

Freeciv uses mostly "real-life" nation flags.  So if some pairs of
nations have difficult-to-distinguish flags, I don't see a good way
around this problem.  You can chose to use "solid colours" instead of
flags from the client options, though that is not as nice generally.
Perhaps each client could (optionally and independently) decide which
flags to display locally for each player :-)

> 3.b. the tax/science/luxury mechanism is a pain to use.

Do you mean the clickable display on the main window, or the separate
dialog?  I've never got comfortable with the clickable display, so end
up using the dialog, which I find ok.

> 4.b. in game.c, in the function game_remove_unit, there's "if
    (is_server) dealloc_id(unit_id);" that's the only thing preventing
    the common code from being self-contained.  and something about
    the "common" code having to test to see if it is the server just
    gives me the creeps, i don't know why.

Yes, this is an awkward kludge.  It wouldn't be too hard to get rid
of; eg could probably do away with dealloc_id and friends completely
by using full 32-bit range for id.  Or by using idex to check whether
a prospective id is in use.  Or simply have the server register a
callback for dealloc_id above; if not registered (eg clients), do
nothing here.

> epilogue.  many of these complaints are internal structure issues
  and probably early design decisions i disagree with.  i don't expect
  them to be fixed.  they would be hard to fix, though it's really
  very easy to bitch about it.  that's why i complain so much!

One thing in Freeciv's favour on these issues is that Freeciv is a
real working game (eg, not "vapour").  So Freeciv's design decisions
are to some extent "proven to work", although of course not
necessarily "optimal".  (But this does not address ease of hacking 
on the Freeciv codebase etc.)

> flame me if you like, i don't mind.

You idiot!  ;-)

Regards,
-- David