Re: AI now goes after bases

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hi Peter, others,

On Sat, 3 Jan 2004, Peter Garrone wrote:

> I think that bit of code does some silly things sometimes, like telling
> sea-bound troop transports to attack aircraft in the middle of a
> continent.

It probably does. There is really nothing preventing it from doing 
so at this point. I will look into addressing this issue after the 
7.5 release. Basically, my changes were intended to address a 
behavioral issue that I found quite annoying in the AI. 
There are more, and I have much broader, bolder plans for AI 
revision once I feel at liberty to do them (after 7.5). You 
certainly mentioned a relevant area to look into.

> However I have found this discussion beneficial in that I will endeavour
> to not change this code while trying to get the ai to fight properly
> with plan_transport and refueling while pathfinding. Some observations

Well, aside from the little discussion I had with Jim, I don't 
intend to make any more functionality changes to it until after 
the next release. If bug fixes need to be made, I will certainly 
make them. Also, I still need to farm some of the logic out into 
separate generic evaluator functions, since victim_here is 
currently looking a bit bloated (and there is a lot more that 
could be done with it).

> I dont see much benefit from saying cities are more important than
> mobile units, by a factor of 10.

By cities, are we talking about all builders or just immobile 
builders?

As far as factors go, I left the actual victim scoring code alone; 
it is the same as before. I have plenty of ideas for that as well; 
victim_here may not even be the place to do the scoring, just the 
weeding....

> Selecting different units based on too many criteria leads to
> disorganised melee-like warfare, 

I was more into _rejecting_ units based on many criteria. :-)
Selecting the best ones is another matter entirely, and I mostly 
agree that the scoring should be fairly straightforward without a 
lot of twists and turns.

>and the different ai-controlled sides
> tend to lose spatial organization.

Hmmm.... Not sure that I follow you here.
If anything, the increased number of rejection criteria have the 
benefit of spatially concentrating attackers on the fewer number 
of victims considered worthwhile.

> Adjacent enemy units should always be attacked. 

Why?

>But if an enemy unit is
> not adjacent, then only units having equal or greater mobility should be sent
> after them, perhaps. 

Also depends on whether a lesser mobility unit has enough ACP to 
reach and attack the defender that turn before the defender can 
move (assuming sequential play).

>I think mobility is the key criteria here, and
> ability to operate on the same terrain as the opponent unit.

I agree on the latter point. I have already done some speculative 
thinking on both, but I don't want to swing the wrecking 
ball before 7.5, and possibly cause breakage that would further 
delay the release.

> Looking at the victim_here code, I think the initial idea was to give
> all possible targets a rating

Correct.

> I disagree with the implementation of code to return immediately
> when certain targets are detected,

As do I. This, however, was in the code that existed prior to my 
changes, and I opted to leave it rather than have additional 
changes in go_after_victim, and so on in ever widening circles. 
There is a big difference between my vision for this code, and 
what I did. The reason is simple: we are trying to get a release 
out the door, and changing gobs of code does not particularly 
help that effort in most cases.

> because it tends to detract from the
> code organisation. It should simply assign a rating to the target.

Agreed.

> Perhaps something could be done at the doctrine level, if not the

A damage ratio threshold might be a nice addition to the unit 
doctrines. I already do a damage ratio calculation in the new 
victim_here code, but perhaps it is not aggressively tuned enough 
or there are other behavioral factors elsewhere?

> planning level, so that if the odds are too great,
> the unit will run away, to fight another day.

The damage ratio calculation doesn't compel a unit to run away, 
but is supposed to prevent it from going after something that can 
kick the crap out of it. But knowing when to retreat is something 
I want to deal with as well (not in victim_here or 
go_after_victim, of course).

> With a bit of care, some self-organising mass-attack behavior might occur.

I have been considering having each AI side maintain a list of 
tactical coordination objects that could be searched by unit 
planners. The tactical coordinators would have things like the 
unit (or list of units) requesting the coordination, and those 
willing to provide it. Tactical coordinators could come in 
different flavors, such as TC_FORCE_PROTECTION, TC_GANG_ATTACK, 
etc... Vulnerable units could put in force protection requests. 
Units that could take down a more powerful unit, given sufficient 
numbers could put in a gang attack request. So on and so forth.... 
Just an idea I have been toying with; need to think it through 
more.

> I have discussed not sharing plan and task level stuff, only action
> level stuff, with networked games. When this is done,
> differing planning and task code will be allowed for different network
> clients playing the same game, and different ai strategies can be tested
> directly by combat, which should be fun.

I agree. I share your stated goal of thoroughly separating the 
action (referee) level things from the task and plan (AI) level 
things. I have also previously mentioned that I would like to 
invoke an AI as a separate client process, which would be the true 
test of such a separation.

> I am not advocating doing this now, though if someone were to implement
> these or other ideas, I would not object.

I have expressed interest in doing this post-7.5, and am willing 
to work with you on it.

How are the changes to the pathfinder coming along?

Eric