Complete.Org: Mailing Lists: Archives: freeciv-ai: July 2002:
[freeciv-ai] Re: time table for ai restructuring

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: time table for ai restructuring
From: Petr Baudis <pasky@xxxxxxxxxxx>
Date: Tue, 16 Jul 2002 15:04:13 +0200

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

> > 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.

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.

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

                                Petr "Pasky" Baudis
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI occassional hacker
You can get much further with a kind word and a gun than you can with a
kind word alone. -- Al Capone
Public PGP key && geekcode && homepage:

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