[Freeciv-Dev] the things i dislike about freeciv

[Jamie Kawabata <kawabata@xxxxxxxxxxxxxxxxx>]

to state all the good things would take forever, so to keep it short, i'm just 
going to list the bad things.  you don't have to get all defensive, ok?


basically the problems i see are these:
1. poor division between client and server.
2. most parts of the code depend on nearly every other part.  no information 
hiding.
3. minor graphics issues.
4. minor code issues.


1.a. client and server share a lot of code.  no big deal, really, although one 
might as well have every client also have the option to be a server (like 
quake).  i bet newbies would like that.  anyway, the sharing of code, in 
itself, is not a problem, but i don't agree with having stuff in the server to 
make the client's job easier.  i think a preferable way of doing things would 
be a well-defined protocol and much less shared code.

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.

1.c. i think internationalization should be pure client side.  the protocol 
between client and server ought to be language-independent.  no messages, 
except perhaps "willkommen," from the server make it to the client (e.g. help 
text).  this is true for the most part.  it is not the server's responsibility 
to have to speak every language simultaneously.  it's an interface thing.  if a 
unit is to be called a "Cannon" then perhaps it should be #defined UNIT_CANNON 
in the client and server, and only the client knows about the string 
"Kanonenbein".  as for help text, well, i believe it doesn't have any place in 
the server at all.

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.

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!)

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.


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.

2.b. header files include other header files.  circular references, if any are 
almost guaranteed to cause problems.  if a.h needs to include b.h, and b.h 
needs to include a.h, then what happens is a.h includes b.h, and b.h attempts 
to include a.h, which is a no-op, since FC__A_H is defined, and so b.h has all 
kinds of undefined references, unknown types, etc.

2.c. and this is a more personal complaint, is that the interdependency of the 
pieces of the code makes it hard to use just a part of the code.  actually it's 
not that hard.  i managed to create stub versions of some of the functions i 
wasn't using, and then the higher order dependencies went away.


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.

3.b. the tax/science/luxury mechanism is a pain to use.  anyone ever play 
SimAnt?  they had a neat little triangle doodad that was pretty cool.  i don't 
change tax rate very often so it's not a big deal.


4.a. the way the terrain is set up, with extra fields for specials, it seems 
like it could be better handled by having an entirely new terrain type for 
forest_with_game, hills_with_coal, ocean_with_fish, etc.  have a field for 
river.  this would keep the data structures and handling routines simpler.  i 
have a funny suspicion that the reason it's set up this way is to make 
rendering on the client side easier, though i doubt it makes it any easier.  
sure, maybe if there were ever whales on plains.

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.


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!

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

-jamie

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup