Complete.Org: Mailing Lists: Archives: freeciv-ai: July 2002:
[freeciv-ai] Re: Borg AI.

[freeciv-ai] Re: Borg AI.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Per I Mathisen <per@xxxxxxxxxxx>, freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: Borg AI.
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 06 Jul 2002 12:17:56 -0400

At 04:09 PM 02/07/03 +0200, Raimar Falke wrote:
>On Wed, Jul 03, 2002 at 02:55:13PM +0200, Per I Mathisen wrote:
>> On Wed, 3 Jul 2002, Raimar Falke wrote:
>> > Is there a reason why you can't use these guesses with influence maps?
>> No, as I said, it is possible to use influence maps in freeciv, but it
>> isn't as easy as the standard influence map model, where you just map
>> units into a map struct and mesh the values out. The really hard part is
>> to figure out where the units could be hiding, and the influence map
>> doesn't really help there.
>The influence map shouldn't help with the estimation of the enemy
>units. But to estimate the danger to your cities.

Think static estimates ...

>> > So you attacked and found that there is a defending Archer. You killed
>> > it but the city is still defended. What information does this give to
>> > the attacker about the remaining defending forces? IMHO nothing except
>> > that the city doesn't currently have stronger defenders than Archers.
>> I was thinking more high-level. ie we try one attack on continent X with Y
>> units and fail. So next time we try continent 2 instead. Or something.
>> Attacking repeatedly on the same spot is a typical AI failure that we
>> should avoid.
>> > IMHO a good way would be to assume a fixed number (1 or 2) of the best
>> > defenders in the city and than attack if you have collected enough
>> > forces to get the city. If you fail increase the number and retry. If
>> > you get your first city you can also learn from this. You know how
>> > many defenders and which type their were. You can now use this to
>> > _estimate_ the defense of other enemy cities.
>> That doesn't sound right. Often the enemy will attempt to rush its units
>> into the single spot where you concentrate your attacks, leaving other
>> cities less defended.
>But if you don't counter this concentration of enemy units the enemy
>may decide to not only use these units as a defense but will attack
>with them.

There are a number of balancing aspects in dealing with this. A good
general influence-based system, with some tactical refinement options
to deal with specific situations will sort this out.

>       Raimar

In general, well-planned attacks require time to position forces.
Doing a number of scattered attacks as a general stategy is invariably 
a recipe for disaster, sending weak forces to be lost everywhere. It
is often better to mass forces and keep hammering at a weak point until
it collapses. If the enemy is "rushing" forces to counter, they are
often out of position and poorly coordinated, thus easy to pick off.

But if you hit a rock, then you need to backoff and the sooner the

In a good atrategy model, only excess forces will be committed to an
attack, with sufficient reserve to deal with any perceived threat from
a complete rout.

If you have enough excess forces to mass for multiple attacks on 
several key positions, or send in unit killing teams to deal with the 
panic rush to defend the initial attack point, then the influence
map should trigger these actions as the enemy positions shift and 
weaknesses or concentrations of forces upset the balance.

A good AI won't explicitly plan a lot of these sorts of things in
specific code, but will setup given response strategies to the general
influences and specific tactical threats of any given moment. One
way to prevent flip-flops is to have a scaling factor in the weights
like "war-weariness" which typically holds back actions. After an
"incident" this factor gets reset guaranteeing that pent up or 
positionned forces all get released in some sort of coordinated
manner, and keep at it for a defined period of time. This is usually
a more effective strategy.


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