Difference between revisions of "Micro AIs"

From The Battle for Wesnoth Wiki
m (Guardian types and their specific keys for the [micro_ai] tag:)
Line 296: Line 296:
 
== Animals Micro AI ==
 
== Animals Micro AI ==
  
The Animals Micro AI defines a number of a animal AIs. Different animal AIs behave differently. For details, see below. Currently only the hunter micro AI works, and only in the example scenario.
+
The Animals Micro AI defines a number of a animal AIs. Different animal AIs behave differently. For details, see below. '''Currently only the hunter micro AI works.'''
  
 
For a demonstration, check out scenario "Dragon" of the AI-Demos campaign.
 
For a demonstration, check out scenario "Dragon" of the AI-Demos campaign.
Line 304: Line 304:
 
into the [side] tag and configure it by using
 
into the [side] tag and configure it by using
 
  ai_type=animals
 
  ai_type=animals
in the [micro_ai] tag. (This is not implemented yet.)
+
in the [micro_ai] tag.
 +
 
 +
'''Required keys:'''
 +
 
 +
* '''id''': The ID of the unit to which this AI should be applied.
 +
* '''hunt_x''': The x range of the area where the AI will wander.
 +
* '''hunt_y''': The y range of the area where the AI will wander.
 +
* '''home_x''': The x coordinate of the place where the AI will return.
 +
* '''home_y''': The y coordinate of the place where the AI will return.
 +
* '''rest_turns''': The number of turns the AI will stay at "home".
  
 
== Other Potential Micro AIs ==
 
== Other Potential Micro AIs ==

Revision as of 16:10, 30 November 2012

More information: Google Code-in Micro AI Tasks


The add-on AI Modification Demos contains a number of so-called Micro AIs (well, currently there are only three, but the goal is to add more). Mirco AIs add specific functionalities to a side's AI that can be added to a scenario easily using only a few lines of WML code. Adding (or deleting) a Micro AI is done via the [micro_ai] tag, which also lets the campaign designer configure the AI behavior to the specific need of the scenario.

Note that the AI-Demos add-on is only supported for Wesnoth 1.11 any more. In time, fewer and fewer of the AIs (and Micro AIs) will function with Wesnoth 1.10.

Setting up a Micro AI

After installing the AI Modification Demos add-on, there are currently three steps required to set up a Micro AI:

1. Making the Micro AIs and [micro_ai] tag available in your add-on

The following line needs to be added to your _main.cfg file, inside the #ifdef for your campaign:

{~add-ons/AI-demos/micro_ais/activate_micro_ais.cfg}

This loads the required AI files and sets up the [micro_ai] tag.

2. Setting up the Lua AI engine

Add the following line to the [side] tag of the side that should use the Micro AI. The exact macro name depends on the specific Micro AI - see below for the available Micro AIs and respective macro names:

    {MICRO_AI_HEALER_SUPPORT}

This does not yet activate any Micro AIs, but it is currently still necessary to define the Lua AI engine inside the side definition for the Micro AIs to work. This requirement will go away for one of the upcoming Wesnoth 1.11 releases.

3. Activating and configuring the Micro AI

Micro AIs are activated, deleted and configured using the [micro_ai] tag. This tag needs to be placed in ActionWML, that is, in an event, a menu option or the like. As an example, the following code activates the healer_support Micro AI in its default configuration for Side 2 from the beginning of the scenario:

    [event]
        name=prestart

        # Configure the healer support micro AI
        [micro_ai]
            side=2
            ai_type=healer_support
            action=add
        [/micro_ai]
    [/event]

For the full syntax of the [micro_ai] tag and the available Micro AIs, see the next sections.

The [micro_ai] Tag

The [micro_ai] tag activates, deletes and configures the Micro AIs for use in a scenario. It needs to be placed in ActionWML and must contain the following three required keys:

  • action (string): The action to take concerning the Micro AI. The following values are allowed:
    • add: Add a Micro AI to a side.
    • change: Change the configuration of an existing Micro AI. Note that this does not only change the specific parameters provided in the tag, but it replaces the entire existing Micro AI by a new version with the new (and only the new) configuration. It is therefore equivalent to using first the delete and then the add action.
    • delete: Delete an existing Micro AI from a side.
  • side: The side for which the Micro AI is to be added, changed or deleted
  • ai_type: The type of Micro AI to be added, changed or deleted. See the following sections for allowed values. A Micro AI that attaches to a unit, that is, a Behavior Candidate Action (BCA), has an ai_type starting with 'bca_'. Consequently, ai_types not starting with 'bca_' apply to all units of a side.

