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

["Per I. Mathisen" <per@xxxxxxxxxxx>]

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

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

> All calls within the AI to the server address space should similarly be
> replaced by a packet send and recv operation using the standard packet
> API.
>
> One may need to rebuild AI model data structures that mimic the server
> data but are updated only by packet events and any defaulting or guess
> code rather than make all data requests a packet op.
>
> Once the AI runs essentially in its own part of the server process, it
> would be trivial to move it to a forked process talking over a stream
> connector between the packet queues and the server. At the top level
> the current AI is not far off this goal.

Here I agree with Raimar: This is a very bad idea. In order to become a
client, you need to instantiate your own copy of the common code. The
alternative you paint here means duplicating the common code inside the
same process - a much bigger job.

> Clean things up in place until the general shape is a little more
> defined and a serious design including the architectural description
> of the components is agreed upon and at least partly prototyped to the
> point of being functional.

Cleanups should definitely go in first.

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

> Neither should
> any evolutionary or other process that people are strongly interested
> in be actively discouraged. Vigorous discussion is of course ok, but
> keeping options open at this point is a good thing (TM).

That is what is most important to me: We should choose the way to do this
that least hampers development. How much we improve the AI before we start
putting it into client directory or when or how we do it is secondary.

Yours
Per