WML recruitment. Which improvements would you like ?

[Trademark]

Hello,

I'm a GSoC applicant and in this context I would like to improve the current WML markup for recruiting units.
I'm not a scenario & campaign editor, so I wish you can tell me which improvements you would like on the recruitment part.
If you want a better layout of the following, I suggest you to read it here: http://wiki.wesnoth.org/Soc2012_Talbot_ ... terisation.
It's also the page provides by this link which will be updated with your remarks and suggestions.

I came with some ideas that I'm going to share, do not hesitate to tell what's wrong or how to improve it, I'm open to any suggestions.a
You mainly develop a campaign by modifying the ai via the [modify_ai] tag during specific events.
It would be better to resume the recruitment WML in the same place.
I begin with a simple example, admit that you would like to recruit two scout in the first and the second turn:

Code: Select all

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

Now, we assume that you want to recruit fighters in the start but only if there is enough gold (and space on the castle) after recruiting scout:

Code: Select all

[ai]
  [aspect]
    id=recruitment
    [facet]
      [recruit]
        id=scout_start
        type=scout
        number=2
        importance=2
        turns=START
      [/recruit]
      [recruit]
        id=fighter_start
        type=fighter
        number=3
        importance=1
        turns=START
      [/recruit]
    [/facet]
  [/aspect]
[/ai]

The fighter have less importance than the scout, so the AI will firstly recruit scout and than, if possible, recruit fighters. You can notice the use of the keyword "START" described below.

Another interesting application is to program a survival mode, with wave of enemies, we assume that the AI have unlimited gold.

Code: Select all

[ai]
  [aspect]
    id=recruitment
    [facet]
      [recruit]
        id=scouts_recruit
        type=scout
        number=2
      [/recruit]
      [recruit]
        id=fighters_recruit
        type=fighter
        number=1
        increment=1
        turns=2 to END
      [/recruit]
    [/facet]
  [/aspect]
[/ai]

In the first wave, there are only two scouts recruited.
In the second wave, two scouts plus one fighter are recruited.
In the n wave, two scouts plus (n-1) fighters are recruited.

The importance is not specify as we already know that the AI have unlimited gold (so the AI won't have to choose between potential recruits).
We didn't specify the turn either, so it takes the default value "" which means "for all turns".
The tag "increment" is equal to 1, for each turn specify, an additional unit will be recruited. In the example above, a fighter will be recruiting at the turn 2, at the turn 3, 2 fighters will be recruited, etc.

After this little introduction, I'll describe the functionalities.

Inside a recruitment facet

Each recruiting options are specified into a [recruit] tag.
Inside this tag the following key can be used:

• id: Important if you need to access it later to modify it.
• type="": (string) This key takes a comma separated list containing the usage of the units that can be recruited. Common usages are: 'scout', 'fighter', 'archer', 'healer' and 'mixed fighter'. An empty string tells the AI to recruit units according to the internal recruitment algorithm. A random value means to recruit randomly all type of units.
• number=1: (integer) A number greater than 0 will tell the AI to recruit n units of usage type for each turns specified below.
• increment=0: (integer) number is incremented by increment for each turns specified in turns. If increments=3, number=1 and turns=1, 2 than one unit will be recruited during the first turn and four (1 + 3) during the second turn.
• turns="": (string) This key takes a comma separated list containing number specifying the turn. If a unit should be recruited during the turn 1, 2 and 3, the string should be "1, 2, 3". The macro START, MIDDLE and END can be used, START tell the AI to recruit during the first "1/10" of the total turns, and END during the last "1/10". MIDDLE recruits units after START and before END. The keyword 'to' can be used between two values and is provided for convenience, for example: 1 to 3 means "recruit during the turns 1, 2 and 3". It can be used with START and END, but START must be the left value and END the right value.
• importance=0: (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. The increment key will not be applied if the AI cannot recruit all the units specified by number. If two units are equally important, the AI will choose one according to his internal recruitment algorithm.

Because I've never develop campaign and really use WML, I could misused the tags or the entire language. So I would be really happy if you could tell me the stupidities I committed.

I hope you are enthusiast at the idea of ​​having (perhaps) soon these new ideas in store.

Thank you very much for reading me. As I said, any suggestions or critics are welcome.

Pierre Talbot.

[zookeeper]

For turns=, I'd suggest also supporting the "range" syntax used in a couple of other places: 4-12 denotes turns 4 to 12, and so on. So, you could for example have turns="2,3-6,9-14,18".

[Trademark]

I replaced the "-" token with "to" because I think I saw that a list could be separated with comma OR dash, but maybe I dreamed. If you can confirm that, I'll update the doc.

Thank you for your comment.

EDIT: I dreamed, I'll update it.

[taptap]

I am not much into WML. Two things are important for better AI recruitment from my strictly player perspective:

1) Stop recruiting when you achieve a certain balance of forces - saving upkeep and income for later use. (This alone would improve AI performance tremendously and might make a rebalancing of several campaigns necessary.)

2) Don't make the AI rely too much on the information of your current recruits as this is easily exploited. Such as recruiting trolls only to kill the skeletons you recruited first (when you still have wraiths and spectres in the recall list). While it is good that the AI takes your recruits into account, remaining gold and recall list should be considered as well. This is related to the first point, as the AI in with unrestrained recruiting commits to a certain army composition while the player who retained gold might still change his.

