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: Hans Ronne <hronne at comhem dot se>
- Cc: Peter Garrone <pgarrone at acay dot com dot au>, <xconq7 at sources dot redhat dot com>
- Date: Sat, 3 Jan 2004 00:39:40 -0500 (EST)
- Subject: Re: AI now goes after bases
Hi Hans,
On Sat, 3 Jan 2004, Hans Ronne wrote:
> That being said, the low level ai code could be more sophisticated.
Yes. Much more....
>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.
Yes. I even introduced a few of the above-mentioned factors simply
because the infrastructure did not exist for choosing optimal
values in a given situation. Of course, I introduced them with the
mental note that they would be replaced with more sophisticated
evaluators or perhaps even outputs from a neural net or some such
in the future.
> 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.
Yes, but aside from all the little utility calculations and
evaluators, some of that AI code is directly associated with plans
or with tasks. Plan-related generic AI should either be in plan.c
or else a new file aiplan.c. Similarly for task-related generic
AI. AI-player code should not be there, though. If someone
modifies mplayer and wants it to use something different than
plan_offenseive (or, more properly, ai_plan_offensive), then
mplayer_plan_offensive should go in mplayer.c.
So how do you reconcile which function to use?
On initialization, you create registries of function pointers for
different families of functionality, and initially the generic AI
would register all of the ai_* functions in their appropriate
slots. Then as AI-players did their initializations, they could
opt to use the generic AI functions, or register their own
substitutes in the appropriate slots.
Then, things like plan_offensive simply become wrappers for
invoking a function pointer based on a lookup in, say, a plan
registry, based on the calling AI.
> 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.
I think some tactical considerations are okay, provided they do
not make any major assumptions. But, I agree that strategic
considerations do not belong at the task level in the long run.
> Third, it is in my experience very important to consolidate all ai code
> that does one thing in the same place.
I agree, and that is my argument for leaving generic AI code in
plan.c and task.c.
> 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
I personally believe that the generic victim_here
(ai_victim_here) and other tactical decision-making code should
be as sound as possible, even if that means expanding it, or
refactoring the problem. I would like to see someone be able to
throw together an AI by initially relying on the same generic AI
code that could be used from an UI, and then providing
replacements as development on the new AI progresses. The generic
AI should be strong enough for this purpose and to provide an user
reasonable behavior from a UI.
> This can be done already now, at the ai level
Yeah, but now we essentially have duplicated code with
go_after_victim and ai_go_after_victim. I personally would just
rename things like go_after_victim to ai_go_after_victim, leave
them in plan.c, and go from there.
Just my US$0.02,
Eric