Complete.Org: Mailing Lists: Archives: freeciv-ai: August 2004:
[freeciv-ai] Settler code plans
Home

[freeciv-ai] Settler code plans

[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] Settler code plans
From: Per Inge Mathisen <per@xxxxxxxxxxx>
Date: Sun, 1 Aug 2004 13:30:54 +0000 (GMT)

You may have noticed (or probably not) that progress on the new settlers
code has been very slow. The reason for this is mostly that I am having
gnawing doubts about its design. While the patch as it is performs
considerably better than the current code, is much more readable, and is
somewhat more generalized, it is slower and is certainly not generalized
enough.

Most fatally, it has an implicit assumption in favour of smallpox. This is
vital for speed, and improves results - for the current rules.

But I do not have time to write a replacement at this time. So I can
commit the code as it stands, or let it wait. It is not code that will not
suffer much from bitrot.

In any case, here is my plan for another design of the AI settlers code:

On game start, analyze the map. Create a genlist of struct
wanted_city_spots { x, y, want }. When we consider building a settler or
consider where to send one, we find the closest spot on the same continent
and the closest spot anywhere, find the wants to settle those two, and use
the higher one to compare to other build targets.

In the beginning of the turn, we run through the genlist and check if
there are existing cities that overlap with spots in the list. If so
happens, mark that spot in the list as temporarily disabled. Clear these
marks every now and then.

We will not re-analyze the map. This takes too long. This means we will
not support extensive re-arranging of the map during the game. Global
warming and nuclear winter may change the whole map - the AI will ignore
this. The advantage is that this approach is fast, so we can spend more
CPU cycles on a more thorough analysis of the map on game start instead.

We can also print out the list after starting the game and very simply see
what the AI does wrong without watching long games carefully and debugging
reams of data from gazillions of calculations, most of which will never
bear fruit.

For the map analysis:
 - need a quick and greedy algo for ranking the all the tiles that can be
worked
 - nation.ruleset tells us which government we will use while analysing
   (and perhaps what buildings to assume)
 - amortize the results from the greedy algo according to size, so first 2
   (or 1 if no free city center) are unamortized, then amortize by (want,
   foodbox_for_growth_at_size / food_surplus_at_size)
 - analyse a city up until the size it no longer grows or some max size

Comments appreciated.

  - Per



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