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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jul 15, 2002 at 09:40:27PM -0400, Ross W. Wetmore wrote:
> 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.

Nice idea but this will require more work than you think. All map
functions for example access the server map. You will have to
duplicate common/map or add a parameter to every function. Same with
civgame game and the players in it and all the other data structures.

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

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Only one human captain has ever survived battle with the Minbari
  fleet. He is behind me. You are in front of me. If you value your 
  lives, be somewhere else."
    -- Ambassador Delenn, "Severed Dreams," Babylon 5