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


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

So how is it going with the path-finding? Any hope of fixing the remaining
bugs?

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

I disagree. In most games cities (or more specifically any units that can
build other units) are easily 10 times more important than any mobile
units. Provided, of course that new units are built at a reasonable rate.

That being said, the low level ai code could be more sophisticated. There
are a lot of hacks right now, not only in victim_here, but also at other
points in the low level ai code, where factors 2, 5 or 10 are used rather
arbitrarily. I have replaced some of this stuff with either pre-computed
worth functions or doctrines, but much remains to be done.

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

I agree with that. This is why I wrote the action-reaction code, which
works exactly like that: by attacking adjacent enemy units as quickly as
possible.  In fact, some of the recent discussion about victim_here is kind
of moot since short range fighting is run by the action-reaction code
instead.

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

The advantages of broadcasting only actions in network games is something
that most of us agree on. However, even if that is implemented, I would
like to move more ai code from the plan and task level to the ai proper.
There are several good reasons for that:

First, it would make it easier to write and test different AIs, using the
existing pluig-in structure (e.g. mplayer vs. iplayer). Right now, there is
so much ai code in plan.c and task.c that a new ai would not make much of a
dif´ference.

Second, a better separation of AI and task level code is desirable since
the latter is used also by the human interface. The task code should
therefore be only about how to implement specific orders, whether given by
the ai or a human. Accordingly, a task should just be a logical chain of
actions without any tactical or strategic considerations.

Third, it is in my experience very important to consolidate all ai code
that does one thing in the same place. Otherwise, you will end up with race
situations where different parts of the ai code compete with each other. We
have had ample examples of such problems in xconq. For this reason, I am a
little wary about expanding the ai code in victim_here and other low level
ai functions too much. I would rather try to improve the tactical code in
ai.c and the mplayer.

Hans










This can be done already now, at the ai level



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