Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2002:
[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)

[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, per@xxxxxxxxxxx, freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: [Freeciv-Dev] Re: [RFC][Patch] AI can fly v2 (fwd)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Thu, 11 Apr 2002 23:35:42 -0400

At 08:11 PM 02/04/11 -0500, Mike Kaufman wrote:
>Ccing freeciv-dev for now until I know core AI group is 'scribed
>On Thu, Apr 11, 2002 at 07:26:49PM -0400, Ross W. Wetmore wrote:
>> At 01:07 PM 02/04/11 -0500, Mike Kaufman wrote:
>> >On Thu, Apr 11, 2002 at 07:36:51PM +0200, per@xxxxxxxxxxx wrote:
>> >> On Sun, 7 Apr 2002, Gregory Berkolaiko wrote:

>> The AI program to mimic this is probably a few decades out even at rates
>> like Moores's Law.
>> Even caching past information is expensive.
>a possibility would be to give the ai a second map and game struct,
>which houses educated guesses, about troop concentrations in enemy
>cities for example. Another example would be seeing an enemy unit coming
>out of unknown territory and then assigning probabilities about the
>terrain type (!ocean) to the unknown tiles.

This is what I call expensive, and a few years out in complexity to be
of any real utility.

>> A reasonable compromise is to allow the AI to "see" the real map but 
>> add an error or ai_fuzzy() factor that makes this information less
>> reliable in locations that are unknown or fogged. For a difficulty
>> factor you can have the AI fuzz run from 0% (i.e. Mike's favorite
>> level) to 100% accuracy reflecting a more sophisticated cognitive
>> ability in a human.

>yes, yes, but I'm looking at a point in time where the AI doesn't have
>any choice because it ain't connected to the server. It can only see
>what it sees. Coding new stuff that takes advantage of the current
>omniscient ability is not a good plan.

The server contains a set of model data and some sort of per player
state (know and seen bits for instance). It sends only certain data
to the player filtered by these bits. This is the only source of
player data.

Toggle an AI flag and the filter bits become fuzzy. 

Limit AI flag toggling by server control or to players at the end of
localhost connections only. There are any number of "solutions" to the
list of followup problems that people that don't like losing arguments
will probably throw up.

In other words, your point is has validity only as far as you wish to 
limit the options :-).

>> >> - Also in the same savegame, why doesn't solomon invade sooner? It
>> >> around with dozens of transports with units in for dozens of turns
>> >> it finally decides to land them. Drives me crazy. pille's cities are
>> >> and deserted!
>> >
>> >yes, I noticed this when I looked at the original patch. AI doesn't
seem to 
>> >know when to pull the trigger.
>> You are supposed to be able to determine "flag" presence, so the AI should
>> know when a town is empty and change its attack computation accordingly.
>> This should not be a big deal if someone is playing in that code area. It
>> may be as simple as it never targets towns, just units in find something to
>> kill, so empty towns are 100% safe if they don't have units as bait :-)
>whatever it is, the its_time_to_invade() function should be on the
>todo list.

Here are some code fragments from advmilitary.c and aiunit.c. I 
suspect without really having had time to check under the debugger
that the want "e" is pretty low for empty cities, and kill_desire 
scales rapidly with heavy defender counts, making heavily defended 
city targets much more interesting to the braindead AI as Gregory
partially pointes out :-). 

The ai.f, ai.a, ai.invasion values do prove interesting as well
as they are the totals of surrounding unit build_cost and belligerence
of which there are likely none.

So with ai.f and d both zero, the kill_desire for an empty city with
no nearby units is 0.

And after much munging the want value is 0 which is not really very
effective at becoming a valid activity choice. 

Hence empty cities with a "plague" sign for friendly units to keep
away, are 100% safe from enemy attack :-).

        b0 = kill_desire(b, a, f + acity->ai.f, d, g);
        if (b * a_squared > acity->ai.f * d) {
          b0 -= kill_desire(b, a_squared, acity->ai.f, d, g);
    e = military_amortize(b0, MAX(1, c), fprime + needferry);           
      else process_attacker_want(pplayer, pcity, b, n, vet, x, y, unhap,
           &e, &v, myunit->x, myunit->y, boatspeed, needferry);
          if (e > best && ai_fuzzy(pplayer, TRUE)) {

Victim count is number of victims stacked in the target tile. Note that we
shouldn't treat cities as a stack (despite the code using this function) - the
scaling is probably different. (extremely dodgy usage of it -- GB)
int kill_desire(int benefit, int attack, int loss, int vuln, int victim_count)
  int desire;

  /*         attractiveness     danger */
  desire = ((benefit * attack - loss * vuln) * victim_count * SHIELD_WEIGHTING
            / (attack + vuln * victim_count));

  return desire;


[Prev in Thread] Current Thread [Next in Thread]