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]

[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: Tue, 14 May 2002 23:41:40 -0400

At 10:59 AM 02/05/14 +0200, Per I. Mathisen wrote:
>On Mon, 13 May 2002, Ross W. Wetmore wrote:

>> It is a mistake to try and figure out what the "best" level of anything
>> is as well.
>It is a mistake for us to assume for the AI what is best for it, yes. It
>should do its own analysis and find out. But right now we need to curb
>some excess building behaviour.

Yes. General recognition of bad behaviour with checks and balances is
what is mainly needed on the management front.

Units are semi-autonomous and have a list of activities with weights
that they know how to do, i.e. for every activity there should be a 
function that computes the current weight/want, and code that executes
the activity. Recognizing these elements and isolating them into clean
functional code units would be a good thing.

A manager should be able to "program" the weight function by adjusting
key parameters, or set flags to force specific critical weight decisions 
or activity actions/checks. This means one wants to arrive at a set of
general functional parameters, or flags and a system for implementing
them, as part of the general weight function or action routine form.

The manager should also be able to analyze or determine bad behaviours 
to set these weights. Which means there need to be various statistics
or analysis routines they can call up.

Figuring out what the ultimate code is going to look like is an
impossible task, but one doesn't need to in order to get there.

For now most of this code exists but is all scrambled together. It is not
unreasonable to add more elements to the pot-au-feu, but one should try
to indicate what category the element is and keep it relatively compact
and cleanly interfaced. As things become clearer in sections, one can
then rearrange all the local bits into proper groups without changing 
the overall code flow or effect. Finally when things are well stratified
and tucked behind clean weight/action/analysis interfaces, one can redo 
entire modules without serious impact on the rest of the code if this
seems desirable.

Gradually cleaning up the current code with such a stratification in
mind will both get new ideas into play and suggest ways to deal with 
organizing everything. And it shouldn't require a big bang rewrite event.

>> 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
>What is "too many settlers"? If there are no threats on the horizon, if
>anti-ICS parameters are set very low, and we gain more long-term
>production, trade and science by simple building more cities (which is
>true now), then it should build settlers, settlers and even more settlers
>until there is a good reason not to.

So you have just defined a strategy and set of conditions to implement 
it with some sort of analysis/goals to use as the feedback. This is the 
basic growth strategy.

Your set of assumptions and actual measurement criteria on its success
are incomplete, but that just means that you will likely only win in
certain situations where things remain within the bounds of your coded
understanding. Someone with a better or more varied strategy will beat 
you if they can force the game into a different play mode or environment.

>BTW, Ross, can you take a look at my settlers.c cleanup patch? There are
>also two bugfixes for settlers.c in the bitvector flags patch.
>"As Israeli forces pursued militants, civilians
>continued getting in the way and dying as a
>result." -- New York Times, April 21

Ok, here is a quick review ...

For the most part the changes are innocuous and not unreasonable. But
they don't go anywhare near far enough in cosmetic cleanup and a few
introduce significant flow or performance change.

The real changes should be split out for further debate and the cosmetic 
ones pushed much further as in run the routine through indent and then
fix its style faults :-).

Specific comments prefaced with ">>>" in the attached gzip file.


Attachment: settlerscleanup5.patch.gz
Description: Binary data

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