3) Make it easy. (Even many mainline campaigns do not utilize the possibilities that exist already.)

[Coffee]

As a UMC WML author that uses aspects and AI parameters I am happy that you are taking on this work Trademark.

However, as it is I would not use the results because of one simple problem -- when the AI is told to recruit a bunch of different units it often does not recruit them in the best castle hexes for scouting villages.

I have found that to make the AI a much harder opponent in my campaign, I have to set the particular hexes for scouts/likely quick units/etc. If it could be made that AI units are picked until a user set point delayed to actually recruit them in the best position to get villages, this would be a huge improvement to the game in certain small/medium size maps.

Please note that some units are 'quick' and it is often better from a strategic point of view to get a non-scout unit (as it is cheaper and more powerful) where possible.

If you could "fix" the AI problem of over-recruiting scouts that would be a good thing also with your new syntax to recruit a certain number of them (could be randomized from a list of recruits).

So, in short, a second solution (although less nice) could be just specifying a list of possible recruits in a string and an (x,y) coordinate and turn number in an aspect for recruiting. This would simplify/improve my code a lot and perhaps bring this change to other scenarios/campaigns.

[Trademark]

@taptap: Your ideas are great even if you are not a WML user. My proposal is not only about WML, I've updated it with your first idea. I understood it like this:

"However, the AI should not use all the gold, and should maintain reserves for later. In this case, the problem becomes, "when is it later ?". In fact, the AI will recruit a balanced army, if a balance army doesn't cost all the gold, it's great. If it uses all the gold, then it's maybe the smartest decision, otherwise we could lose. The expression "balance army" should be defined as well: it means the AI have an army that could beat the current enemy units on the map without recruiting others. The AI army is just a little more powerful that the enemy army."

If you have any comments, do not hesitate.

Your second point is closely related to the gold and much more specific, I'll take it into account later.
Finally, I'll try to make it simple, but if I'm walking out the way of the KISS principle, do not hesitate to tell me it

@Coffee: I'm not sure to understand everything you said. However, the placement of scouts in the castle could be "resolved" by first recruiting n random units and then recruiting scout with a lower importance, couldn't be ? BUT I think it's just a workaround and I don't really see the relation with WML. Don't you think it's the internal algorithm which should select a recruiting list first and then recruit in the best order with the best location ?

Thank you both for your useful comments. It's helping me to clarify obscure points. Do not hesitate to tell me your next ideas.

By the way, I'm not updating the first post, I'm updating this: http://wiki.wesnoth.org/Soc2012_Talbot_ ... as_you_can

Notes:

• I added a "tip section".
• I clarify some points in the doc.

I though about another improvement, what do you of anther keyword "objective" which is a hint a the purpose of an unit. For example, if an unit is not a scout but we want to act "as a scout", we could do objective=get_village. Moreover, we could specify more than one objective ! For example, objective=get_village, attack is a unit who first try to get a village and then attack.

[Alarantalara]

What Coffee is referring to is the following situation.

