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

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Cc: <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: ai bug when splitting up settlers
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 13 May 2002 23:25:04 -0400

At 02:13 AM 02/05/13 +0200, Per I. Mathisen wrote:
>On Mon, 13 May 2002, Per I. Mathisen wrote:
>> settlers.c:void contemplate_terrain_improvements(struct city *pcity)
>...
>> This fix seems to be necessary. This code was copy&pasted from the
>> F_CITIES code by whoever did the F_SETTLERS and F_CITIES split. I bet
>> there are a lot of other issues he did not fix also.
>
>Alas, the AI has no checks and balances on building of workers. It doesn't
>build all that many settlers since cities can't bear the food costs. And
>when it does build too many settlers, it merely ships them off to another
>island to settle down. Since we can't do the latter with workers, it
>builds way too many and they don't know what to do.
>
>The entire code must probably be rewritten. It might attempt to estimate
>how many workers are needed on that continent and then build max that
>many. Then it could ship excess workers off the island. Aaarrgh. That will
>not be easy. Any other ideas?

Your comment on checks and balances is the right tack.

I also suspect there is not enough general understanding of the problem
or of various techniques for solving it to do a rewrite yet. This will
just produce yet-another-brain-damaged-and-half-complete solution. While
it is irritating, a gradual cleanup or the interfaces, and introduction
of lots of little self-contained activity or analysis functions that are
grouped and built upon as subunits may gradually fragment the monolithic
AI into understandable chunks. Doing the rewrite by rearrangement and
reassembly of these sub-parts may be both less traumatic and more
efficient as there is a reasonable level of current AI ability, even if
it appears to be occasionally lacking, and is far from obvious how it
is done.

It is probably a mistake to split settlers into two non-convertable units, 
at least at this stage of the AI. You really need the flexibility of all 
types of activities to balance things out, as the original code did and 
you are finding out. Once the controls are more sophisticated and analysis
refined, it may be possible to zero in on subtle effects and details, or
do longer term planning with various multi-part activity goals.

It is a mistake to try and figure out what the "best" level of anything 
is as well. First consistently hitting the top few, as opposed to the
bottom few is going to be just fine, and better than most humans. It is
better to have rough estimates of lots of effects than detailed breakdown
on only a few. The only ones you need to really be concerned about are
the radical deviations from the norm.

A better strategy is to place negative feedback levels on bad behaviour
with good/bad determined at whatever present time. Lots of little nudges
will keep things in a balanced region. This is the check and balance
rather than micromanagement solution.

The trick is to figure out what good and bad are, and to come up with
reasonable feedback effects. If you are grwoing too many settlers, then 
the want value for settlers should be scaled down, and those that exist 
should move to the periphery and plant themselves. If you have too few
the want value should be boosted and those that are around concentrate
on improving terrain, i.e. the want for this activity is boosted, at
least relative to founding, and maybe relative to all other unit tasks
so there is a competitive edge to nudge cities to build settler units.

If you insist on splitting the types, then workers should go join 
smaller cities to raise them to rapture levels, or to exploit resources.
roading hills and mountains, or transforming terrain are also good
activities for surplus workers with two workers tasked per tile. But
right now the "join city" is probably part of founding and (mistakely)
off limits to your workers.

Properly ordering the weights within an activity set, and providing
appropriate scaling functions/effects between sets will do a lot to
help manage the control aspect. Activities need to be complete enough
to provide real shifts to cover a wide number of feedback scenarios.

>Yours,
>Per
>
>"As Israeli forces pursued militants, civilians
>continued getting in the way and dying as a
>result." -- New York Times, April 21

Cheers,
RossW
=====




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