Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2000:
[Freeciv-Dev] Re: the things i dislike about freeciv
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx (Freeciv developers)
Subject: [Freeciv-Dev] Re: the things i dislike about freeciv
From: Reinier Post <rp@xxxxxxxxxx>
Date: Sat, 14 Oct 2000 13:14:51 +0200

On Fri, Oct 13, 2000 at 10:00:48AM -0400, Jamie Kawabata wrote:
> 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?

Most of your points ae well known, some are accepted as too hard
to correct, some are being addressed gradually.  The unnecessary
interdependencies for instance are decreasing, but very slowly.

Some comments.

There is a reason for putting things like worklists and goto in the
server: lag!  This is a conscious decision.  Freeciv is still fairly
playable over poor connections because of this server side automation.
If more elaborate automation is ever added it will benefit even more
from being in the server.

The reason for putting nation names into the server is a different one:
they are used by players to communicate with each other, so the server
must know them once they're chosen.  The method of choosing could be at
the client side of course.

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

This is nontrivial to solve, how to make all of > 20 nations pairwise
distinguishable?

> 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'm not sure what you mean - T brings up the dialog.
 
> 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.

There's too much server specific code in common/, this is explained in the
"hacker's guide": functionality has been shifted to the server over time.

-- 
Reinier



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