User:Flixx/Configuration Specifications

The specifications are Work in Progress

All configurations can be implemented by aspects (inside the [ai] tag).

I want to seperate my Ideas for configurations in two parts:

Easy understandable configurations

The following configurations are intended to be easy understandable without knowing details about how the recruitment analysis works. Some of those configurations are often requested features in the forum.

recruitment-more-diverse = no (boolean)

When this flag is set the AI will recruit more units which are currently rare on the map. I will decide later how much more is. For a exact tweak of diversity see below.

recruitment-more = "Orcish Grunt" (string)

comma-separated string of unit-types ("Orcish Grunt") and/or usages ("fighter").

This is meant to let a scenario editor make a easy hack when he/she wants the AI to recruit more units of a specific type. I will decide later how strong this configuration will be considered during the recruitment phase. One could also think about doing something like recruitment-more = "Orcish Grunt, Orcish Grunt" to make the instruction to recruit more Grunts even stronger.

recruitment-level-pattern = "0111223" (string)

unseparated list of numbers (levels)

This one is inspired by this idea in the forum. When a recruitment_level_pattern is given the AI will similar to recruitment_pattern only recruit units according to given level ratios.

recruitment-counter-strategy = no (boolean)

When this flag is activated the AI will also do a counter-recruitment analyses. I cannot say yet how exactly the AI will behave when this flag is set.

recruitment-instructions = "3:Orcish Grunt, 3:Orcish Assassin, 5:Orcish Assassin" (string)

comma-separated list of the form "[Turn]:[Unit]"

This instructions will overwrite all other configurations. The AI will then recruit the units in the given turn (if there is enough money). One could also think about to let the AI plan to save money in previous turns.

This "recruitment-instructions" is by far the most complex configuration (and needs discussion). Recently I came across trademarks forum-thread about his idea of configuration this (he applied last year for Recruitment Refactoring). To be honest I like his approach for recruitment-instructions more. It is more flexible, extendable and corresponds with the existing recruitment aspect to [limit] recruits.

I will repeat his idea here in a slightly modified form:

[ai]
  [aspect]
    id=recruitment
    [facet]
      [recruit]
        id=scout_first
        type=scout
        number=2
        turns=1,2
      [/recruit]
    [/facet]
  [/aspect]
[/ai]

• id: Important if you need to access it later to modify it.
• type="": (string) This key takes a comma separated list containing the unit-type or usage of the units that can be recruited. A value "random" means to recruit randomly all type of units. A empty string means that the AI will decide what to recruit (so "" means kind of all units).
• number=-1: (integer) A number greater than 0 will tell the AI to recruit n units of each usage/unit-type for each turns specified below. -1 means as much as possible. 0 means do not recruit
• increment=0: [I will not implement this]
• turns="": (string) This key takes a comma separated list containing number specifying the turn. '-' can be used between two values to define a range. A empty String means all turns.
• importance=1: (integer) The importance of a recruitment tells the AI to firstly recruit units with the highest importance. If gold is lacking or the castle is full, only the most important units will be recruited, the other will be dropped. If two units are equally important, the AI will choose one according to his internal recruitment algorithm.

Notes:

• If there is more then one unit specified for recruiting (with the same importance), the AI will decide what to recruit.
• By default when recruitment is specified for a turn, the AI will not recruit any other unit. (So if we say recruit 1 scout in turn 1 then the ai will only recruit 1 scout and not more). To prevent this behavior one can do this:

[recruit]
   id=recruit_more_then_specified
   importance=0
[/recruit]

According to all the default values above (all types, as much as posible, all turns) the AI will now fall back when all other recruitment jobs are done.

• One could think about including all other configurations I specified on this page inside [recruit]. Feedback for this important design descission is needed.

Tweaking Configurations

The following configurations are intended to tweak some inner functions and weights. In order to use them one should have a idea of how the recruitment works.

Most likely I will implement those things:

recruitana-combat-weight = 1
recruitana-map-weight = 1
recruitana-counter-weight = 1
recruitana-counter-counter-weight = 1
recruitana-diversity-weight = 0

With this configurations one could adjust the weights of the scores coming from the analyse-algorithms. I want to normalize the default weight to 1 (or 0 if the analyse-algorithm is not activated by default). So one could double the impact of a algorithm by setting the weight to 2 or half the impact by setting the weight to 0.5.

This is a rather a vague guess about how some specific analysis-functions could be tweaked further. I will not specify them further yet.

recruitana-combat-range = 100
recruitana-map-village-range = 1
recruitana-counter-turns = 2

Notes

1. I will pay attention not to break the existing configurations 'recruitment', 'recruitment_pattern', 'recruitment_ignore_bad_combat' and 'villages_per_scout'.
2. Before all the analysis-algorithms run the units which are considered for recruitment (and get a entry in the score-map) will be filtered according to some configurations.
3. Some combinations of configurations will cause impossible instructions. For example if a recruitment_pattern and a level_pattern are given. So some configurations will overwrite others. I will the *what overwrites what* list define later.