[Freeciv-Dev] Re: Client AI development

[Tony Stuckey <stuckey@xxxxxxxxxxxxxxxxx>]

On Thu, Apr 19, 2001 at 06:36:57AM -0500, Cameron Morland wrote:
> La 2001-04-19, Raimar Falke skribis:
> > Cell based client structure
> > ===========================
> 
> First of all, I really like the idea of making the entire AI writable
> in any language, especially considering how AI has historically been
> done primarily in Lisp (now Scheme). Emphasising standards-compliance
> by the use of XML and so on is also a good idea. This method also
> permits many AIs to easily be written in many different ways, which
> may make it worthwhile in any case. However, this is an awful lot of
> coding, so it might take quite a while. Continuing to do it in C might
> not be so terrible, especially if the AI section can be logically
> separated from the rest of the code.

        All of this is already true.  Nothing is stopping you from creating
a LISP client AI using the currently defined packet interface.  The noted
serialization problems will make this annoying, but it's still possible.
        Any server-side AI work can be done in any language that has a
C-linkage.  That includes C++, PERL, Fortran, and many others.  Go to it.

> So an outline of my AI would be this: each unit is an autonomous
> agent, which gets its information from the map, and marks information
> on the map, permitting communication between units. This allows
> selection of action; there are very few possible actions for a
> non-settler unit --- move, attack, fortify, pillage, disband. A
> handful of subsumption-architecture layers control the actions. (The
> same is true for settlers, they just have a bunch more things to do.)

        Except for the "and marks information on the map", this is already
done.

> This deals with individual units. An additional bit of code is
> required to make each city an autonomous unit. The city controls only
> setting production, placing citizens, and some unit control (shields,
> happiness). Cities communicate again via the map, both with each other
> and with units.

        This is already done.  What specific problems do you have with
server/cityturn.c: auto_arrange_workers()?

> A third AI type is required; this is the civilization. The
> civilization sets tax rate, selects advancements, does diplomacy,
> and chooses government. It also communicates via the map.
>
> An appropriate combination of these should be workable. It should also
> be possible to automate generation of some of the intelligence,
> because optimally-intelligent behaviour is likely to be
> ruleset-dependent.

        Optimal behavior will absolutely depend upon the ruleset.

> So my intention is to start with the first section, the individual
> units. This means I can simply add a "automate military unit" item to
> the Orders menu, then fiddle with the AI. Levels of competence could be
> something like this:
> 
> - If could be attacked by much stronger unit, retreat.
> - If could attack much weaker unit, attack.
> - If could be attacked, move to a defendable tile, such as a hill.
> - If could be attacked, fortify.
> - If are a good defensive unit, move towards areas of the map that
>   feel undefended, such as empty cities.

        Most of this is already implemented.

> - If are not a good defensive unit, make the map near you feel
>   undefended, especially if you see an enemy unit.
> - If are fast, seek unknown land.
> - Make good tiles near enemy cities feel undefended. (To encourage your
>   old trireme to sit on his whales. :) )
> 
> A few more levels like that should provide reasonable behaviour. The
> details, of course, need to be worked out.
> 
> This should be testable at all points, with a human controlling city
> and civilization functions. Once this works, code for making
> autonomous cities is required, and eventually, autonomous
> civilizations.
> 
> You might notice that Raimar's design is essentially a design of my
> civilization AI; I just want to make each unit and city a seperate,
> autonomous entity below the civilization. Did you come up with the design
> on your own? It's quite BB-ish.
> 
> Fun, eh? I'm going to Europe for a month, but when I come back this will
> be my project, if I have any spare time. This has been "simmering"  for
> some time, but I've been too busy to make any progress.
> 
> This sort of design has the advantage of permitting small patches to
> implement it; one patch for "automate military unit", one patch for
> "automate city", one patch for "automate civilization", one patch for "get
> rid of this now-useless GUI". I guess there could be an option "--nogui"
> or somesuch on the client, and the server could spawn the appropriate
> number of GUI-less clients.

        The current Freeciv AI is already programmed bottom-up.  Each city
greedily gobbles up the best land, produces units until it can't support
any more, builds city improvements with the most immediate impact on
production.  Each unit makes it's own decisions based upon incomplete
information about where to go and what to do.

        What is needed is a master planner.  Something that will direct all
of this.  Something that understands how many turns are left in the game,
and how tactics change because of that.  Something that actually evaluates
*HOW WELL* an AI tribe is doing relative to all the others.  Something that
decides whether to win by conquest or space race, and how.
        There is none of this in the current code base.  There isn't even
support for it.  There is no function for estimated_turns_left_in_game().
There is no function to determine whether the AI is still in the initial
expansion, fighting a losing defensive war, diplomatically hated by all
other players, etc.  There is no synchronization of attack unit arrival
turns, because there is no base turn counter kept by the game.  There is no
function that looks at the Demographics report, Embassy data, Wonders of
the World, etc, and decides whether the AI is doing well or getting
hammered.

        This high-level lack of direction is the biggest problem with the
current AI.  If it wins, it wins by accident because of massive
overproduction.

        Yes, breaking the map up into smaller, more manageable sections
would make some things more efficient.  Yes, having a separate, client-side
AI is useful.
-- 
Anthony J. Stuckey                              stuckey@xxxxxxxxxxxxxxxxx
"And they said work hard, and die suddenly, because it's fun."
        -Robyn Hitchcock.