User:Flixx/GSoC 2013/Idea AI Recruitment: Purposes

This is not a proposal yet but only a summary of some Ideas for the AI-Recruitment Idea. This page will hopefully advance (itself ;-) ) to a proposal for GCoS 2013 over the next days.

I have made this site, so people (especially Crab_) can have a look at my ideas, evaluate if it is doable and implementable and give me feedback. My username in IRC is flix.

I want to concentrate first on the Purpose-Idea. By reading the SoC Idea pages (including the ones from last year) I noticed there is a ask for a purpose-memory per unit in the ai, so a unit will remember a purpose assigned to it and act later according to its purpose. So I know, that the Idea to have purposes is not new at all. But I have the feeling that the idea to have purposes is underestimated. Especially when it comes to what I call "Purpose-Driven-Recruitment".

I figured out that a many Problems mentioned in SoC_Ideas_AI_Recruitment_2013 could be solved by introducing purposes, purpose_requests and purpose_request_patters.

Purposes

Each unit should have a purpose assigned. Purposes could be:

• ‘no purpose’: this should be the default purpose and is important for backward-compatibility. A unit with this purpose will act like it does now.
• ‘stay with [unit]’ This could be used to form groups or to defend [unit].
• ‘combat [unit]’ This could be used as a refactoring for recruitment_phase::analyze_potential_recruit_combat(): We could first analyze the opponents units, then recruit a unit as counter-unit to a specific opponents unit and then assign the the combat-purpose to the opponent's unit.
• ‘goto region’ This purpose could consist of a coordinate, a terrain or even both. A unit with this purpose will move to to coordinate or try to stay in a given terrain.

Purpose_requests: “Purpose-Driven-Recruitment”

We could introduce a ‘purpose-request’. So a purpose can be requested before the recruitment is happening. For example we could request the purpose ‘goto region’ with (10,9, water). Or we could request the purpose ‘combat Grunt’. And then the AI will figure out what unit is best for this specific purpose, will recruit it and set it’s purpose.

Purpose_request_patterns

A scenario editor could then define not a recruitment_pattern but a purpose_request_pattern instead. For example: “Recruit 2 units good in the water region and 1 unit to combat Grunts”

Solution for many problems

I will now describe what Problems could be solved by puposes and “Purpose-Driven-Recruitment” by using quotes from SoC_Ideas_AI_Recruitment_2013.

• 3) Scenario editors want the AI recruit all units or most of the units, even if some of them might seem suboptimal from 'combat' point of view [...]

We could introduce a purpose-request called ‘diversity’ which can be used inside the purpose-request-pattern. ‘diversity’ will try to recruit units which are currently rare on the map. The units recruited by the purpose-request ‘diversity’ will get the ‘no purpose (default)’ assigned.

• 4) One of the tool that scenario editors usually use to make the AI recruit more diverse units (and also for limiting difficulty), is limiting the number of concurrent recruits of specific type in the field. Now they are doing it via a WML macro - it's better if recruiting would allow parameterization, allowing scenario creators to easily specify some 'what to recruit' hints and limitations. An example would be 'consider recruiting water-based because I want this leader to control the waterways' or 'recruit enough scouts in the first three turns because I want the AI to start capturing more villages early'. The optimal number of scouts varies with the map, of course.
• 5) This leads to another problem - if AI recruits some units thinking of particular purpose, it must use them properly - i.e., if a fish is recruited, it should not be used to move it to land to fight - otherwise, it makes little sense to recruit the fish in the first place

I think I don’t need to explain how the purpose_requests could solve this ;-). From there the whole idea is from.

• 6) Several years ago we tried an approach where the AI was finding 'most important' hexes on map and using the terrain on those hexes to affect it's recruitment patterns (instead of using the entire map)

I don’t know if the algorithm still exists. If yes, it could be used to set a purpose_request ‘goto region’ for this hex. I don’t like the idea of this algorithm to much though. I think everything what goes beyond “find the hex between me and the opponent” will become complex very soon. But of course a scenario editor can specify those important regions by using the purpose_request_pattern.

• 8)Sometimes it makes sense to hold back and not recruit even if gold is available, [because ...]

Maybe this could be achieved by purpose-requests too. We could introduce a purpose-request called ‘no unit’ or ‘save money’. This request will be set, when the AI can figure out that the end is near. When in the recruitment_phase the AI tries to recruit a unit for the purpose-request ‘save money’, the AI won’t recruit a unit.

• 7) Recruiting first is a huge disadvantage, because of possibility to recruit counters to enemy units. So, if the AI recruits first, it should recruit to minimize the potential for counter-recruiting (i.e., by making a balanced army which can't be hard countered by enemy potential recruits)

This could be achieved by setting the purpose_request to ‘diversity’ or ‘save money’ (for the first round(s)).

Complexities

When a unit has a purpose assigned it have to be considered, how the not-recruiting Phases will handle this purpose. Almost all phases will have to somehow weight the purpose against other options. I think this will be the hardest part when implementing this.

Additionally it need to be considered that a purpose have maybe to be updated: It makes no sense to let a unit with the purpose ‘goto region’ stick in this region forever if the fight is elsewhere. A idea is to also update the purpose_request_pattern then to prevent future recruits to have the deprecated purpose.

One could begin to implement this not to use the purposes in other phases but the recruitment-Phase. (So the AI won't evaluate the purposes.) Then the idea of purposes is lost somehow, but still we could make use of the purpose_requests. I'm not sure yet but even this might be an improvement to the current recruitment algorithms. I think problems 3), 4), 7) and 8) can be solved with purpose_requests without touching other phases then the recruitment-Phase.