[freeciv-ai] Re: New settler code v7

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

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.