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

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 11:02 PM 02/07/15 +0000, Per I. Mathisen wrote:
>We have made plans for moving the AI eventually into client space. The
>first step would be to add common stuff into client/ai/common/, like city
>management (from CMA) and path finding. The second is to move the AI
>sources physically in cvs to client/ai/<AI name>/. The third is to
>actually make the existing AI work like a client. This plan is detailed in
>README.AI already.

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.

There is every reason to put the AI into a self-contained address space
at the end of a packet stream or equivalent that means it interoperates
with the server component in the same way (at the server) as clients 
currently do.

This doesn't mean it needs to go in the client process, and certainly
does not belong anywhere in the GUI part of the client. It is perfectly
reasonable to have it run in the server process or at the end of pipes
spun off of it as standalone AI-bots.

The key elements are
1)  The AI code doesn't directly access server structures and data.
2)  The AI communicates with the server through the same types of
    channels that a client does. Note, this can be queuing packets
    into/out of the server packet stream/handler.

If you concentrate only on the key elements, and not on the preconception
of one possible manifestation of it, you will be further ahead.

>Obviously this will have serious impact on AI development. So I want to
>know what you people think about this. There is no point moving stuff into
>client disk space if nobody plans to eventually rework the stuff into a
>client. Also this movement should not come on collision course with other
>AI work.

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.

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. 

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.

This exercise will teach two things. 

1)  How to do it - basic connector and module mechanics.
2)  How the current AI performs in a self-contained context and what
    any critical subset of routines, or packet API extensions might
    be.

You will be refining and generalizing the AI library as you go much as
some current projects are doing.

You will also have a working AI throughout the process to test with and
to get some fun out of.

>We can do the code movement in this dev cycle, but that depends on whether
>people here intend to start working towards making it a client in the near
>future.

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. 

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

Once things are taking reasonable shape and there is an obvious 
direction with general agreement, then do the source code rearrangement, 
i.e. first the horse, then the cart :-).

>Thoughts?
>
>Yours
>Per

Cheers,
RossW
=====