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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, May 15, 2002 at 08:59:43PM -0400, Ross W. Wetmore wrote:
> 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.

Ok. I agree and understood expect this "scale by the size of your
civ". What is scaled? and how?

Do you know that you speak here about a list of multiple 1000s
elements in a midgame?!

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

Nice ideas.

> None of this takes a lot of CPU either.

No but a lot of parameters or a callback function which does all the
calculations.

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

I agree that something like this is needed for a (very) good
AI. However I think that to get a manageable (at the code base) AI we
have to seperate areas. So I'm pleased with the current first version
of CMA. It may have to be extended at some later point to collaborate
with other agents to be more efficient. The current SMA solves this
problem by this code:

+  if (is_currently_used_by_a_city(x, y))
+    /* the city WOULD benefit fully */
+    effective_percent = 100;
+  else
+    /* the city COULD benefit from it if the city grows or changes
+       its distribution of workers */
+    effective_percent = parameter->unused_tile_percent;

So there is a chance that a settler improves the tile and a turn
latter the CMA uses it.

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

I don't understand this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We've all heard that a million monkeys banging on a million typewriters
  will eventually reproduce the entire works of Shakespeare.
  Now, thanks to the Internet, we know this is not true."