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


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


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