[Freeciv-Dev] Re: FreeCiv Client Side AI (off current topic)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jul 02, 2001 at 09:29:40AM -0400, Guy Smith wrote:

[ Mayor and Ministers ]

This is IMHO a special version of the agent model I have in mind. An
agent is a bit of software that manages something (a unit, a city, the
production of a city). An agent issues requests to other agents or
directly to the server. This scheme allows it to build a hierarchical
set of agents. There may be simple agents like the Mayor which work
directly onto the server and there may be higher agents which only
issue requests to other agents. Also some existing functions like
auto-settle can be viewed as an agenet.

> occupied by enemy forces.  A mayor might be assigned to a map square
> occupied by a foreign city; in this case, the mayor would assume that "his"
> city is being occupied by foreign forces, and will then issue a request for
> the city to be "liberated."

I like this one.

> 2.3.14 RECORDS MINISTER
> 
>    Not sure about this one.  This minister probably wouldn't have an active
> role; instead, he might serve as a repository of information.  The idea is
> to do post-mortems on games, in an attempt to identify wrong decisions.

Not only post-mortem analysis but also in game analysis. The LOGISTICS
MINISTER may decide upon the information of the RECORDS MINISTER on
which fields should a road be build.

> 3.1 GENERAL ARCHITECTURE
> 
>    Because of the tentative nature of many of the ministers, and the
> expectation that new ministers may be added or existing ministers modified,
> and in view of the fact that the software is intended to be used both as a
> player-assisted AI and in a standalone mode, it makes sense to pursue a
> design architecture based on dynamic shared objects.

Dynamic shared objects is one way. What about scripting languages?

>    It is tempting for me to require that this base platform include the
> fundamentals of beauracracy, since my AI model is based on that paradigm.

I think every model require some kind of communication. You call it
fundamentals of beauracracy. I called it requests and responses.

>    The next question (that I have not yet answered) involves the tasking
> capabilities of the software.  Much of the game is event-driven, and of
> course there must be an ability to handle interruptions.  But much of the AI
> is not event-driven.  Exactly how I'm going to address this aspect remains
> an open question.

I think one sane solution is to make the AI event driven.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "A common mistake that people make, when trying to design 
  something completely foolproof is to underestimate the 
  ingenuity of complete fools."
    -- Douglas Adams in Mostly Harmless