[Freeciv-Dev] Re: Scripting and client-side AI's

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Jan 10, 2001 at 12:25:42AM -0600, Bobby D. Bryant wrote:
> Raimar Falke wrote:
> > So IMHO it is not like asking a question and getting an answer. But
> > more like asking a question, have to answer a lot of questions and
> > later getting an answer.
> 
> Yeah, I left out a lot for the sake of simplicity.  Suppose you had a CNGCCB 
> and
> wanted to add scripting support for some decisions.  The first question 
> becomes, how
> does the script access the state?  Two obvious choices come to mind: (a) keep 
> track
> of the state within the script, and (b) keep track of the state within the 
> existing
> client, and let the script make callbacks whenever it needs more information.
> 
> I personally like (b) better, because it would make use of existing client 
> code for
> maintaining state.  That gets you back ahead in the maintainability game, 
> where most
> changes to the game would be made once, in the common client code base, and 
> you
> would only be forced to update everyone's AIs when you had game rule changes 
> that
> were so radical that they created new *kinds* of information, not already 
> supported
> by callbacks offered by the common client code.
> 
> System (b) would also be useful for clients based on neural networks, since 
> all they
> need is some inputs that they don't really have to "understand".  For such a 
> system,
> you would just call the callbacks relevant to the current decision, and feed 
> the
> results of those callbacks into your NN, and out pops the answer, which you 
> return
> as your black box's answer to "What do I build?", or whatever the question 
> was.

I also like (b) more. However thinking about the implementation
aspects this will need some kind of bidirectional information
flow. Both sides (the common code and the agent) have to make calls
and to answer calls. So the common code has to answer directly or
indirectly calls from various types of agents. Agents programmed in C
(GUI-agents, ai agents in C), Perl, Python, forked external programmes
(I.Q.'s approach),... Putting this all into the common client code is
too much. So there are translation layers needed, one for each type
(Perl, Python, forked external programmes, CORBA,...) of
communication. These will translate between the native interface (C)
and the preferred method of the agent.

This is an extendable design and easy to start (a noop layer for a an
ai agent programmed in C). 

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Despite all the medical advances of the 20th century, the mortality 
  rate remains unchanged at 1 death per person."