[PATCH] Attack preference based on bonus

[dumbo]

When new entities come on the sight of unit, it will collect all units on range into array, which is sorted by distance. Closest first. Now, in function AttackEntitiesByPreference it sorts whole array on preference based on element PreferredClasses, which basically means division between structures and organic units.

This patch introduces new function GetAttackBonusPreference which goes through enemy units in sight and attacks the closest unit with highest AttackBonus. In other words, when choosing the unit to attack against, preference goes to where the attack is most effective.

This has a noticeable performance gain especially in big combats. Patch was profiled in Combat Demo (huge) with 300 vs. 300, 160 vs. 160 and 80 vs. 80 units. In my setup (Intel Core 2 Duo 2.4GHz, 2gb RAM, GeForce 9400 GT) patch gave consistent 50msec/frame improvement over the old method of choosing preference.

Graphs: ​http://imgur.com/qCGDTLt,4SwQNwc,ePATSD6

Edit: After removing hardcoded max AttackBonus of 2, now every array will go through for maxbonus. little performance damage, but still faster than original:

Graphs: ​http://imgur.com/AuOhlHZ,7TGfy0h,OnOf6nz

TODO: get max attackbonus for unit and set that to maxbonus. If that is found, attack without going any further in array.

[dumbo]

removed hardcoded max bonus

[Tom Brewe]

just as an additional idea: what if we have a certain chance, that a given unit doesn't attack the one against it has the highest bonus but the closest one. so it reflects more an organic, partly chaotic battlefield. (eg 75% chance attack with biggest bonus like you implemented in the patch, and 25% chance simply to attack the/any closest unit).

This will have to be decided under design principles and balancing i guess.

[michael]

I don't like this from a gameplay standpoint. Also, we already have PreferredClasses. I think your patch extends this too far and starts playing the game for the player. Right now I think combat is too micro-heavy, but I don't think this approach is best.

[Marcio]

Can be button in GUI that, be enable or disable, only for test it. If is not good as Michael say we can revert this one.

[dumbo]

Added primary preference by class

[dumbo]

I have no idea how to make a GUI button. It is probably easiest to test by playing and it's very easy to revert by svn revert.

v.4 of the patch is modified to take PreferredClasses into account. So now it looks for the best bonus in the preferred class. If there are units that one can attack against but not in the preferred class, it will still attack unit with the best bonus.

This doesn't play the game too much for the player. It only takes account of the units in the line of sight. If there comes more units in los while attack is already underway, it will continue attack if not told otherwise.

Still to be developed is to find out first what is the best bonus unit can achieve. Then we can stop going through units in sight in the moment we get the first unit with highest achievable attack bonus. This will be performance improvement, but first I need to figure out a simple way to get max attack bonus from the unit.

Second is the behavior after succesful attack. For example, player decisions should be preferred. If, for some reason, player orders attack against group of similar units where there would be no attack bonus, but there is in sight units that one have bonus against, the next target should be chosen from the group that the attack was ordered against. This needs a method to store the type of unit just attacked – if ordered – preferably a generic name of unit. Now it is easy to find the id of the unit just attacked, but identity queries fail on dead units.

However, this v4 should already be playable so we can test it, find bugs and give feedback on how to develop battle behavior.

[Stan]

Moving it to A17 not enough time to test.

[Itms]

Hello dumbo, and sorry for the very long time we left this ticket aside.

Your patch is rather debatable from a gameplay point of view, as michael pointed out, and it will be really difficult to conciliate all the problems that could arise with such a system.

So, even if some players would like to have cleverer units during fights, I'm going to close this ticket because the behavior proposed here is not fitting. If you have other ideas with a lighter impact on the gameplay, don't hesitate to create other tickets! And thanks for your work so far. :)