[Freeciv-Dev] Re: More on client AIs.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Jan 10, 2001 at 01:26:20AM -0600, Bobby D. Bryant wrote:

Agreed till here.

> This *might* mean that the AI agents would need to have two levels like
> the player agents: a high-level agent to make the decisions, and a set
> of utilities, corresponding to the GUI, that the high-level agent would
> invoke during the decision-making process.  However, it may be that the
> common infrastructure could be accessed directly by the high-level AI
> agent, without an intermediate layer.

Why this split into two layers? The functions in the non high-level
agent can IMO split into indepented of the high-level agent functions
(these can be add to the common base) and the rest which would can be
added to the high-level agent.

> The high-level AI would need to save some high-level state, just as a
> human player does, but would rely on the common infrastructure layer to
> save the lower-level state, just as the GUI clients do for human players
> now.  The nature of the high-level state would depend entirely on how
> you wanted to implement the AI (e.g., for a neural network the state is
> maintained in the weights and the activation levels of any hidden
> layers). The nature of the lower-level state would be common regardless
> of the nature of the AI, and for that matter common between AI agents
> and human agents, since the state is just details about what the server
> is telling you about your world.

Agreed.

> For a hybrid system where a human player is supported by scripting, the
> decision would work pretty much the way it does for the AI agents, i.e.
> the GUI does not directly need to be involved.  Of course a lot of
> things go into this decision, so you may want to provide a mechanism for
> the player to set some global state variables (at war, at peace,
> expanding, perfecting, etc.) in a place where the helper scripts could
> make reference to them in their decision making process.

I would like to throw in another approach: instead of common base an
an agent would about stackable agents? The ai would be split into
parts. These parts can be put together. Every information flow and
command flow can be modified by an agent part. So as an example you
may have in this order:
 - common base
 - bodyguard agent
 - war agent
 - human agent

If the war agent moves a bodyguarded cannon the bodyguard agent will
issue commands to also move the bodyguard and maybe if the bodyguard
isn't fast enough slow down the cannon. Another example would be that
information like "City Foobar destroyed" will be translated by the war
agent into "Job finished; war against player Foobar2 won"

The ideal solution would be pluggable agents. Something like Javas
pluggable io-streams. A basic requirement for this would be that
commands and information can be intercepted and changed. 

> For simplicity, I have portrayed the infrastructure layer (and GUI) as
> being essentially passive.  In practice that would need to be modified
> somewhat, as when a message from the server needs to trigger a new
> action (e.g., "you need to pick something to research now").  For human
> agents, that already works by having the GUI pop up a message.  For AI
> agents it could be interrupt driven, but it might be simpler to just set
> a flag and let the high-level AIs poll the flags each turn.
> 
> Also, the whole system will need a way to tell the AI agent "Make a move
> now."  This could be done by having the AI poll the game state until it
> sees an appropriate flag set, or else by some more elegant mechanism.
> For hybrid systems, the helper scripts could behave the same way, i.e.
> once per turn they would all wake up and do whatever tasks have been
> delegated to them.

To quote from an older posting of mine:
--------------
Is some kind of parallel execution needed? (There are at least two
reasons for parallel execution: performance and up-to-date data)

IMHO yes in the long run.

Problem: during a longer calculation the control code layer wants the
current data

Possible solution:
 1) the network and cachng layer update the data asynchronously. New
    problem: the control code sees some old and some new data.
    Solution: locking of every access. IMHO ugly
 2) the control code layer gives execution to the network layer. If
    there are packets they will be handled in normal fashion. If
    there no more packets the call returns. The control code layer
    knows when something has changed.
 3) more loose coupling: no shared objects. All data is got through
    function calls and is only a very short time valid. (How long is
    short time?)
 4) more loose coupling2: no shared objects. The network layer send
    only the callback and then the control code layer copies the data
--------------

IMHO we should take a precise look what level and what kind of
parallelism we allow/need.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We just typed make..."
    -- Stephen Lambrigh, Director of Server Product Marketing at Informix,
                         about porting their Database to Linux