Complete.Org: Mailing Lists: Archives: freeciv-ai: July 2004:
[freeciv-ai] Re: New settler code v17
Home

[freeciv-ai] Re: New settler code v17

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv AI development <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: New settler code v17
From: Per Inge Mathisen <per@xxxxxxxxxxx>
Date: Thu, 1 Jul 2004 12:24:58 +0000 (GMT)

On Thu, 17 Jun 2004, Gregory Berkolaiko wrote:
> It looks quite good. Syela way to estimate want for the tech is to
> pretend we can have the simplest boat, calculate the want and use it as
> the tech want (but not use it as the settler want of course). This is a
> clever way but possibly a bit slow. By me, a WAG is fine.

It is a much better way, though. I'll consider it.

> 1. Can we commit it and then tune in situ?

Yes, but I am still unhappy about speed. Here I probably need to do
dramatic changes to the patch in order to improve it significantly.

> 2. Can you give me some maps where it stumbles?

I can send you later.

> 3. Can you describe in detail how you measure the performance (and add
> this info to README.AI too).

I write a script file with fixed rand seeds, then run this with both
'hard' and 'experimental', then compare the resulting gamelogs. Quite
easy, really.

> > Perhaps also more speed up is desirable - I am considering doing a more
> > general static map of the world to cache more tile data.
>
> I am also considering a world map to hold various info for the AI. Each
> player should have one. What do you mean by "static"? Not reallocated
> every turn or one for all AIs?

Not recalculated every turn. Eg the tile values are mostly static, only
modified by goverments, land improvements and city improvements.

Most of the time is spent updating city production, I believe, not sending
existing settlers around. So if we can remember our want for settlers from
the previous turn (for a number of turns), we can avoid much unnecessary
CPU usage.

  - Per




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