There is a village that is 6 hexes away from the closest castle hex, and 7-8 from other ones.
Player has a unit with 5 moves that is a good combat unit, and a scout with 8 moves that could be recruited.
The player would prefer to recruit two of the combat units — they are cheaper and will be more effective in combat against the opponent — but also wants to get that village next turn.

Therefore, the player recruits a combat unit in the castle space 6 hexes away. If that unit is quick, then the village can be captured and the other unit recruited is a combat unit. If the unit is not quick, then a scout is needed to capture the village and so one is recruited, and is preferably recruited at a location where the target village is the exact movement away (may let a slower unit start a bit further forward).

If there are two castle spaces 6 hexes away, then the player may try for a quick unit twice before recruiting a scout.

So the number of scouts to recruit ideally ends up depending on the number and location of units recruited with the quick trait. It also means there is a tendency to recruit from the outside in rather than the default inside out.

Perhaps a [location] facet might allow controlling this to a certain extent if a limited amount of conditional logic is allowed in it.

Code: Select all

[location]
     id=quick_unit
     x,y=10,10
     importance=2
     desired_trait=quick # so that only units that can get the quick trait are picked here
     move_min=5 # or some other way of specifying what units to try first
     turns=1
[/location]
[location]
     id=scout_back_up
     x,y=10,11
     importance=10
     [filter] # filter makes rule turn on and off, result may change as units are recruited
         x,y=10,10
         max_moves=5 # to make the rule turn on only when a unit that is too slow is in the primary hex
     [/filter]
     turns=1
[/location]

So the engine would use the location facets to recruit in the order they specify by importance, choosing units from the recruit facets if possible, then fill in any unspecified locations with what remains of the recruit facets, then applies the default recruit rules.

[taptap]

If you have any comments, do not hesitate.

Trying to flesh out my idea a little more:

The problem is the AI recruits more units than can be effectively employed at a time and it does invariably so if not limited by small recruiting space or absence from the keep and all too often those units do nothing but to pile up behind the front, yet they still cost upkeep. Often this pushes the AI into negative income or highly negative overall gold even when it is completely avoidable. This leads to the typical "survive one wave then mop up" play against the AI, where the AI has no chance for later reinforcement due to the built-up negative gold. The "solution" to this problem in many campaigns is ridiculous high AI income or completely arbitrary reinforcements / gold boosts which is contrary to the complete information I would expect.

Some factors are: gold/income obviously, length of front, length of "supply line" to the front, AI objective.

E.g. in some cave scenarios (with the shortest front length) it often would be perfectly fine for the AI never even to let the income be reduced by upkeep, while in open scenarios where you can get many units to effective use or if you have skirmishing units you can employ far more units effectively. This is in some way related to another recruitment topic I like to mention here and there, AI should decide between available high level/low level recruits according to how much units it can effectively employ.

I guess it is hard to decide when to stop recruiting automatically, but this can be left to campaign authors by means of both a "target unit ratio" and "target power ratio" if you are below the threshold nothing changes the AI recruits like hell to build up the ratio, but if it reaches both, it stops and keeps reserves to maintain the ratio when the human players starts killing the AI units. Having both target unit ratio and target power ratio would also address the low level vs. high level recruitment.

[Trademark]

@Alarantalara: I understand now, thanks for this explanation. I don't think it's a good idea to specify the location because it should vary on the map. I think the internal engine and algorithm should be updated to choose itself the better location.

Anyway, I like your key "desired_trait", we could specified it in addition of the type. In a first time, I won't add it, because I already have a lot of work, and I want to hear your feedback from the previous ideas first before doing more. However, thank you, it's a great idea.

@taptap: thank you, it's two well-known problem but you catch my attention to the fact it's not little problems. However I think we should wait an improvement from the recruitment algorithm and then add WML markup to balance and correct the new algorithm. Do you think it's wise ?

Correct me if I'm wrong but I like to differentiate the WML user-interactions with the AI and the internal current algorithm which is not easily alterable. In my proposal the first two points speak about the algorithm and the last speak about WML.

Do you think the differentiation between WML and the internal algorithm should be minimized, or should we improve both and see what is missing from each sides (I prefer this idea) ?