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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Jul 16, 2002 at 03:04:13PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Jul 16, 2002 at 02:22:01PM CEST, I got a letter,
> where "Per I. Mathisen" <per@xxxxxxxxxxx> told me, that...
> > On Mon, 15 Jul 2002, Ross W. Wetmore wrote:
> > > 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 believe the problem is one of terminology only. I don't disagree with
> > you here at all.
> > 
> > > There is every reason to put the AI into a self-contained address space
> > > at the end ofa packet stream or equivalent that means it interoperates
> > > with the server component in the same way (at the server) as clients
> > > currently do.
> > 
> > This is the idea, yes.
> > 
> > > I seriously doubt a real AI will ever be "reworked" into the current
> > > client.
> > >
> > > Library routines might be shared by the client and whatever form the AI
> > > takes.
> > 
> > Actually I don't think an "AI-client" needs to share any code with the GUI
> > clients. It will use code from common/ and client/ai/common/.
> 
> Then keep it in ai/ and please don't pollute client/ with it at all. As I 
> said,
> I think it's very confusing and unclear for everyone not deeply familiar with
> the strange directory hiearchy. After all, it's not user client (which is what
> client/ is for, I believe), but rather a "bot", new thing out there, which 
> even
> may, but must not, run a separate process. And ai/ looks like nice place for
> that. Or maybe bot/ or aidrop/ ;)) or so :). 

> BTW, what would be point of client/ai/common?

If the ai/-people want to use the CM(A) code where should this code be
placed? Either common/ai or client/ai/common but not ai/common.

> > > For now the AI is in the server address space. The first move should be
> > > to replace all calls into the AI from the server code with normal client
> > > packet send and/or receive actions, and develop a simple internal 
> > > connector
> > > that is basically just a packet queue system.
> > 
> > In some parts of the AI code we use packet structures which we push over
> > to handle_* functions that are the same as those on the receiving end of
> > packets. In order to turn these into code acceptable for a client they can
> > just be renamed to calls to the appropriate send_packet_* call.
> > 
> > Rewriting more code to use this kind of interface will bring us much
> > closer to clientifying the AI.
> 
> .oO(not even having to move anything)
> 
> > > It is quite likely during the process of extracting the current AI
> > > and cleaning up its various routines and helper functions, that there
> > > may be one or more tries at a from scratch, or at least fairly radical
> > > rewrite. If one of these actually looks promising enough, then a push
> > > on it is quite reasonable and shouldn't be discouraged.
> > 
> > A write from scratch should preferably be done as a client AI, and can
> > live comfortably side-by-side with the current AI. We already have two
> > such initiatives: Raimar's agents and Vasco's BORG AI.
> 
> As said many times, Raimar's agents aren't standalone AI. They [are designed
> to] handle, not coordinate. You tell them "I want that and that", but there
> must be something to tell them that, and that something must reasonate that
> from something. That's the coordination.

Yes and no. Yes you are right but if we have a hierarchy of agents the
top one at the top will be given the target "win" or "maximize your
score". So hopefully at some point in the future the agents will form
a standalone AI.

> The Syela AI contains both coordination and handling, but the coordination is
> IIRC the most part of it all, and it is also naturally much more difficult 
> (and
> at some level you just crack with your head to the NPC boundary and then it
> either is not perfect at all, is not very perfect and you cheat, or starts to
> eat vast amounts of CPU time as it tries to figure something out from the 
> chaos
> around it). I'm not sure how easy it would be possible to convience the Syela
> AI to use agents as handlers though.

Primary we don't want to share the handler code but the calculation
code. CM(A) and the auto_arrange_workers and co. Path finding
code. And maybe settler and SM(A).

> Oh, this reminds me about another thing - should "client AI" cheat?

This is in the archives.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This message has been ROT-13 encrypted twice for extra security.