This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: AI now goes after bases
- From: Hans Ronne <hronne at comhem dot se>
- To: xconq7 at sources dot redhat dot com
- Date: Sat, 3 Jan 2004 07:04:56 +0100
- Subject: Re: AI now goes after bases
>>> 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.
Agreed. My point was essentially that the latter file already exists as
ai.c. That's where I would like to move some more ai stuff from plan.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.
Good point. And easy to implement. We could just use the mplayer as the
default. It's even easier to make a copy of the mplayer, though, and hack
it. That's how we made the iplayer.
>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.
>
>> 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.
Agreed. Axcept I think ai_go_after_victim should stay where it is is ai.c.
Hans