Complete.Org: Mailing Lists: Archives: freeciv-ai: August 2004:
[freeciv-ai] Re: (PR#9623) Re: terrain improvers (fwd)

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: (PR#9623) Re: terrain improvers (fwd)
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>
Date: Sat, 7 Aug 2004 09:47:49 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: >

On Fri, 6 Aug 2004, Gregory Berkolaiko wrote:

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

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

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.

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 think the above design is quite workable now.
I have some thoughts on caching, but this can wait.


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