Complete.Org: Mailing Lists: Archives: freeciv-ai: January 2003:
[freeciv-ai] Re: (PR#2644) AI needs 5400 years to get Republic
Home

[freeciv-ai] Re: (PR#2644) AI needs 5400 years to get Republic

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ue80@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#2644) AI needs 5400 years to get Republic
From: "rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>
Date: Tue, 7 Jan 2003 21:15:00 -0800
Reply-to: rt@xxxxxxxxxxxxxx

At 03:01 PM 03/01/01 -0800, Gregory Berkolaiko via RT wrote:
>Quoting "rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>:
[...]
>> Taking issue with your own limited view so you can move beyond it is
>> a good sign.
>
>Translation: admitting you are stupid means you are not beyond hope :)

Actually a more positive translation is ...

Setting up a strawman so you can knock it down, is a very useful technique
to get beyond the first stage understanding :-).

>> There are at least two models for applying the feedback constraints.
>> First one can do the simple and obvious count constraint
>>   if (!RANGE_CHECK(min, count, max)) want = 0
>> But a more useful approach is to build a feedback function with some
>> sort of linear, quadratic or other behaviour than simple step function
>> and the various thresholds and scores as its coefficients and variables.
>>   want = feedback_adjust(want, min, max, cummulative_score)
>>     or
>>   want = feedback_adjust(want, &min[], &max[], &cummulative_score[])
>> 
>> You will note, the first is just a trivial hardcoded example of the
>> more general second forms.
>> 
>> Since, the cumulative_score may adjust anytime one adds a new city, 
>> grows population, or any other factor you build into them, calculations 
>> of want may change on a turn by turn basis, or may not. One might be 
>> able to optimize using the information for any given case, but the
>> need or frequency of this is largely an orthogonal issue.
>
>Give me a practical model.  Or, at least, describe what you mean by 
>"count", "cumulative_score" and where "want" comes from.

One can lead a horse to water, but one cannot make him th^H^Hdrink :-)

Want is the usual AI parameter. 
Count is what Rahul used, something like a simple count of units. 
Cummulative_score[] are the variables of the more generic function 
representing the various counts or more generally scores that one 
computes perhaps by accumlating them over time (try understanding 
the pollution model).

>Here is what I thought of: 

Hey, he drinked ... not beyond hope :-).

>1. Each time a city decides to go for an aggressive unit, the barracks want
>should be bumped up.  This barrack want should accumulate, the simplest
model is
>  new_want = old_want * INFLATION_COEFF + increment

Ok. Good idea, now lets generalize ...

In the general terms, your cummulative variable is "barrack_want".

Someone might call this "military_need" and the min[] max[] values 
would be the "military_perfectionist range/index" of the personality. 
Genghis Khans scorn anything but in the field training, while Chinese 
Emperors spend endless amounts on training improvements.

>2. It should be adjusted according to the production (even better --
potential
>production) of the city and how it compares to the national average --
here is
>an opportunity to softly introduce barrack quota.

You could keep a per city local accumulated value as well as the Civ-wide
global in much the same way as local and global corruption and waste
should be done, or per city and global pollution/warming are.

The local production factor is good, as it means that the barracks can
crank out units when done. For a library, you want high trade. For
high food you want temples and marketplaces. Hopefully, when the city
next evalutaes its build, it will adjust building wants using these
factors and choose a barracks here, a temple there rather than always
putting barracks ahead of temples.

>3. The barrack want should overspill into the SUN_TZU want.

Or the feedback_adjust() for barracks and SUN_TZU should both have high
min[]/max[] values for the appropriate military_need. The SUN_TZU might
include social factors like Civ3 culture, "culture_aggressive" in addition
to "military_perfectionist" in its feedback function.

>4. The want should compete against other similar wants (and tuning it is the
>difficult part).

So make a big general function in "n" personality variables/scores with
appropriate min/max coefficients for each improvement/unit/action. The
simplest function is a static coefficient like the current want values
for improvements, but one could add linear or quadratic terms in 
personality elements over time. min[]/max[] may be useful for Simplex
algorithm constraints, rather than just an upper/lower bounding function
or one could just use a single want_adjust[] for a single-valued function.

>Ross, if you want to make a patch for this or any other model you think up,
>please do so.  I will work on it with you, but you must take it easy and 
>(a) not refer me to the corecleanups :)

But you want practical working examples :-)

>(b) try to make the changes localised -- it makes it easier to read and
easier
>to find time for.

I think the discussion phase on something like this is still open, so
kicking the ideas around a bit more with several different viewpoints
may actually start to suggest the sorts of timid fixes that could be
done to move the current codebase towards something like this over time.

What you want now is a general goal and/or plan rather than a lot of oneoff
half-baked attempts that go nowhere. Then one can gradually fill in pieces
consistent with the plan/goals so you actually finish a big project in
bite-sized piece mode that seems to be the desired or limiting modus
operandi all maintainers soon fall back on.

For example, unify the current improvement and unit want calculations 
along the above lines. The current function could just include the static
constant term until you figure out what the best personality dimensions 
are and the sorts of statistics accumulations or computations are needed
to provide the linear term variables.

Think about this as a solution to the mega tweak constant problem. Either
fold tweak constants into the function or figure out how to generate
tweak constants from existing coefficients. The things that these constants
currently adjust must be some sort of linear combination of the sorts
of cummulative_score variables one might want to consider for the 
personality dimensions.

>Best wishes,
>G.

Cheers,
RossW
=====






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