If no other keys are given, the Micro AI is set up in its default configuration when using the add and change actions. Additional keys allowed for each Micro AI are listed below. The add and change actions ignore all keys that do not apply to the respective Micro AI type. The delete action ignores all keys other than the three listed above.

Healer Support Micro AI

The Healer Support Micro AI configures the healers of a side to stay behind the battle lines and heal injured and/or threatened units rather than participate in combat under all circumstances. You can set different levels of aggressiveness for the healers, from "never attack" to "only heal if you cannot attack" (not all implemented yet).

For a demonstration, check out scenario "Healer Support" of the AI-Demos campaign.

Enable the Healer Support Micro AI by putting

{MICRO_AI_HEALER_SUPPORT}

into the [side] tag and configure it by using

ai_type=healer_support

in the [micro_ai] tag.

Healer Support specific keys for the [micro_ai] tag:

  • aggression=1.0: (float) Sets the aggressiveness of the AI. This parameter is set up as a float to accommodate future functionality, but it currently acts as a boolean: if set to zero, the AI will never let its healers participate in combat, for all other values it allows them to attack after all other units have attacked and if the healers cannot find any more units to support. The former behavior might be appropriate in scenarios with only one or few valuable healers, while the latter might work better in scenarios with many healers.
  • injured_units_only=no/false: (boolean) If set to 'yes' or 'true', the AI will only move healers next to units that are already injured and skip units that currently have full hitpoints, but might get injured during the next enemy turn.
  • max_threats=9999: (integer) The maximum allowable number of enemies that can attack a hex in order for it to be considered for a healer. As an example, setting 'max_threats=0' means that the AI only moves healers to locations that are entirely safe from the enemy (assuming that none of the units currently on the map dies). Note that the value of this key is checked against the number of enemies that can make it to the hex, not the number of adjacent hexes from which the healer could be attacked.

Bottleneck Defense Micro AI

The Bottleneck Defense Micro AI lets you define a location on the map where the AI can take a defensive stance behind a narrow passage (bottleneck). Units on the front line are backed up by healers and/or units with the leadership ability. Injured units are moved to the back and replaced by uninjured (or less injured) units. The units on the front line only attack when it is safe (no retaliation) or when there is a high chance that they will make a kill or level up. Using this Micro AI only makes sense if there is no way for the enemy sides to move around the bottleneck and attack the AI's units from behind.

For a demonstration, check out scenario "Bottleneck Defense" of the AI-Demos campaign.

Enable the Bottleneck Defense Micro AI by putting

{MICRO_AI_BOTTLENECK_DEFENSE}

into the [side] tag and configure it by using

ai_type=bottleneck_defense

in the [micro_ai] tag.

Bottleneck Defense specific keys for the [micro_ai] tag:

Required keys:

The Bottleneck Defense AI requires two sets of coordinates that define where it should be taking up its defensive stance, and from which side the enemy attacks at that location.

  • x,y: Comma separated lists of the hexes on the front line, where strong units are placed. All hexes on which the AI makes contact with (be attacked by) the enemy need to be included here. Units are placed on them in the order in which they are listed here.
  • enemy_x,enemy_y: Comma separated list of the hexes from which the enemy can attack the AI front line units. This is needed for the AI to know on which side of the front line support units (healers etc.) need to be placed. In many cases, it is sufficient to provide only one of the enemy front line hexes, but there are geometries for which that does not work. It is therefore safer to list all enemy front line hexes here.

Optional keys:

By default, the AI places healers and units with the leadership ability both on the front line itself (if they are the strongest units available) and on hexes adjacent to and behind the line. If different placement is desired, these locations can be overridden with the following keys.

