[freeciv-ai] Re: time table for ai restructuring

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 12:31 AM 02/07/16 -0500, Mike Kaufman wrote:
>On Mon, Jul 15, 2002 at 09:40:27PM -0400, Ross W. Wetmore wrote:
>> At 11:02 PM 02/07/15 +0000, Per I. Mathisen wrote:
>> >We have made plans for moving the AI eventually into client space. The
>> >first step would be to add common stuff into client/ai/common/, like city
>> >management (from CMA) and path finding. The second is to move the AI
>> >sources physically in cvs to client/ai/<AI name>/. The third is to
>> >actually make the existing AI work like a client. This plan is detailed in
>> >README.AI already.
>> 
>> There is a terminology problem that I think is skewing your perceptions
>> and/or restricting your options. To repeat an earlier comment, agents 
>> are not AI, and their purpose as user GUI tools is not the model to use 
>> for a real AI.
>
>I agree with most of the rest of your post Ross, but this confuses me.
>I don't think Per is confusing agents with AI at all. I think he agrees
>with me that Raimar's code shouldn't go to waste. There's no reason why
>good (or at least ok) algorithmic code shouldn't be put as the disposal
>of the server-side AI.

My apologies since the above is clearly highlighting the agent, and not
the "client" aspect that the next and succeeding paragraphs explained in 
more detail. I think the agent stuff is very good as a "governor" model 
for augmenting user play. There is a lot of good low level stuff that 
should be common, or part of any libAI. Some day there may be a continuum 
of client/agent/ai modules or functionality. Agents are working from the 
client user tool side towards the centre compromise and thus are the 
opposite extreme from a real AI though.

Note a real AI does not need to be in the "client" process. It just needs
to get its fingers out of the server pie :-).

The terminology I think is limiting is the "move to the client" - there
are lots of options short of this, or off on a tangent. Thinking of things
slightly more generically at this point will help flush out some of the
better possibilities.

Moving the server AI towards this compromise is a better model for real
AI development at this time, at least in my estimation.

>The point I've been trying to make is that the idea that it's good to
>automate some tasks for a human is here to stay. For that to work, some
>mechanism needs to be present to do that automation. ("Agents" are a
>reasonable mechanism). As more automation is applied to tasks in the
>human-controlled client, the automated part becomes more ai based.

No problem with any of this - mom and apple pie sentiments abound.

>Why not place the heavy-lifting parts of that automation at the
>server-side ai's disposal. We cut down on duplication of code and
>effort. The server-side (eventually to become client-side) ai also gets
>the bonus of becoming a bit more modular.

The heavy-lifting parts are the ones I would leave behind. They are 
liable to be too targetted at a task environment that is not what a 
self suportting AI needs. For example the AI does not need a CMA
rather it needs a CMM :-).

A lot of the low level routines may be very useful. The libAI concept
is a great one to start on right now.

>The first exercise would be to take the city mananagement code (as
>distiguished from the agent that calls into it) and stick it in ai/
>The server-side ai doesn't have to (and probably won't) use it for quite
>a while, but it's there.

The level of detail of the CMA is useless to a real AI. And as I say, 
it doesn't need an agent to carry out policy under imposed constraints, 
it needs a manager to figure out policy under very liberal constraints
or ones it makes up on the fly.

>perhaps you're right, ai/ doesn't need to go to client/ai, but
>agents/cma_core.c (or most of it) needs to go to something like
>ai/common

Someday it might go there. I don't want to rule this option out either
at this point. 

The agents are really part of the client and their purpose is really 
client specific. The core agent code belongs there somewhere. Generic 
low-level functional routines without the agent philosophy built into 
them are great for a common library. Keeping the two parts modular and 
separate might be a boon as well as it will allow other agents to be 
quickly constructed from pieces with slightly different driving 
philosophies or tactical strengths :-).

But for now, figuring out what to do next, rather than the end location
is probably more in order. I still think there is some mileage to be
gained by squeezing on the existing AI before one starts over from
scratch and ends up with a 7-year project to get back to current 
capabilities.

I actually think it *could* be moved to the client lock stock and barrel. 
But taking this a few steps at a time will probably be quicker, and 
something may turn up along the way that results in a better 3rd option.

>-mike

Cheers,
RossW
=====