[Freeciv-Dev] Re: Client scripting

[ccrayne@xxxxxxxxxxx]

In <980593737.3a72ac495370b@ceylon>, on 01/27/01 
   at 11:08 AM, Andrew McGuinness <andrew@xxxxxxxxxxxxxxxxxxxxxx> said:

:What *I* would like to see ( and the observant may notice that I've never
:even looked like doing anything about it ) is all of the following:

:o AI clients

:o Client-side scripting

:o Server side "higher-level" functions available to both, like the 
:current server-side "goto" and "worklist" features.

:o Essential client state information saved in savegames server-side

:o Inessential client state information saved in client-side save files
:(possibly very large for client AIs)

I agree with these goals, but with the qualification that I have yet to
find any client state information which I would like added to that which
the server already saves.

:On the other hand, I feel the people who are jumping straight into 
:trying to write client AIs from the current codebase are going to  find
:it is too much work to handle writing a client and an AI  together.

It would be, if there were any need to write a new client, but, in fact,
the existing client code works just fine -- with the minor exception of a
couple of routines in packhand.c, which strip off the same sort of
information from some packets as Dirk and Raimar are trying to add to
others. In addition, most of the existing low level AI routines can be
moved from the server to the client with minimal changes. Thus, such time
as I am willing to devote is spend primarily on designing and implementing
new AI functionality.

:I think the right approach is what Dirk and Raimar are doing - 
:improving the interfaces to make AI clients and scripting clients easier
:to write and manage.

Although potentially useful, this is a convenience, rather than an
approach. If & when it happens, it will give me some additional tools,
which I will use when appropriate, but I will not wait for them.

In my view, the first step in the "right approach" is to design data
structures which allow the knowledge of strategic and tactical goals, and
the progress which has been made toward achieving them, to be preserved
from turn to turn, as opposed to the current design in which (with a few
minor exceptions) the AI views each new turn as if it had never seen the
game before.

As a simple example, suppose that the AI wishes to take and hold a
strategic square. Assume that the AI is smart enough to generate a list of
available units (from various locations) which it wishes to converge on
the target. But how does it actually go about moving them? It can't just
issue a "goto" for each unit, because the units are unlikely to arrive at
the same time, and it might cost too many turns to assemble them at some
safe location before moving the stack to the final target.

Since this is a function which a human player might like to use, and
because it would reduce network traffic, this would be a good candidate
for a server provided service, but wherever it is implented, it requires
new or expanded data structures. I invite you, and everyone else who is
interested, to join me in discussing the design alternatives.

Best,
        -- Chuck Crayne
-----------------------------------------------------------
ccrayne@xxxxxxxxxxx
-----------------------------------------------------------