[PATCH] Add PreferredClasses and RestrictedClasses to Attack component

[historic_bruno]

This is an idea to solve the following problems:

• Some units can attack entities they shouldn't be allowed to attack:
  • Females can attack anything
  • Animals can attack buildings
• Units always attack the nearest enemy entity when not otherwise occupied:
  • Siege weapons chase units when they should be attacking structures instead

PreferredClasses is proposed to list classes of entities that the unit prefers to attack, in other words this would change the current UnitAI behavior.

RestrictedClasses is proposed to list classes of entities the unit is never allowed to attack, this could be checked in UnitAI as well as the Attack component.

The classes would come from those specified in the Identity component ("Unit", "Structure", "Cavalry", etc.)

[Zsolt Dollenstein]

Preferred/Restricted Classes are per attack type to make it a bit more flexible. For example a vehicle could run over an infantry unit (charge) but may not use its regular attack on the infantry.

When a unit searches for a target, it prioritizes those that have an associated PreferredClasses entry.

[Kieran P]

Thank you. Excellent work. I've tagged the topic with [PATCH] and moved it to the Alpha 10 milestone. Someone should be able to review your patch within the next 1 or 2 weeks and let you know if anything needs changing.

[Zsolt Dollenstein]

Thanks! :)

I was thinking of prepopulating PreferredClasses in the template xmls based on the attack bonuses that are already there. If an attack type has a bonus multiplier > 1.0 against class X, then X should be in PreferredClasses of this attack type. I can probably write a small python script to do this automatically and then we can review them on a case by case basis.

Let me know what you think

[Kieran P]

We have a guy (Michael a.k.a Mythos_Ruler) that does all the unit balancing and XML tweaks needed. So once your patch is reviewed and applied, he'll go through and make the required template changes.

[historic_bruno]

Replying to zsol:

I was thinking of prepopulating PreferredClasses in the template xmls based on the attack bonuses that are already there. If an attack type has a bonus multiplier > 1.0 against class X, then X should be in PreferredClasses of this attack type.

Interesting idea and worth discussing in more detail. It sounds like if we did that, we wouldn't necessarily need an explicit PreferredClasses element. I don't know if there are exceptions to that rule, like a unit that should have a preferred class without a matching attack bonus.

[michael]

I think what a unit "prefers" to attack should be broader than the attack bonuses. We don't want the game to decide battles for the player. Part of winning battles is successfully micromanaging units to attack the units they are best at defeating. So, here's what I'd like to see:

"Meat" units, like citizen-soldiers, champions, and heroes should be restricted from attacking most buildings. Later we will add capturing, so that instead of attacking a (e.g.) Barracks, they attempt to capture it instead. This should be flexible, so that we can allow units to attack some types of buildings (palisades, farm fields, outposts), but capture others (barracks, etc.). Some buildings, namely City Walls, meat units can't attack or capture--they will require siege units top bring them down.

Siege unit templates: siege_rams: restricted to only attacking buildings. siege_onager: prefers attacking buildings.

I may develop more thoughts as the discussion continues. siege_ballista: no preference (will attack whatever is in range).

[leper]

Thanks for the patch.

Some issues and suggestions:

Attack.js
Add an example to the schemas <a:example>.
To check if something is present in preferredClasses (or restrictedClasses) you should use ...Classes.indexOf(value) != -1;.
In CompareEntitiesByPreference() exchange 1 and -1.
It would be good to add some sort of counting to this function to check what target has the most preferred classes.
You should change the byPreference filter to use this modified function.
Just curious but why did you use const instead of var in GetBestAttackAgainst?

UnitAI.js
In CanAttack() replace the TODO with a call to cmpAttack.CanAttack(target).

Should we remove GetBestAttack? It is only used by GetQueryRange() and that can be replaced by a new function like GetHighestRange().
You could also take a look at components/test/test_UnitAI.js and maybe add a test or modify the existing that uses GetBestAttack.

[Zsolt Dollenstein]

Replying to leper:

It would be good to add some sort of counting to this function to check what target has the most preferred classes.
You should change the byPreference filter to use this modified function.

So there are two possibilities here:

1. Prefer attacking any target that is mentioned in PreferredClasses
2. Prefer attacking the target with most classes mentioned in PreferredClasses

I personally think the first option is clearer to understand from a gameplay point of view, but I'm happy to implement the second if the general consensus leans towards it.

Just curious but why did you use const instead of var in GetBestAttackAgainst?

I think it's good practice; frankly, I should have used it in more places :)

Should we remove GetBestAttack? It is only used by GetQueryRange() and that can be replaced by a new function like GetHighestRange().

I think that's sensible.

I'll implement the rest of the suggestions soon

[michael]

I think what classes a unit automatically targets should be as general as possible. So I think *1 is fine. I may change my mind and want *2 after playtesting, but *1 is fine for an initial implementation.

[Kieran P]

@ZsoL Just recapping what a few of us talked about in IRC:

• PreferedClasses is only used when an idle unit is looking for a new target (it should not affect a unit already attacking something). This ensures a players command doesn't get superseded.
• Finding a unit to attack is done by the order of PreferedClasses. So if a women had <PreferedClasses>AnimalDomestic AnimalPassive AnimalSkittish</PreferedClasses> would mean that the women first goes for domestic animals (sheep/goats) within her view, then when those are gone, goes for passive animals (chickens), and when those are gone, goes for skittish animals (deer). Once those are done, the women becomes idle. (would be nice if she started gathering food (farms,berries) but that is outside the scope of this ticket).
• The order of RestrictedClasses doesn't matter.

Example for women:

<PreferedClasses>AnimalDomestic AnimalPassive AnimalSkittish</PreferedClasses> <RestrictedClasses>AnimalAggresive</RestrictedClasses>

How long do you think those changes will take to implement and patch? We're keen to have this in Alpha 10.

[Zsolt Dollenstein]

I think of all the above this logic makes the most sense :)

Replying to k776:

How long do you think those changes will take to implement and patch? We're keen to have this in Alpha 10.

This Saturday is a working day in Hungary, but next weekend will be 4day long, so I'll definitely have time to do this (and #748 for osx) then.

[Zsolt Dollenstein]

Add RestrictedClasses and PreferredClasses to the attack component

[Zsolt Dollenstein]

Implemented everything above.

[leper]

In 11710:

Add Preferred and RestrictedClasses, based on patch by Zsol. Fixes #1144.

[leper]

Thanks for the patch.