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

[Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>]

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

This is just a matter of simpleness and reducing network traffic. I
think it is acceptable. Which parts would you like to see removed from
the client?

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

In theory you're right, but the disadvantage is that they would be
lost on disconnetct or saving. This could be partly solved by having
an option for the clients to add opaque data to a savegame, but that
wouldn't gain you the advantage of the worklists working while you're
disconnected.

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

I agree that this would be a nice option.

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

This has the same disadvantages as mentioned for worklists.

> 2.a. in my programs, whenever i have a circular dependency, it
> indicates a logic error.

Usually it only indicates that you're inlining too much. Feel free to
provide patches :) (BTW, when compiling with the Compaq C compiler,
one gets lots of warnings about unused includes. I guess they're
mostly false, though...)

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

Yes, that would be nice. It would have to coded for all widget sets,
though, which is a bit too much work IMHO.

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

Well, there are reasonable cases where a special may appear on
different terrains, and handling specials independent keeps the number
of different tiles smaller.

        Falk