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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Dec 26, 2000 at 01:38:31AM -0600, Bobby D. Bryant wrote:
> Jesdyn Flamestrike wrote:
> 
> > On Tue, Dec 26, 2000 at 12:41:50AM -0600, Bobby D. Bryant wrote:
> >
> > > The easiest way to do this, IMO, would be to go ahead and start adding
> > > client-side scripting to the player clients, and then bootstrap a true
> > > client AI off the scripted player clients.
> >
> > Non-portable.
> 
> No worse than what we already have.  In fact, much of the necessary code would
> be in the non-GUI portions of Freeciv (i.e., call the script dispatcher rather
> than the UI dispatcher).
> 
> 
> > Don't attach scripting to the client directly. Make a new client that's just
> > an AI. Client code, no display functionality at all -- it can send info
> > messages to the server or something.
> 
> 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.

> Also, there is already independent demand for client-side scripting to 
> delegate
> various player tasks to a script, so the bootstrap would exploit work that's
> destined to be done anyway, and will be in the official CVS version.  Even in
> the final stages of bootstrapping, the player clients may want to use the AI 
> as
> an advisor on major decisions, whether those decisions are actually delegated
> to the AI or not.
> 
> 
> > Attach scripting to IT, in whatever language you like -- but trying to add
> > scripting to all clients is just gonna cause some heartache. "I need -what-?
> > GUILE? Can I get by with stealth?"
> 
> I suspect we could leave the client agnostic about what scripting language was
> used.
> 
> 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.

Another approach would be that the nongui-client informs the decision
making part about every new information it gets from the server and
somewhere along the way the decision making part would issue a command
through the nongui-client. The nongui-client could in this scenario be
small (it only has to implement the server-client protocol). Than
however the decision making part needs to implement some kind of
memory.

        Raimar

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

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  One nuclear bomb can ruin your whole day.