[Freeciv-Dev] Re: questions about agents

[Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Apr 03, 2002 at 09:29:01PM +0200, Raimar Falke wrote:
> On Tue, Apr 02, 2002 at 03:55:26PM -0600, Mike Kaufman wrote:
> > On Tue, Apr 02, 2002 at 10:50:47PM +0200, Per I. Mathisen wrote:
> > > What are the current plans for Settler Management Agent?
> 
> I will restart working on it if the new release is out.
> 
> > > Is there any code, any specs or anyone working on it?
> 
> Only some (very) old code.
> 
> > > Is the plan to replace all the current autosettlers code with
> > > this, or just some of it?
> 
> Long answer: The general idea is to create/copy-modify code which
> handles the basic tasks (auto*) and also higher tasks in a fashion
> which is ok for client side operation. This ai-code and the "classic"
> server code will both be put into the CVS tree. If at some point the
> "new" ai-code is as good as the "classic" one and the civbot is coded
> the "classic" one can disabled/removed.
> 
> Short answer: server/autosettler.c and other ai/*.c and server/*.c
> won't be touched by new agents.
> 
> > > And move GOTO to the client (please)?
> 
> We have three users of goto (server, client and agents). If we can
> agree upon an interface and an implementation I would really to unify
> this and create a common/goto.
> 
> > > Why are we not using the agents code for the server-side AI? (I know I've
> > > asked about this before but I have forgotten the answer and it seems so
> > > strange I have to ask again.)
> 
> This isn't the plan. If you want to use agents at the server you have
> to either use the civbot way or have to look at this for yourself.

we should never even think about using agents in the server.

> 
> > As I have mentioned, I don't have the answers to these (Raimar has a much
> > better idea), but I do have some comments.
> > 
> > My feeling is that agents should simply be the interface between the client
> > and the ai.
> 
> What client? The client in "client and server" or the GUI client?

the client. by client I mean the thing that a human uses. With this
definition, "agents" is a particularly good term to use.

> 
> > citizen management, autosettler, autoexplore, etc are more
> > mundane things that the human client hands off to the ai to do. 
> 
> > It's code duplication and bad practice to have two different sets of
> > code do citizen management.
> 
> I agree. But the code in ai/ left me with no other choice. If some
> poor soul want to adapt the ai to use code of the CMA feel free
> so. However the resulting extract should be placed in common.

well, some poor soul really needs to, but the resulting extract should
absolutely not be in common/, it should be in ai/. common/ is [should be] for
code that is common to the client and server. the server should have
nothing at all to do with the core cma functions. It shouldn't even know
they exist. For now of course, since the ai library is needed by the server
(by virtue of the server running the ai), it will see it.

> 
> > Agents should do two things. Get directives from the client to tell the ai 
> > what to do and then request the server to do that thing. Using CMA as an
> > example, the agent should 1. get the goals from the client gui and ask the
> > ai function what worker arrangement best satisfies that goal directive. 2.
> > then send some packets to the server requesting worker rearrangement. All
> > the actually calculation should accomplished in ai/
> > 
> > Actually this might be a good first step toward a more rigorous ai
> > advisor type setup. The advisor in advdomestic.c presents goals---just like
> > the human client---to the core cma code which returns the best arrangement.
> > The advisor then implements that arrangement in the current server-ai
> > setup, or will send requests to the server in the future client-ai setup.
> > 
> > another example is the autoexplorer. Right now, we hand the unit off to the
> > server which calls ai_manage_explorer. In a perfect world, the server
> > should not be the one doing this. There should be an agent which manages
> > all the autoexplorers doing the calls into ai_manage_explorer, and then
> > send destination or move info to the server through the regular request
> > packets.
> 
> I see two points where we disagree:
>  - where should be code be placed client/agents (maybe with common/) vs ai
>  - whether we use the existing infrastructure in ai/ or not

see above on the first. I'm not sure I see your position. The agents code
itself should be in client/agents. The code it interacts with should be in
ai/ on the one hand, and packhand/guis on the other. Why would you have it
otherwise?

as for the second point, I want to do: for the interim add new files in ai/
that house the cma, sma, etc core functions. agents will use those
functions right off the bat. The functions should be general enough so that
ai can eventually use them. When we're ready, we punt the old worker
management and autosettlers code off the end of a pier (though some of the
old worker management stuff should be folded into the "city advisor")

What do you want to do that's different than this?

-mike