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

["Bobby D. Bryant" <bdbryant@xxxxxxxxxxxxxxx>]

Raimar Falke wrote:

> On Tue, Dec 26, 2000 at 01:38:31AM -0600, Bobby D. Bryant wrote:
>
> > But that requires updating your yet-another-client everytime something is
> > checked in to CVS for the regular clients.  I won't object if that's what 
> > you
> > want to do, but I'm certainly not interested in going that route.
>
> It depends how much code is shared between the non-gui client and the
> other clients. The non-gui client can shares code with other clients:
>  - to understand the protocol which is spoken between server and
>  client and
>  - to perform some caching of information which it does get from
>  the server. The other clients need this mostly for redrawing
>  while the ai client would use the data as input for decisions.

I will go out on a limb and say that it's "obvious" that there should be common 
base
of non-GUI client code, and that the GUI-specific code should be minimized, 
leaving
the common non-GUI client code base maximized.  That should leave a common base 
that
would be useful for building client AIs, but not have too much code in it that 
an AI
wouldn't need, either.

And per my earlier posts, if you add a scripting interface to that common 
non-GUI
client code base (CNGCCB?), you could use that for player-support scripting as 
well
as for implementing full client AIs.



> > For the low-level decisions ("what do I build now?", "what should I be
> > researching?", "what does this unit do this turn?") you can think of a 
> > script
> > as a black box that accepts a question and returns an answer.  The game 
> > defines
> > a finite number of questions, and a finite range of answers for each 
> > question.
> > It should be possible to localize each possible question into a C function 
> > that
> > invokes the relevant script, passes the relevant arguments, and receives an
> > appropriate value back.  As a very worst, these functions would need a case
> > statement to see which scripting language the current client is using, and 
> > then
> > execute the few lines of code necessary to send/receive the question/answer 
> > for
> > that particular language.  Someone here may be clever enough to avoid the 
> > need
> > for even that much, or at least to pack the case logic into a macro that 
> > only
> > needs to be maintained in one place.
>
> That is a good starting model. But IMHO is missing some views.
>
> The decision making part has to access almost all data for a
> decision. "What should I be researching?" can depend on a lot of
> factors. Starting with the available techs, the ruleset settings, the
> rating of the enemies,.... It would be IMHO foolish to create a
> infrastructure which leaves this out.

>
> Another closely related problem is state. Almost every decision has to
> use state to come up with or play better than current ai. The current
> ai saves the state in the ai parts of city and unit. The decision
> making part must have access to this state and this state also have to
> be saved (on the server or on the client side).
>
> 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.



> P.S.: All who are concerned, please take a look at the past dicussion
>       <http://arch.freeciv.org/freeciv-dev-200007/msg00181.html> and
>       at the open questions in
>       <http://arch.freeciv.org/freeciv-dev-200007/msg00384.html>.

Re the second, I'll just mention that (b) above would not need any new caching,
since the existing client code already stores a "model" of the player's world.  
The
AI could just look at that model, and you wouldn't need any kind of new caching
system.

Bobby Bryant
Austin, Texas