As an example, in the Bottleneck Defense scenario of the AI-Demos add-on, there are three front line hexes, two of which are on hill terrain, while the third is a road with a lower defense rating. The healer and side leader are supposed to participate in combat because they are strong units, but only from the hill hexes to keep them safer. This is accomplished but using the following keys (see code example below):

  • healer_x,healer_y: Comma separated list of hexes where healers are placed. This can be used to keep healers from the front line (or to take up only certain positions on the front line), and/or to override the default healing positions behind the line. Healers are placed on them in the order in which the hexes are listed, with the exception that hexes on the line always take priority over hexes behind the line.
  • leadership_x,leadership_y: Same as healer_x,healer_y, but for units with the leadership ability.
  • active_side_leader=no: (boolean) If set to 'yes', the side leader participates in the bottleneck defense action after the side's gold has been spent. If set to 'no' (default), the leader follows default AI behavior (sitting on the keep and recruiting, for the most part).


Here's an example of the [micro_ai] tag usage from scenario "Bottleneck Defense" of the AI-Demos campaign:

[micro_ai]
    # Required keys of [micro_ai] tag
    side=1
    ai_type=bottleneck_defense
    action=add

    # Required keys of Bottleneck Defense Micro AI
    x=14,14,14
    y= 7, 9, 8
    enemy_x=13,13
    enemy_y= 8, 9

    # Optional keys of Bottleneck Defense Micro AI
    healer_x=14,14,15,15
    healer_y= 7, 9, 8, 9
    leadership_x=14,14,15,15
    leadership_y= 7, 9, 9 ,8
    active_side_leader=yes
[/micro_ai]

Messenger Escort Micro AI

The Messenger Escort Micro AI lets you define a location on the map where the AI will attempt to move to safely. One unit is defined as a messenger, and the other units will escort the messenger.

For a demonstration, check out scenario "Messenger Escort" of the AI-Demos campaign.

Enable the Messenger Escort Micro AI by putting

{MICRO_AI_MESSENGER_ESCORT}

into the [side] tag and configure it by using

ai_type=messenger_escort

in the [micro_ai] tag.

Messenger Escort specific keys for the [micro_ai] tag:

Required keys:

  • id: The id of the messenger. All other units with the AI will protect the messenger.
  • goal_x,goal_y: The x and y-value of the hex of the destination, where the messenger will attempt to reach.

Optional keys:

  • enemy_death_chance: A number ranging from 0 to 1. When a unit is adjacent to an enemy unit, if the probability of the enemy dying is greater than or equal to this value, then the unit will attack. Default is 0.67.
  • messenger_death_chance: A number ranging from 0 to 1. When a unit is adjacent to an enemy unit, if the probability of the unit dying is lesser than or equal to this value, then the unit will attack. Default is 0.

Here's an example of the [micro_ai] tag usage from scenario "Messenger Escort" of the AI-Demos campaign:

[micro_ai]
    side=2
    ai_type=messenger_escort
    action=add
    
    id=messenger
    goal_x=28
    goal_y=1
[/micro_ai]

Guardian Micro AI

The Guardian Micro AI defines a number of a guardian AIs. Guardians typically protect certain locations on the map. Different guardian AIs behave differently, some moving, some remaining in place. For details, see below.

For a demonstration, check out scenario "Guardians" of the AI-Demos campaign.

Enable the Guardians Micro AI by putting

{MICRO_AI_GUARDIAN}

into the [side] tag. Configure using the [micro_ai] tag with ai_type as "guardian". Different types of guardians are specified below.

Guardian types and their specific keys for the [micro_ai] tag:

Stationed Guardian:

The stationed guardian will remain at its station until an enemy unit enters its radius of defense. It will continuously attack any unit within this radius until there are no more, at which time it returns to its station.

Enemies will only be attacked if they enter within the radius from both the unit's station and guarded hex. Thus ensure that the guarded hex and the station are at most 2*radius hexes apart.

You can configure it using the micro_ai tag as follows (all keys are required):

  • guardian_type: Must be "stationed_guardian"
  • id: The ID of the unit to which this AI should be applied.
  • radius: The maximum distance from its station that this unit will move to attack an enemy unit.
  • station_x and station_y: The x and y position of the hex that the unit must take as its station (point to which it returns)
  • guard_x and guard_y: The x and y position of the hex this unit is guarding

For example:

[micro_ai]
  side=1
  ai_type=guardian
  action=add
  
  guardian_type=stationed_guardian   
  
  id=stationed1
  radius=4
  station_x=3
  station_y=5
  guard_x=4
  guard_y=5
