[Freeciv-Dev] Re: questions about agents

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Apr 04, 2002 at 10:54:48AM -0600, Mike Kaufman wrote:
> On Thu, Apr 04, 2002 at 11:52:46AM +0200, Raimar Falke wrote:
> > On Wed, Apr 03, 2002 at 04:27:22PM -0600, Mike Kaufman wrote:
> > > > > 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.
> > 
> > The client currently doesn't need libcivai.a. This is good this so. I
> > don't want to change this. The ai directory is for the server ai
> > only. So it should really be moved to server/ai/.
> 
> Maybe I'm looking a little bit farther ahead than you are... Moving the ai
> to server/ai is a recipe for disaster. I want to get rid of the ai from the
> server altogether. I thought you did too. If we keep thinking that ai's
> place is in the server, then it'll just be longer to get it out.
> 
> _Currently_ the client doesn't need libcibai.a. The server does. I want to
> see that reversed. The server shouldn't need it. Period. Hopefully you agree
> with that. The client needs it because the client uses (or should/will use) 
> ai functions like ai_manage_explorer() as a simple example.
> 
> > > 
> > > 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?
> > 
> > For you the agents are just a glue between the real ai functions and
> > the GUI?! Right?. For me the agents include the real ai functions.
> 
> yes. GUI/UI/whatever. If a human wants to use a text interface, that's his
> business.
> 
> > 
> > > 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?
> > 
> > As I said I don't want the client to use the ai directory. Merging the
> > two ais wasn't in the plan. Instead of putting them in ai/ and
> > connecting them I want to put the common part (the core calculation
> > methods) into common/(ai/).
> 
> Arrgh. I can't see why you'd want to do this unless you keep thinking 
> about the ai in the server. I must agree with Per here. If merging
> the two AI's wasn't part of the plan before, it should definitely be the 
> plan now. It not only less than ideal to have separate AIs, it is
> counterproductive. I understand that most of the AI code is in sorry shape,
> and you don't want to touch it with a ten foot pole, but that is not a
> reason to give the ai the benefit of your work.
> 
> Please present your rationale why you believe that libcivai.a shouldn't be
> needed by the client. 
> 
> Why should ai functions be put in common/ when the plan is to separate the 
> ai from the server altogether? 
> 
> Why is it critical for agents to do calculations rather than calling into 
> the ai?

<put on the developer hat>

At the time I came to the final concept for the agents the code in ai/
scared me a lot. Now I understand the code a bit better and I see that
there are some diamonds in a lot of cruft. Coping/using the ai code
verbatim is still something which I want to avoid. The diamonds which
are worth it are some general concepts (amortization, bodyguard,...) 
but not the code. So I planned to (re)implement an AI:
 - where I understand all concepts
 - where the code isn't a pain to read
 - which is documented
 - with small interfaces
 - which isn't monolithic so you can replace parts with other algos in
 other other languages easily

I don't want to touch the ai/ directory and since all things are
client side this also isn't necessary. So no agent code will ever call
ai_manage_explorer. There will be an exploring agent which will have
this functionality but a complete different interface.

The server AI just gets better (in small steps) while I build up my
army of agents ;) If the agents as a whole can compete with the server
AI the server AI will be disabled/removed/the agents be the first
choice/whatever. Than I got maintainer.

<put on the maintainer hat>

In the long run the server ai should die. I know that it will be long
time till the agents (or another client side AI) can compete with the
server AI. This makes it necessary to maintain the server AI. I'm
against adding huge new features since in an ideal world all this code
would be second choice in some years.

We can with relative little time create a civbot using ai/. This would
give us client side AI. But not client side scripting since you
couldn't replace parts of the AI with say a GA in Java. This would
also not enable an average programmer to extend/manipulate the AI. So
you see client side is only one of the requirements.

Two seperate AIs in code also provide a bit of competition ;)

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Programming today is a race between software engineers striving to
  build bigger and better idiot-proof programs, and the Universe trying
  to produce bigger and better idiots. So far, the Universe is winning."
    -- Rich Cook