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

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

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.

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.

Once that basic structure is set up, maintenance would be straightforward.  If
someone wanted to add a new language, all they would have to do is go in and
add a case for the dispatch code needed by their interpreter.

Bobby Bryant
Austin, Texas