Board Thread:Wiki discussions and announcements/@comment-3308937-20150122092301/@comment-24981764-20150126060038

Double Slap wrote: Nice app. Since nobody seems to have questioned it, I'll make that first bold move. This is to emphasize any assumptions your app makes to allow experimentation. Thank you! And I'm glad to engage in discussion over these things - I'm definitely making assumptions to get it to work, even though I'd like to decrease the number of these assumptions over time. *What condition of fighting is the player in within the "combat-period?" My assumptions are that the player is going spam-ham and is using all their spells at 100% efficiency. Maybe even more so if this ignores the fact that a champion is unable to cast a spell and auto-attack at the same time and cast multiple spells simultaneously. You are exactly right - they are going spam-ham at 100% efficiency. Before the combat period, they are at full health and haven't expended any resources. If they have stacks (like akali shadows), these are all expended immediately before starting to wait on the cooldown. I suppose I could reduce auto attacks by the number of spells cast, except that I wonder - how long is the delay of a spell? If I had that number, I could just reduce auto attack rounds over the combat period appropriately. Although, auto attack resetting skills and non-interrupting skills would have to be accounted for, then, but, it could be done. **What is the accuracy of the spells and autoattacks? Am I to assume that the spells and autoattacks are landing 100% of the time? Yes, 100% - I suppose I could make this a thing one could adjust. Also, while I'm at it, right now if AoE is enabled it uses hits against all 5 enemy champions (or all other allied champs for friendly AoE) in its calculations. Again, I could perhaps make it a selectable # of AoE targets, and that would solve that one. *How is the dynamic of range calculated? Range not only being in movement speed, but also the range of spells and autoattacks. Range is something that I did include in my spreadsheet prototype (for personal use), but that I didn't implement (yet) in my web app. It led to some really wacky numbers for global abilities, although it's pretty wacky already with things like Rek'sai's ult, whose range DOES matter. Of course, the longer the range the more valuable the skill, and the larger the hit box, also the more valuable. I have been putting a range property into the abilities, so really it's a matter of programming the attribute in to make it relevant. It's just been low on my priority level, since I feel like it could be misleading and distorting. My plan right now with range is to multiple the value of abilities by a ratio of Range/AverageAutoAttackRange, as a sort of a measurement of what is short or long range, and to get a sense of how the range amplifies the ability's value. As you can probably tell, this is a somewhat questionable method, but I more than welcome all suggestions of how to better integrate range into the evaluations. And of course I intend to put in a checkbox to turn range ratios on and off - off being the default, and how things are now. **Is vision a factor in this app? Am I to assume that I can see my enemy clearly 100% of the time? I assume that I do because ranges on autoattacks and targetable abilites would reduce drastically otherwise. Yes, the app assumes you can see the enemy. Vision is valued with a sort of hacky method, valuing any individual vision at 75g. For instance, the Twin Shadows active has a value of 75g*2 every time it comes off cooldown. Ashe's vision ability also has a value of 75g. As you can probably guess, this was because I couldn't really think of a better way of doing this. But if you think about it, if people have other vision items/abilities, they will probably buy fewer wards - so maybe it's not so far off after all. *Is terrain a factor in this app? I am assuming that terrain is disregarded as the movement speed formula from jumps and knockbacks becomes too variable if terrain is added. No, not yet at least. I was thinking of figuring out the walking distance increase of jumping over an average sort of wall, or maybe finding the longest wall and taking the average between it and no wall.

Also, part of the reason why Ryze is so damn valuable (not that anyone asked...), is because of the way mana is valued right now. My main concern with valuing stuff is valuing future purchases, so as such, if the champ needs no extra mana in their mana pool over the combat period (factoring in the amount gained from mp5), then I'd like for mana to be worth 0g. But if their costs would go over their mana pool, then I want mana's worth to be based off of how much extra value they could squeeze out of their abilities, on average, for every extra 1 mana in their pool. Ryze at lvl 18 will dry up his base mana pool, so this triggers his mana as being worth something - both purchased mana AND base mana (groan) - on top of this, his mana ratios up his mana value even higher, causing his base stats to be about double everyone else's at lvl 18. As you can see, this is a bug and I'm trying to think up an appropriate workaround. I guess one would be to value the base mana of everyone, but separate that calculation from the mana value in their purchases. If there are any thoughts on this, they are also welcome.