[freeciv-ai] Re: Opinions on some AI issues

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Thu, 20 Jun 2002, Per I Mathisen wrote:

> On Mon, 17 Jun 2002, Gregory Berkolaiko wrote:
> > I. Technology selection by AI.
> >
> > Right now the AI evaluates units (and I
> > guess buildings) that it can build to select the build but it also
> > evaluates the things it cannot yet build and if they are found useful,
> > the want of the enabling techs is bumped up.  IMO it is a very good
> > philosophy.  Unfortunately it is hard to maintain, hard to generalize, it
> > encourages spaghetti-coding and slows down the server.  Also it is hard to
> > weigh importance of musketeers on the same scale as importance of
> > cathedrals.
> >
> > Instead I suggest that tech slection be done randomly, based on some
> > general tendencies.  We can define few general tech directions, like
> > Social, Economy, Military.  Then we can have base weights for each civ
> > plus some situational modifiers (e.g. a lot of cities in danger -- go for
> > Military, too many elvii -- go for social, empty coffers -- go for
> > economy).  The next tech will be selected randomly with more probability
> > going to the more desired directions.
> >
> > This is a very basic idea.  It can be made more complicated (and therefore
> > flexible, I hope), by several means:
> > 1. Split basic directions
> >                  Military
> >             /        \
> >       Defense        Offense
> >      /       \
> >     Buildings       Units
> >
> > 2. Each tech can have a precomputed score in each of the directions.
> > You combine (scalar product) these with the civs weight and it becomes the
> > probability of this tech's selection.
> >
> > 3. Each civ can have it's character reflected in the base wieghts.
> 
> And these tech weights should be in the rulesets? No, thanks. Rather
> calculate these weights in game start. The ruleset author is not in a good
> position to know beforehand what tech strategies are going to be good and
> which are not.

If you can calculate the weights in the code, you have an algorithm and 
can therefore ask the ruleset author to apply it, if he is dumb.  And he 
can also have some freedom, if he knows something about his ruleset that 
the designers of the algorithm did not take into account.

> > %%%%%%%%%%%%%%
> > IV. Invasions.
> >
> > Invasion targets should be selected on a high level.  The current
> > "everybody is going there so I go there too" attitude is pathetic.  But
> > what is a good city to attack?
> 
> A group of poorly defended cities connected by road or rail is always the
> best target. The capital is always the second best target. The nearest
> enemy is rarely the best target.

What is a "poorly defended city"?  Is it better to go for a 4-pop city 
with one defender or for 6-pop with 2 defenders?


> We can write complicated functions or we can make rulesets complicated and
> trust ruleset authors to know how to give the AI good hints. My vote is
> for the former. Often ruleset authors don't know what units are good
> before their ruleset has been tested a few gazillion times. A calculating
> will help here. It is easy change the balance of which unit rocks with a
> tiny change with unforseen effects, which will not be reflected in AI
> hints, but may be picked up by the complicated function.
> 
> Also, for some very complex rulesets, it may not be apparent which units
> will be available at the same time as other units are. So it is not
> impossible that Riflemen are the best attacking unit. Hardcoding it as a
> defender would be wrong in that case.

It is not impossible for non-standard rulesets.  For the standard one the 
cannon (artillery, howitzer) is always a better attacker.  And it has a 
flag "AttackStrong".

And don't you think that ruleset authors are dumber than the AI coders.

In any case, there should be functions 

is_strong_attacker
is_fast_attacker
is_good_defender

so whether we opt for complicated code or just ruleset flags, the changes 
would be localized.  Also, with such functions we can combine two 
approaches.

G.