This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: AI now goes after bases
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Peter Garrone <pgarrone at acay dot com dot au>
- Cc: xconq7 at sources dot redhat dot com
- Date: Sat, 3 Jan 2004 00:11:05 -0500 (EST)
- Subject: Re: AI now goes after bases
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