[freeciv-ai] Re: ai bug when splitting up settlers

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 08:49 AM 02/05/15 +0200, Raimar Falke wrote:
>On Tue, May 14, 2002 at 07:38:09PM -0400, Ross W. Wetmore wrote:

>We have two different problems here:
> - which city have to build at which time a worker
> - if we have a worker how should it be used

Yes, and recognition of this is a key step, kudos.

>I have code for the second problem but not for the first one.

>> You would be better off keeping a running tally of the possible 
>> improvements to all controlled terrain with a quick shield/food/trade
>> weighted benefit scaled by the size of your Civ in cities or pop. This
>> would consume almost no CPU even if you did a full reset every few
>> turns as a sanity check. Set threshold levels on how many workers you 
>> need to maintain a given rate of growth. Rate of growth is a 
>> personality/management concept missing from Freeciv. 
>
>This is a solution to the first problem. Your solution is an extension
>to my solution from above. I want to check for the best not yet done
>improvement you want to check all or a subset (you can limited this to
>current_number_of_workers * 2) of tasks.

Actually, it is not. When I say a running tally, I mean a really trivial
count of the possible improvements as shield/food/trade totals. As a
per Civ enhancement I might scale each by the current *_WEIGHTING so as
to reflect the Civ strategy better. The reason for scaling by Civ size
is so I can gauge whether I am a perfectionist or have no interest in
improvements and thus if one in twenty of my tiles are improved I am
happy and don't need workers.

I would *never* extend your solution to do this.

Over a couple of turns I can predict if the current worker crop is going
to be swamped or run out of work, and adjust it accordingly. If the civ
enters an expansion phase, I clearly will be adding workload rapidly,
and if it then levels off into a consolidation, I can recognize that
while the workload is high, my worker crop has increased along the way
and with the diminished rate of additions will be sufficient, or may
even need to be decreased.

>> The same thing applies to building a new city. As an example, consider
>> the horrific Syela calculation tells you that A > B > C are the top
>> benefit locations.
>> 
>> But it ignores the fact that A overlaps with current or planned city
>> development and will in fact cost you 50% of its value because of packing
>> issues.
>> 
>> B is great, but on the other side of a river and in 150 turns will be
>> taken over out by your agressive neighbour because you could never get
>> it developed or integrated into your Civ in time.
>> 
>> C is the weakest according to Syela, but sits in the river valley which
>> 1) has tremendous initial growth potential, 
>> 2) allows you to run a road across the river before you discover
>>    bridge building
>> 3) is incredibly well connected via both the river movement and the
>>    road you will build so it can be resupplied and serve as a base
>>    for counter offensive units.
>> 
>> C in fact means that you will take over your aggressive enemy's city at
>> B in 100 turns.
>> 
>> The intricate detailed benefit calculations were just worth squat in 
>> reality :-).
>
>For the second problem you want a detailed analysis especially in the
>start.

Actually, you really don't need the kinds of details in eval_city_building.

All cities will essentially follow the same growth and lifecycle pattern
so you don't need to keep recalculating this constant base over and over 
again in excrutiating detail.

What changes are the strategic effects and the deviation of resources
from the norm, none of which are really looked at currently.

For example, doing an average and RMS average of each tile resource 
with a *_WEIGHTING version of the total over the city_map will tell 
you immediately if it is above or below average, with the RMS values 
telling you how diverse it is, i.e. if there are some large key
resources.

Doing the same for the best 5 food, 4 shields and 3 trade tiles will tell
you if it has good startup potential or a solid core resource base that
allows for flexible worker allocations. You might do this as both the 
minimum (undeveloped) and maximum (fully developed). The former will be 
more appropriate for the early game, while the latter applies to the mid 
and end game where you have an existing worker pool that can keep ahead 
of the city development.

Over time the weighting function can be adjusted to recognize a good
balance of startup growth, mix of terrain/resource types and maximum
potential.

To this you can add "bonuses" like river connectivity, sea access,
protective mountain or hilly terrain, new continent beachhead, or
"negative bonuses" too much improvement required (swamps/jungles), 
bad packing, far from core Civ base.

None of this takes a lot of CPU either.

For worker management in the CMA, you can really evaluate every
tile improvement benefit for the city once and store it as a list
of tasks sorted by weight. The benefit is a delta resource times
some sort of *_WEIGHTING factor, amortized if you can't live 
without this, but it really isn't that important.

When it comes time to allocate a new worker task, you can pick the 
highest benefit task for "currently" worked tiles, and the highest
benefit task for unworked tiles that would improve the tile to a level
at or above the next best unworked tile (in at least one capacity).

You might try adding in improvement effects, but I suspect that over
the long haul they won't be half as useful as say a city need effect
weighting, i.e. need more food, or need more shields. The improvement
effect will be taken into account by how much it diminishes need and
thus the time until this need resurfaces, i.e. indirectly over a 
series of improvement tasks, this will deal with amortize as well,
as a big long time effect, will presumably keep the city content in
that need category for a longer time until the need resurfaces.

>       Raimar
>
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
>  "Heuer's Law: Any feature is a bug unless it can be turned off."

Cheers,
RossW
=====