[Freeciv-Dev] Re: Client scripting

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 27, 2001 at 12:54:51PM -0800, ccrayne@xxxxxxxxxxx wrote:
> 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

I posted a patch which implements this.

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

Suppose you have an agent which manages the worker of your city to
achieve some goal (maximize trade for example). This agent is also
available to human clients. Where would you save the goal?

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

IMHO such data structure can't be designed generic. Each agent has to
implement its own. Maybe some infrastructure can be programmed but I
guest this would only provide a small portion of what you want.

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

So it needs some way to calculate the number of turns for a unit to
reach a square. Next question is where this number will be calculated.

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

Please if extra "higher-level" functions are implemented at the server
side don't put them into the core. Make it an extra source file with a
well defined interface. Nevertheless I think the ability to implement
various implementations of a "higher-level" function at the client
outweighs the reduced network traffic. The ideal solution IMO would be
a generic interface. So you have something like:
  
  GUI client <-> agent <--- internet ---> server core

and if now the agent uses to much network traffic just move it to the server:

  GUI client <--- internet ---> agent <-> server core

This implied that "GUI client" send commands for the server core but
also for the agent.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  reality.sys corrupt. Reboot Universe? (y,n,q)