[/micro_ai]

Coward:

The coward will remain where it is until an enemy unit enters its radius. It then run to the hex furthest from all enemies (ie with least distance sum to enemies). It also attempts to move towards the "seek" hex and away from the "avoid" hex (if specified).

You can configure it using the micro_ai tag as follows:

Required keys:

  • guardian_type: Must be "coward"
  • id: The ID of the unit to which this AI should be applied.
  • radius: The distance that an enemy must be to "scare" the unit

Optional keys:

  • seek_x and seek_y: The x and y position of the hex to seek
  • avoid_x and avoid_y: The x and y position of the hex to avoid

For example:

[micro_ai]
  side=1
  ai_type=guardian
  action=add
  
  guardian_type=coward
  
  id=coward1
  radius=4
  seek_x=3
  seek_y=5
  avoid_x=4
  avoid_y=5
[/micro_ai]

Return Guardian:

The return guardian moves towards the hex passed to it.

You can configure it using the micro_ai tag as follows:

Required keys:

  • guardian_type: Must be "return_guardian"
  • id: The ID of the unit to which this AI should be applied.
  • to_x and to_y: The x and y position of the hex to move towards

For example:

[micro_ai]
  side=1
  ai_type=guardian
  action=add
  
  guardian_type=return_guardian
  
  id=return1
  to_x=3
  to_y=5
[/micro_ai]

Lurkers Micro AI

The Lurkers Micro AI defines a lurker battle AI. A lurker can move across most terrains but only stops on swamp. They always attack the weakest enemy within their reach. If no enemy is in reach, the lurker does a random move instead.

For a demonstration, check out scenario "Swamp Lurkers" of the AI-Demos campaign.

Enable the Lurkers Micro AI by putting

{MICRO_AI_LURKERS}

into the [side] tag and configure it by using

ai_type=lurkers

in the [micro_ai] tag

Protect Unit Micro AI

The Protect Unit Micro AI lets you define a location on the map where a chosen unit will attempt to move to safely. The chosen unit will stay away from enemy units, and stay close to friendly units. Other units with the AI will protect the chosen unit.

For a demonstration, check out scenario "Protect Unit" of the AI-Demos campaign.

Enable the Protect Unit Micro AI by putting

{MICRO_AI_PROTECT_UNIT}

into the [side] tag and configure it by using

ai_type=protect_unit

in the [micro_ai] tag.

Protect Unit specific keys for the [micro_ai] tag:

Required keys:

  • units: Information about the protected unit(s). Listed as id,goal_x,goal_y for each unit. All other units with the AI will protect this/these unit(s).

Optional keys:

  • disable_move_leader_to_keep (boolean): If true, will prevent protected leaders from returning to their keep.


Here's an example of the [micro_ai] tag usage from scenario "HttT: The Elves Besieged" of the AI-Demos campaign:

[micro_ai]
    # Required keys of [micro_ai] tag
    side=1
    ai_type=protect_unit
    action=add
    
    units=Delfador,1,2,Konrad,1,1
    disable_move_leader_to_keep=true
[/micro_ai]

Animals Micro AI

The Animals Micro AI defines a number of a animal AIs. Different animal AIs behave differently. For details, see below. Currently only the hunter micro AI works.

For a demonstration, check out scenario "Dragon" of the AI-Demos campaign.

Enable the Animals Micro AI by putting

{MICRO_AI_ANIMALS}

into the [side] tag and configure it by using

ai_type=animals

in the [micro_ai] tag.

Required keys:

  • id: The ID of the unit to which this AI should be applied.
  • hunt_x: The x range of the area where the AI will wander.
  • hunt_y: The y range of the area where the AI will wander.
  • home_x: The x coordinate of the place where the AI will return.
  • home_y: The y coordinate of the place where the AI will return.
  • rest_turns: The number of turns the AI will stay at "home".

Other Potential Micro AIs

The following Micro AIs might be added at some point. Feel free to add to this list, if you have other ideas.

  • Leader support
  • Targeted enemy poisoning
  • Protect unit/location/area
  • Annoying AI (grab targets and avoid fights as much as possible)
  • Hunter AI (e.g. wolves)
  • Orderly retreat