This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AI now goes after bases


On Wed, Dec 31, 2003 at 02:10:25PM -0500, Eric McDonald wrote:
> Hi Jim, others,
> 
> On Wed, 31 Dec 2003, Jim Kingdon wrote:
> 
> > playing the standard game, and I noticed that the AI will now flatten
> > my bases (using fighters and bombers), and it generally didn't used to
> > do that.
> 
> Hmmm... The new victim_here code is also supposed to gauge whether 
> a capturable transport (mobile or immobile) can withstand getting 
> roughed up a little to see whether a unit can give it a "shake 
> down" to discover/kill any occupants the transport might have. Of 
> course, I had Bellum Towns in mind when I wrote that part of the 
> code, and those Towns regenerate some lost HP every turn. Also, 
> Bellum Towns are builder units, whereas I don't think Standard 
> Bases are. If I remember the code correctly, I let it go ahead and 
> mark non-builder capturable transports as potential victims 
> indefinitely (pretend Transports were capturable in the Standard 
> game; you would probably want to pound those until they are below 
> sea level, hopefully with occs included). But perhaps the victim 
> finder should make an assumption that capturable, immobile 
> transports are "facility" or "base" units and spare them an 
> untimely death before being assimilated by the AI's side?
> 
> > been using to beat the AI.  If the AI played to capture the bases
> > instead of flatten them, that would probably be even better.
> 
> Agreed. Unless someone sees a problem with assuming capturable, 
> immobile transports are worth saving, I will modify the AI's 
> victim finder to account for this. (And violate my self-imposed 
> Xconq feature freeze yet again.)
> 
> Eric

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.

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

I dont see much benefit from saying cities are more important than
mobile units, by a factor of 10. If an opponent were composed entirely
of cities, it would be an easy job to defeat them, so it cannot be said
that cities are more important than mobile units.

Selecting different units based on too many criteria leads to
disorganised melee-like warfare, and the different ai-controlled sides
tend to lose spatial organization. If the attack criteria was to hit the
nearest unit irrespective, then that does lead to more organised sides,
I think. Unfortunately this doesnt work for things like aircraft
intrusions.

Adjacent enemy units should always be attacked. But if an enemy unit is
not adjacent, then only units having equal or greater mobility should be sent
after them, perhaps. I think mobility is the key criteria here, and
ability to operate on the same terrain as the opponent unit.

Looking at the victim_here code, I think the initial idea was to give
all possible targets a rating, and to hit the target with the highest
rating. I disagree with the implementation of code to return immediately
when certain targets are detected, because it tends to detract from the
code organisation. It should simply assign a rating to the target.

The AI also tends to send units on suicide missions.
Perhaps something could be done at the doctrine level, if not the
planning level, so that if the odds are too great,
the unit will run away, to fight another day.
With a bit of care, some self-organising mass-attack behavior might occur.

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 am not advocating doing this now, though if someone were to implement
these or other ideas, I would not object.

Peter


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]