More of a suggestion about Rubick spell strategy

[forest0xia]

Currently you are checking one hero by one hero, one ability by one ability, and one condition by one condition, to see if Rubick can use any of those spells.

1. This is time consuming. The computation grows linearly or even exponentially as you add more heroes, abilities and conditions to check for.
2. This is error prone. The possibility of having errors grows linearly as you add more ability support. And you may forgot to update spells for Rubick after updating the same spells for the original hero logic that has the spell, or vise versa.
3. This is not scalable and no generalized fallback.

I'd suggest to think it from another perspective - add all abilities to a ability pool. Such a pool will be like a key-value match for each spell. The key is the spell name, value is the way to use the spell. This way:

1. O(1) match for any spell retrieval.
2. Extendable to support other fun dota2 modes like Ability Draft. Later you can delete all heroes ability usage logic from their dedicated lua files and use the ability pool.
3. You can further extend the game performance by reducing the amount of condition calculations like: getByHeroes, Unit to unit distance, etc that basically almost repeat for all spells, we dont need to re-calculate those in the first place. This is the main reason why the frame (fps) drops.
4. Use a generalized fallback mechanism to support any other not yet supported abilities. The general idea can be: steal a spell, if it's a aoe, use it as aoe when possible, if its a single target dmg spell, use it directly to a target when possible. Etc. You can change the logic for the conditions but it will unblock the Rubick to be more playful.

[ryndrb]

Yeah, a general pool is definitely the way to go. It's something I've been meaning to do, as copy-pasting existing logic (which I change sometimes) across multiple files has been tedious and just isn't good. This is why I've rarely added newer stuff to Spell Steal since adding Rubick. As you mentioned, error-prone and not scalable. It'll take a while.