[freeciv-ai] (PR#9623) worker-unit want is too high

["Kevin Benton" <s1kevin@xxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=9623 >

> > Thoughts on terrain improvers:
> >
> > this is a try to give a quasi-scientific basis to evaluating terrain
> > improvements.
> >
> > Assumption: somebody else supplies resource weights, workers don't
have to
> > know about city's stagnated growth or negative trade balance.
> >
> > tile_value is basically resources we get from a tile multiplied by their
> > weights.
> >
> > benefit = tile_value_after - tile_value_before
> >   if the tile is worked and
> >         = tile_value_after - worst_worked_tile_value
> >   if the tile is not worked
> >
> > we assume that this benefit is "paid" to us every turn starting from the
> > moment the improvement is built, which is
> >
> > d = move_time + time_to_improve
> > (d for delay)
> >
> > q is the "inflation multiplier", currently (MORT-1)/MORT, used in
> > amortization
> >
> > the total benefit (till the end of time) that we will get from an
> > improvement is
> > total_benefit = benefit * (q^d + q^(d+1) + ...)
> >               = benefit * q^d / (1-q)
> >               = benefit * q^d * MORT
> >
> > mantaining workers also cost so
> >
> > cost = value of resources spent in one turn on mantaining the worker
> >     (in default rules = 1 shield)
> >
> > we will be paying them for d turns, so
> > total_cost = cost * (1 + q + q^2 + ... q^(d-1))
> >        = cost * (1-q^d) / (1-q)
> >        = cost * (1-q^d) * MORT
> >
> > total_benefit - total_cost would give you want of making the
improvement.
> >
> > This is all sweet theory but (1) it doesn't quite work with the present
> > weights and (2) might not work with any weights
> >
> > To give examples:
> > building a road on an adjacent grassland = 204
> > building irrigation on an adjacent grassland = 261
> > building mine on an unworked hill (assuming we will switch there from a
> > unimproved grassland) = 328
> >
> > I would build road first, then (maybe) irrigation and then a mine. 
It can
> > be argued that it's a matter of taste.
> >
> > But the biggest problem I see is actually making sure that a switch
to the
> > hill will be made.
> 
> After thinking some more...
> 
> Okay, the problem is to estimate the want of improving a tile which isn't
> worked.  For example nobody sane would work a hill without a mine.

I disagree.  Since combined improvement work goes more quickly than
non-combined work, building a road over a hill so multiple workers can
create the mine does a few things for us:  1) it improves the time to
travel over the hill when attacking/retreating/..., 2) it reduces the
amount of time other units take to get to the "helping point" and, 3)
potentially reduces the time cost to enter the square in the first
place.  Having a road lead up to a fortress on a hill makes a lot of
sense.  Having a road lead up to a high defensive point makes sense if
you're defending.

When playing against the AI manually, I like to improve things around
the city where a work was built first, then, afterward, let the worker
move on to other cities on the same continent.  Once a continent's
cities have been improved adequately, I move my workers/engineers on to
another continent where work is needed.  At this point, however,
automated workers/engineers won't take to the skies to cross continents.
 They also tend to like to do things to some of my tiles that I don't
necessarily want (changing buffalo for example).

> The benefit of improving not worked tile should be computed as
>   tile_value_after - MAX(worst_worked_tile_value, tile_value_before)
> 
> But we want to prevent the following from happening:
> a worker builds a mine on a hill
> city does not work this hill because it would cause lack of food
> the worker then builds mines on other hills around city...

I agree completely.  It seems to me that a worker would benefit from
sensitivity to the CMA to figure out what the player wants most.  If a
CMA ranks food highly, an automated engineer may (with an adequately
high score) terraform desert into plains.  OTOH, if I have Oil there,
and my CMA has production up high, I wouldn't want my automated unit to
change my mined / railroaded Oil to irrigated / railroaded Oil.  I am
wondering if it wouldn't make more sense to allow the worker automation
to specify a particular target city to be improved.  At least that way,
the improvements could be targeted for a particular city (say for
example, one building a wonder).

> Building one mine which is not worked is ok.  After all, it will probably
> be used later.  What is not ok is to build more mines when there are
> already too many.

I agree.

> A simple solution is to check whether the improved tile will have f-s-t
> triplet less or equal then of some unworked tile.  This check is
> relatively cheap.
> 
> This way, if a mine is unworked, the worker will not build any more mines.

I agree - that's a good way to figure it out.  The challenge is, how
does one compute the cost of having the worker unit travel to another
city to do something that will yield a very small benefit where if the
unit had stayed near the city it was supposed to work, it would figure
out that the tile that wasn't being used yet would be used in a few
turns at the next city growth.

> I think the above design is quite workable now.
> I have some thoughts on caching, but this can wait.

While I'm no expert in this area, I am enjoying reading the discussion
on worker decisions. :)