Experimental AI

Experimental AI Summary

An Experimental AI is available for use in both MP maps and SP scenarios. At the moment, this AI contains the following candidate actions:

• New and improved recruiting
• More aggressive village grabbing
• Healer placement behind injured units
• Leader castle switching: useful on certain MP maps
• Poison spreading
• All the default RCA AI candidate actions except for recruiting

Experimental AI Setup

In multiplayer maps, this AI is available from the game setup menu as 'Experimental AI'. In single-player scenarios, it can be included by using the following code in a [side] tag

[ai]
    {EXPERIMENTAL_AI}
[/ai]

Important Notes:

• This [ai] tag must go into a [side] tag. It does not work with [modify_side] or [modify_ai].
• Currently, there is a restriction in the Wesnoth source code that makes it impossible to add the standard aspects together with the Experimental AI inside the same [side] tag, even if they are in different [ai] tags. We are working on lifting that restriction. In the meantime, the Experimental AI must be defined in a [side][ai] tag as shown above. Aspects can then be added by using [modify_side][ai] or [modify_ai] in an event.

Experimental AI Details

The Experimental AI uses most of the candidate actions (CAs) of the RCA_AI, the one exception being the recruitment CA which has been replaced entirely. In addition, it adds a number of other CAs.

The following explains the differences between the Experimental AI and the default (RCA) AI. As you can see, some of the behavior might not be optimal yet, which explains the name of the AI.

Recruitment

The Experimental AI has a completely different recruiting algorithm that was designed to emulate the choices of a human player, especially in the first few turns. As such, it tries to pick units that counter both what is on the battlefield and that the opponent could recruit. As it gains more units relative to the enemy, it picks harder hitting units, even at the cost of fragility, to break through enemy lines.

Unlike the default recruitment algorithm, it also chooses where the units are recruited in order to maximize the number of villages that can be captured and if it knows the leader will be moving to a "better" keep (see below), it will under-recruit at the first keep to project more forward power, recruiting just enough to capture all villages.

It also adjusts its recruitment based on map size, favouring faster units on larger maps, trusting that the economy advantage from capturing more villages will more than offset the price.

It knows about poison and avoids recruiting units that depend on it for damage if the enemy is immune.

It also looks at the expected cost of the unit over the next few turns, which prevents the recruitment of too many fast weak units unless the additional gold from an expected capture of a village is enough to offset the increased cost.

Time of day is taken into account and it prefers units that will reach the current closest enemy at the favoured time of day. This allows, for example, for a slight bias towards saurians during the day and drakes at night (because they will reach the fight at the right time).

Because the AI cannot use them well, it does not accurately measure the damage done by a unit with berserk, causing them to almost never be recruited.

There is also a small amount of randomness added to allow two units that are almost equally good according to the evaluation to be chosen evenly, instead of only picking the first one every time.

Villages

The Experimental AI prefers to capture villages over fighting. This weakens it somewhat in raw fighting but it tends to get enough extra gold that this is actually to its advantage vs. the default AI, although its current implementation is probably too focused on villages.

Healing

If a healer is not used to attack, the Experimental AI will try to heal units, instead of positioning to attack later.

Units retreat to villages/healers when injured, but currently there is little attempt to identify when it would be better not to in order to finish off multiple enemies in an area.

Castle Switching

The leader will move to different keeps, providing a forward force. Sometimes this works very well, especially at the beginning of the game, but it keeps moving later, which sometimes gets it killed. It might be worth stopping this behaviour after turn 3-4 or trying to identify the best keep rather than picking a close one that is not the current one as a way to improve it.

Enemy Poisoning

There is also an explicit poison attack routine that tries to poison unpoisoned units instead of repeatedly poisoning the same one.

A Final Note

• Many of the extreme biases in the experimental AI come from the fact that it still uses a lot of the default AI code and thus cannot ask it what the default action would be and compare possible moves. It has to decide whether the alternative is better without knowing the default choice.

See also: Wesnoth_AI