Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2003: [freeciv-ai] Re: New settler code v7

# [freeciv-ai] Re: New settler code v7

[Top] [All Lists]

 To: "Per I. Mathisen" Cc: Freeciv AI development Subject: [freeciv-ai] Re: New settler code v7 From: Gregory Berkolaiko Date: Wed, 14 May 2003 19:22:56 +0100 (BST)

```On Wed, 14 May 2003, Per I. Mathisen wrote:

> > * the division into cityresult_fill and city_desirability is not very
> > logical, you do some of the checks there and some of the checks here.
>
> Yep. I split it up for readability only...

Now it's cleaner, but still some cruft remains:

if (result->tile[i][j].food >= 2) {
sum *= 2; /* we need this to grow */
}
[...]
/* City center without lots of food is not good. */
if (result->tile[2][2].food < 2) {
result->city_center /= 2;
}
[...]
/* Avoid starvation: We must have enough food to grow. */
if (result->tile[2][2].food
+ result->tile[result->o_x][result->o_y].food < 3) {
result->total = 0;
return;
}

Please put them in one place.

Also, there is no need to initialize all result->other fields.
Besides, the present code will dump core when there are no tiles available
for the "other tile".

> > 4. In find_best_city_placement
> >   /* This ugly algorithm punishes long treks exponentially. */
> > This ugly (and here you are absolutely right) algorithm has nothing to do
> > with exponentials.The result of the computation (modulo interger arithm.
> > errors) is
> > result.total -= ai.perfection * (turns * turns + 3 * turns + 4) / 4;
> > Maybe we can simplify it to
> > result.total -= ai.perfection * turns * (turns - 1) /4;
> > (which is also quadratic) then and remove (turns > 1) condition, which
> > will be automatically ensured?
>
> Ok. But I used this algorithm instead:
>       result.total -= ai->perfection * turns * turns;
>
> It is quite harsh, but I was tired of seeing my settlers running all over
> the map in search of good positions. But this isn't quite good enough
> either. While this gives gives a want curve that slopes downward, we also
> want this curve to flatten out when it has reached low, to avoid it ever
> reaching quite zero. Since it now does reach zero, this code does not fare
> well in my constructed test savegame with difficult tasks for settlers.
> When the only possible place to make a city is far away, we never go
> there.
>
> Greg, can you come up with something?

I would actually use the true exponential ;)
something along the lines
result.total = amortize(result.total, ai->perfection * turns);

> Oh, and the new results:
> Quick view:  1  2  3  4  5
> HARD        66 72 82 55 66 turns
> EXP         51 47 56 49 46 turns
> EXP v2      48 48 48 50 40 turns
>
> A slight improvement overall.

Where did it come from?

> I did a speed test. Autogames on very big maps where we do nothing but
> settle cities for a large number of such, the new code is three times
> slower than the old. Ideas on how to improve this welcome.

Wow, 3 times...

I think you should have a look at the profile.

Also (especailly on big maps), old code looks at most 13 tiles away.
Path-finding does the whole map.  Early termination is your
responsibility!  For ideas on how to do it without forfeiting the chance
of finding far-away spots, have a look at Cameron's latest explorer
patch.

Also, the calling code might specify the minimum want it is willing to
consider and also the want it is guaranteed to accept.

G.

```