Complete.Org: Mailing Lists: Archives: freeciv-ai: March 2003:
[freeciv-ai] Re: [Freeciv-Dev] (PR#3689) server/settler.c
Home

[freeciv-ai] Re: [Freeciv-Dev] (PR#3689) server/settler.c

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ue80@xxxxxxxxxxxxxxxxxxxxx
Subject: [freeciv-ai] Re: [Freeciv-Dev] (PR#3689) server/settler.c
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Tue, 11 Mar 2003 04:59:53 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Mon, 10 Mar 2003, ue80@xxxxxxxxxxxxxxxxxxxxx wrote:

> after i found the routine which is responsible for the bad cityplacement
> from the AI here some thought on it.
> 
> static int city_desirability(struct player *pplayer, int x, int y)
> 
> Why don't we create a "warmap" for cityplaces? There are so many
> comments like "save CPU" in that function that i think it could be
> helpful to do it so.

We do.

> static int evaluate_city_building(struct unit *punit,
>                                 int *gx, int *gy,
>                                 struct unit **ferryboat)
> 
> Why do we only look at the next 11 squares? With boats we can do up to 
> ~90 fields distance with an engineer in 11 rounds.

Because Syela hoped it's enough.  I don't believe it's the main problem.

> In general AI isn't able to grow the same rate as a human player because
> its not building enough cities (and when building them on the wrong
> places)... so the calculation for the benefit from a new city may be
> calculated wrong.

Yes.  But this comment isn't helping.  How would you calculate the benefit
of a new city?  Do you assume some "typical size" and calculate what the 
city of this size can harvest?  Do you check that the city can reach this 
size?  Do you assume that we will build a harbour?  Do you check that we 
will be able to build harbour?  What about irrigation?  Will we be able to 
build / support a settler to build the irrigation?

Let's have a look at city_desirability.  It is quite clever, only maybe 
too clever for it's own good.  It first initialises "goodness" of future 
city squares and then emulates the dynamics of city growth.  Unfortunately 
to do this it needs to make many assumptions, too many.

I guess the best way forward would be to first clean the routine up 
(I believe we have something to learn from it) and then try to formulate a 
better (simpler) solution.  Or just polish the existing one.

Any takers for the cleaning job?

G.




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