[freeciv-ai] Re: New settler code v7

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Tue, 13 May 2003, Gregory Berkolaiko wrote:
> Code is great and the numbers you provide are amazing.

Thanks.

> 1. In citymap_reserve_city_spot:
> * in the comment you talk about city_mindist.But there is no sign of it
> in the code.
> * you use city_map_checked_iterate but don't use city coordinates, it is
> confusing
> * in the second iterate you again increase the positive values, why?
> can't you do both in one iterate?
>
> 2. In citymap_free_city_spot there is a condition
>   if (citymap[x1][y1] == -id || citymap[x1][y1] == id) {
> why is the second condition there?

Ugh. Leftover legacy code. Fixed.

> 3. In cityresult_fill and city_desirability
> * the condition in
>   } else if (!city_center) {
> is not needed. city_center case is already caught by the previous if

Nice catch.

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

> * in cityresult_fill if !virtual_city you adjust by corruption.When you
> return to city_desirability you happily overwrite the adjusted value by
>   result->total = result->best_other;

Ick. Fixed.

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

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.

> 5. A comment: placing cities on the spots worked by the non-allies is not
> just possible, it's a clever thing to do!

1) It is dangerous to build so close to the enemy in any case.
2) Building right on top of a worked tile _might_ be a good idea (usually
not, see 1), but assuming it is not taken, is not a good idea, since the
tile _is_ taken.

So I think this behaviour in citymap.c should stay as is.

Also fixed: We now check if our current mission is possible before moving
towards our goal. The checks are: can build city at x,y and goto is
possible to x,y.

New patch attached.

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.

  - Per

PS Files that were not changed are not attached.

newsettler8.diff
Description: Text document

citymap.c
Description: Text document

aisettler.c
Description: Text document