Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: questions about agents
Home

[Freeciv-Dev] Re: questions about agents

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>, "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: questions about agents
From: Daniel Sjölie <deepone@xxxxxxxxxx>
Date: Fri, 5 Apr 2002 04:15:55 +0200

On 2002-04-04 20:32:22, Raimar Falke wrote:
> 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:
> > > 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 ;)

I'm with Raimar on this... :)

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)


[Prev in Thread] Current Thread [Next in Thread]