[Freeciv-Dev] Re: (PR#14923) Stupid AI Building Wants

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=14923 >

On Sun, 5 Mar 2006, Benedict Adamson wrote:
> Agreed. Note, however, that applying some of the fragments might make
> the AI peculiar (or stupid) until the remainder was added. OK provided
> we bear that in mind.

I do not see why that should be the case. Ideally we should add piece by
piece and measure improvements somehow.

> > Covering every possibility and obscure twist of the rules
> > makes for tons of code that is hard to follow.
>
> I'm not sure what you have in mind here.

I am thinking of code like the part where you add a penalty for wanted
government based on the increased upkeep of settlers. Why is this
necessary? Does the AI become better due to it, or does it make it less
capable (reaching Republic ASAP is vital in current rulesets)?

> > It is too hard to maintain.
>
> Oh dear. My intention was to produce something correct and easy to
> maintain. The current want computation code is neither.

I agree the current code is not good, but your patch adds a ton of
additional code, not just replacing old code. I suspect some of this
additional code may be attempting to do too much. However, we should
probably discuss this on a case by case basis.

> ...
> > advdiplomacy.c:
> > -worth = bulbs + tech_want;
> > +worth = bulbs + tech_want / TRADE_WEIGHTING;
> >
> > is this wise?
>
> Not only wise, but necessary for dimensional correctness. The units of
> 'bulbs' is 'bulbs'; the units of 'tech_want' is 'Want'. To combine them
> we must convert 'tech_want' from a 'Want' to a 'bulbs', which means
> dividing by a priority value; TRADE_WEIGHTING is a suitable value,
> although ai->science_priority would be better.

Yet the net result is that techs are traded for 1/12th the current value,
no? The AI would be selling itself cheap.

> > What is the pointwith this...
> ...
> > +static bool is_potential_settler(const struct unit_type *settler)
> ...
>
> You mean, 'what is the point of having this *in a separate function*'?

No, with all those seemingly redundant checks. I do not see the point of
always checking if the unit is a gameloss unit, for example - sometimes
producing a gameloss unit is the right thing to do too, and it definitely
does not become correct when this function is used to find other players'
unit types (as in the find enemy hunter code).

> > In ai_consider_attacker(), the attack_radius() function only looks a few
> > turns of unit movement outside the city. This will not do. The AI must be
> > able to attack far away targets too.
>
> That is an optimisation, to prevent the AI spending excessive time
> evaluating targets that are probably not worthwhile.
>
> The further away the target, the less the benefit of building an
> attacker, because our gain from victory will be amortised by the travel
> time to the target.

This is where I think important strategic objectives are lost in the haze
of amorphous wants. We need to recognize distant cities and build
attackers to reach them. One of the key problems of the current AI is that
it fails to build attackers and even attack any targets more than N tiles
away (I fail to remember the value of N). For big maps with lots of 'dead'
terrtain, like water, this is a crucial problem which stalls the AI. I
have savegames that can be used for testing this.

What 'want' fails to realize is that everything the AI does has only one
goal - to win the game (in a manner that is fun for the human players).
Taken to the extreme, the want logic would have the AI rather build up a
massive empire than do an early sneak attack of the enemy which wipes them
out, since the former generates tons of want while the latter gains no
want at all (the enemy size 1 cities are all razed).

So we must keep in mind the limitations of AI want.

> The computation cost of distant targets is probably excessive if we
> compute the attacker want for distant targets every turn, as the code
> does now. Perhaps the AI could instead compute the want for attacks on
> distant targets (or just cities?) less frequently, as we do for the
> computation of improvement wants.

Yes. We desperately need a new attack code that can do massed and timed
attacks, and do so over greater distances and with a variety of troop
types.

  - Per