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

[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: "Gregory Berkolaiko via RT" <rt@xxxxxxxxxxxxxx>
Date: Wed, 1 Jan 2003 15:01:53 -0800
Reply-to: rt@xxxxxxxxxxxxxx

Quoting "rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>:

> Actual numbers are perhaps best determined by letting GB playtest :-)

Right... :(

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

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

Here is what I thought of: 
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
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.
3. The barrack want should overspill into the SUN_TZU want.
4. The want should compete against other similar wants (and tuning it is the
difficult part).

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 :)
(b) try to make the changes localised -- it makes it easier to read and easier
to find time for.

Best wishes,

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