Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002: [freeciv-ai] Re: ai bug when splitting up settlers

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

[Top] [All Lists]

 To: rf13@xxxxxxxxxxxxxxxxxxxxxx Cc: "Per I. Mathisen" , freeciv-ai@xxxxxxxxxxx Subject: [freeciv-ai] Re: ai bug when splitting up settlers From: "Ross W. Wetmore" Date: Tue, 14 May 2002 19:38:09 -0400

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

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.

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

Cheers,
RossW
=====

```