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

[Gaute Strokkenes <gs234@xxxxxxxxxxxxx>]

As I've stated before I am not a Freeciv developer, but...

Jamie Kawabata <kawabata@xxxxxxxxxxxxxxxxx> writes:

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

Quake is a very different beast altogether.  The client _has_ to
include a great deal of native inteligence, since the network is just
to slow to have a completely dumb client.  This is also why you can
create Quake programs that allow you to see through walls, and so on.
Off course, this is not an issue for Freeciv.

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

Freeciv is really based on the concept of a server that does all the
book-keeping and a client that is really just a way for a player give
orders to units and cities.  I don't think there's that much to be
gained by changing that.

> i think a preferable way of doing things would be a well-defined
> protocol and much less shared code.

The protocol is fairly well defined, and most of the shared code is
just book-keeping of various sorts.  There are a few warts where the
client is more intelligent than it should be; if you were to come up
with patches for this then they might very well be accepted.

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

The problem here is that the various kinds of units are defined in
rulesets, and it is very convenient to keep all this information in
one place.

> 1.c. i think internationalization should be pure client side.

I think everyone agrees on this one.  [There is still a need for a
common charset to transport city names, but e.g. UTF-8 could easily be
used for that.]

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

I am inclined to agree.  You'd have to come up with a way to handle
savegames etc. , though.

> 1.e. city name suggestions and nation names should be pure client
> side.

I don't think there's any need for that.  A way to override default
names more easily (i.e. not having the same stupid name being
suggested every time you build a city) and some more randomisation
would just about do it.  Remember, the city name lists live in
rulesets, which are read by the server.

> 1.f. goto should be pure client side.

I think Thue is working on this.

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

Whoopsie.  Maybe the vsnprintf() buffer should be allocated at
startup.  (And what happened to my patch to make native vsnprintf()
and friends usable on platforms where -1 is returned on overflow,
anyway?)

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

I'm not sure what you're getting at.  It is both logical and
convenient to have a header file include other header files that it
logically depends on.  The FC__FOO_H defines guarantees that you won't
get into trouble by including a file more than once etc.

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

I agree that the Taxes dialog is a bit too basic.  I would be happy
enough if it were to show and update the income and research rates as
they are updated in real time.

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

Shrug.  He who writes the code gets to do it in a manner that is
convenient for him.  I think this way it is a lot easier to add
different kinds of flags in rulesets.  In any case, it is trivial to
come up with a bijection between types-with-flags and
types-with-flags-incorporated.

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

What do you mean, exactly?  I don't see how that makes it any less
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.

Well, it sure beats writing the same function two times over (once for
the server and once for the client) or having the client drag around
intelligence that it doesn't need.

You could come up with preprocessor tricks to do the same thing,
however then you would have to compile everything twice (which is
simple enough, but you have to jump through hoops to make the build
process do that in a vaguely sane manner.  Yuck.)

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

What really surprises me is that someone has come up with a critique
of the Freeciv code and failed to mention the grotty/nonexistent
coding style...

-- 
GS