[freeciv-ai] Re: time table for ai restructuring
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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
> Library routines might be shared by the client and whatever form the AI
> 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
> 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
> 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
> 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 :-).
"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