[freeciv-ai] Re: (PR#9623) Re: terrain improvers (fwd)

["Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>]

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

On Fri, 6 Aug 2004, Benoit Hudson wrote:

> Here's a CM-centric way of doing it.  Too expensive for now, but with
> a better dynamic CM algorithm we might be able to do this:
> 1- compute the fitness for each city that can use the square, unimproved.
>         [that is, run CM allowing it to use that square]
> 2- compute the fitness for each city that can use the square, improved.
>         [that is, run the CM again, but increasing the square's value]
> 3- use the maximum difference for any city.

yes
The problem is, of course, that (2) has to be done for each improvement on
each tile in each city.  Fully-blown CM computations would burn the CPU.

> Probably we want to scale the CM weights so they sum to 1 so we can compare
> cities directly.

yes

> The current big cost is going through all the CM's combinations and
> deciding which is best.  Step (1) we can cache at the start of the turn:
> every city just remembers its fitness and its best combination.  So it's
> fairly cheap.
>
> Here's an approximation that may work well enough for step (2):
>
> If the current best combination uses the tile, then just compute the
> same combination with new tile, and use the difference as our benefit

this is exactly what I proposed

> If the current best combination does not use the tile, see if you could
> switch exactly one tile out of the current best to use the new tile.
> That is, loop over each tile in the current best combination.  Each
> time, compute the fitness if you'd used the new tile instead of this
> tile.  Report the largest improvement, 0 if it's never better.

this is similar to what I proposed

> Both of these are only approximate, but very fast to compute.
>
> The approximation comes from two things: constraints, and roundoff from
> computing bonuses.  We might currently be using a 1/0/0 hill to get
> enough food rather than the 0/1/6 gold mine, but when you irrigate
> grasslands suddenly you have enough food to use the mine, so while
> before the gold mine solution wasn't feasible, it now is.  I don't think
> this source of error is bounded.

there is also the possibility of 2-to-2 switch

worked: 2 irr.plains(1s2f)
not worked: an irr.grassland(3f) square and a hill(1f)
constraint: 4food, 2shield
after building a mine, you cannot switch from one plain to a hill -- you
won't have enough food.

> If we get really fancy, we could also take account of the city growth.
> Improving a tile so the city grows faster can make a big difference in
> the medium to long term.

This is hard.

G.