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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, May 14, 2002 at 07:38:09PM -0400, Ross W. Wetmore wrote:
> 
> At 11:13 AM 02/05/14 +0200, Raimar Falke wrote:
> >On Mon, May 13, 2002 at 02:35:36PM +0200, Per I. Mathisen wrote:
> >> On Mon, 13 May 2002, Raahul Kumar wrote:
> >
> >> Syela's general idea is correct - we should calculate the benefit a
> >> new city can give us.
> >
> >> > We could build workers based on the minimap idea you had. The workers
> we need
> >> > is based on no of umimproved tiles in city radiuses, the amount of
> time it
> >> > would take the workers we currently have to improve them, aargh it
> gets hard
> >> > already.
> >> 
> >> Yes, it becomes hard. The above is about the same approach as Syela chose.
> >
> >I also think that this is the correct approach. You have to calculate
> >how much you would gain from an extra worker. A fast approximation
> >would to virtually allocate the not yet produced worker to the city
> >tile which will improve the most and compare the costs (shields, time
> >to produce, time to improve) with the benefit (extra production of the
> >tile, an extra worker (in the worst case it is still worth half the
> >production shield)). If this turns out negative and also the same
> >checks for all the near cities you shouldn't build the worker. This is
> >an approximation because the best tile may be allocated and so
> >improved before the unit is produced. You can now make a more detailed
> >calculation which tiles can be improved in n turns (where n is the
> >number to build the unit) but this may be hard.
> >
> >     Raimar
> 

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

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

> This sort of micromanagment technique is actually a very poor strategy. 
> You build a worker for long term benefits, not the current few tiles it 
> might improve. 
> 
> And the overly detailed calculations Syela did in many of these cases
> are just a waste of CPU and programmer cycles.

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

> Cities in an underdeveloped area may not be the best ones to produce 
> workers as they may be in growth mode themselves. But rather you want to 
> use the more established cities or those hitting a pop barrier like 
> aqueduct as baby or worker factories. 
> 
> Your technique actually stifles growth and builds in the wrong places
> both because it concentrates on the wrong parameters and it completely
> ignores the more strategic concepts.
> 
> When workers look for tasks, *then* you need a more locally constrained 
> but better analysis to decide which is most important next. 
> 
> But using the latter detailed analysis to decide when to build a worker 
> is just unsophisticated foolishness. 
> 
> 
> 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.

        Raimar

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