Redistribution of Legionnaire's Whirling Blade Probability

[[S2]MacroHard]

TL;DR Suggestion

Artificially manipulate the proc mechanics of Whirling Blade such that the probability histogram for a given number of attacks is logically distributed. This new system still relies entirely on chance.

Voting

Please vote on the concept of manipulating the proc chances in order to achieve a pre-designed distribution. Below are two examples of designed distributions; these are only examples. If you do not understand what is going on here please hold your vote until your questions can be addressed.

The Current State of Legionnaire's Whirling Blade

Currently, Legionnaire has a 17% chance to proc Whirling Blade on every attack. If he has not spun for 11 previous attacks, he will always spin on the 12th attack. The chances of reaching this 12th attack is a staggering 12.88%. The result of this mechanic is a skewed probability distribution:




As you can see, the distribution is far from clean. The chance for attack amount is 17% less than the one before it until it spikes at the 12th attack.

Solution 1: Normalized Distribution

The current charge system remains: each attack without a spin adds a charge. The difference is that the probability to spin artificially changes based on the number of charges in order to achieve a pre-designed distribution. The following probabilities were back-calculated to produce a normally distributed probability histogram:




Even though the individual proc chances seem bizarre, the result is a normal distribution. Most of the time he will activate Whirling Blade after 5 or 6 attacks. However, the luck factor is still preserved and he may still spin immediately or after 12 attacks. This distribution is designed such that the effective spin rate is identical to the current method at 19.035%.

Solution 2: Even Distribution

The method is the same as above, but this time the goal is a perfectly even distribution; the chances that he'll spin after 3 attacks is identical the the chance he will spin after 5, 7, 10, etc.




Note that the probability for spinning after 11 and 12 attacks were removed from this method in order to maintain an effective proc rate approximately equivalent to the current method in order to preserve overall balance.

[[S2]ElementUser]

Raise the effective spin rate to be equal or greater than the current iteration and I'll be happier

[[S2]MacroHard]

Raise the effective spin rate to be equal or greater than the current iteration and I'll be happier

I shifted the normal curve such that the effective spin rate is identical to the current method.

[[S2]ElementUser]

Yay!

[changlingbob]

You probably should be using cumulative probabilities instead of flat probabilities. Also, you're neglecting the fact that, after spinning once, the charges are reset. While there's a 12.8% chance you spin after 12 attacks, what should actually be looked at is the number of procs over time; there's a non-negligible chance you get two procs in those 12, or three or more. Your proposed 'fixes' look only at the marginal spin chance, and not at any kind of context. If you want, I'll hammer out the maths, but you appear to have wasted enough time on this short-sighted analysis of what isn't actually the problem.

E: In 12 attack starting at no charges, while there's a 12.8% of proccing off charges, there's a 63% chance of proccing at least twice, a 33% chance of proccing at least three times, and a (staggering?) 13% chance of procing at least 4 times.

[GregerMoek]

People will see a lot of pictures and think "must be legit". ^_^

[changlingbob]

cbob@tinman:~/Documents/hon$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> random.seed()
>>> def dumblego():
...    charges = 0
...    chance = (.1, 1/9, 1/8, 1/7, 1/6, 1/5, 1/4, 1/3, 1/2, 1)
...    attacks = 0
...    procs = 0
...    try:
...       while(1):
...          attacks = attacks+1
...          if (random.random() < chance[charges]):
...             charges = 0
...             procs = procs+1
...          else:
...             charges = charges+1
...    except KeyboardInterrupt:
...       print "%d %d" % (procs, attacks)
... 
>>> dumblego()
^C1739640 15829675
>>> 1739640/15829675.0
0.10989739208164413

Nice 18% overall proc rate on your flat 10% proc. Plus, I showed my working.

Over a large number of 10000 attacks, binomial is a buff of the order of 10% more procs, over 100 attacks it is a buff of about 1% more procs, and over the number of attacks we care about in a gank, say, 12-36 attacks, its between a 0.1-3% nerf, depending on number of attacks.

Recommend not changing due to insignificant nerfs in the time scale that actually matter (low numbers of attacks), and significant buffs over the course of a game spent jungling.

Source code: http://pastebin.com/YSdaMnVi

People will see a lot of pictures and think "must be legit". ^_^

I hope source code counts!

[[S2]MacroHard]

cbob@tinman:~/Documents/hon$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> random.seed()
>>> def dumblego():
...    charges = 0
...    chance = (.1, 1/9, 1/8, 1/7, 1/6, 1/5, 1/4, 1/3, 1/2, 1)
...    attacks = 0
...    procs = 0
...    try:
...       while(1):
...          attacks = attacks+1
...          if (random.random() < chance[charges]):
...             charges = 0
...             procs = procs+1
...          else:
...             charges = charges+1
...    except KeyboardInterrupt:
...       print "%d %d" % (procs, attacks)
... 
>>> dumblego()
^C1739640 15829675
>>> 1739640/15829675.0
0.10989739208164413

Nice 18% overall proc rate on your flat 10% proc. Plus, I showed my working.

Over a large number of 10000 attacks, binomial is a buff of the order of 10% more procs, over 100 attacks it is a buff of about 1% more procs, and over the number of attacks we care about in a gank, say, 12-36 attacks, its between a 0.1-3% nerf, depending on number of attacks.

Recommend not changing due to insignificant nerfs in the time scale that actually matter (low numbers of attacks), and significant buffs over the course of a game spent jungling.

Source code: http://pastebin.com/YSdaMnVi



I hope source code counts!

I included this. Why do you continually insult me in every thread even though your counter-argument is already covered? Look at the charts again: Current effective spin = 19.035%. Suggested normal effective spin = 19.035%. There is NO overall change when averaged over the long run. The ONLY difference is that the spins occur after 4, 5, or 6 attacks more regularly instead of a lot at 1 or 2 and a lot at 12.

As for the even distribution method, it is impossible to get 19.035%, so I put it as close as I could. My last line is even: "Note that the probability for spinning after 11 and 12 attacks were removed from this method in order to maintain an effective proc rate approximately equivalent to the current method in order to preserve overall balance."

[[S2]MacroHard]

You probably should be using cumulative probabilities instead of flat probabilities. ... Your proposed 'fixes' look only at the marginal spin chance, and not at any kind of context.

The above is factually incorrect. The cumulative probability is actually what is graphed. The marginal is back-calculated in order to achieve a desired cumulative probability. On the tables you can find the cumulative probability under "total". For example, using the "normal" table, when you begin a fresh attack sequence after a spin, there is a 14% chance it will take exactly 5 attacks for a new spin. The sum of all the cumulative probabilities add up to 100%.

[[FT5]Anizer]

Method 1 please!!

[Savaii64]

+1 for Method 1

[Mursuvaari]

Method 1 seems pretty good.

[GregerMoek]

I personally don't see anything wrong with the current thing, besides, messing with this is a balance issue despite the so called "effective spin rate" being the same.

The result of ~13% is far from staggering and consider how it was before, where you didn't have any "max" hits before a spin. The only thing that number says is that 12.88% of the time you haven't spun yet before the 12th attack.

Things I am interested in:

Why isn't the distribution clean from your point of view?

The current 17% chance per hit(unless on cooldown) is a rather common thing in games, it only comes with a perk after 12 strikes.

Why isn't the so called unclean distribution fine in the case of other %chance based events such as critical strikes from for example Swiftblade, chain lightning procs from Charged Hammer(both buff and on attack) or counter strike (Swiftblade) or reflecting (Zephyr)? Sure they don't have any "upper cap" but the distribution should appear in a similar fashion for those things too.


Repeating, I am confused as to why this current thing is bad. Now it looks more or less like "Look at this, it's bad, let's change it". I'm not saying you don't have good intentions or haven't thought about it, but there's no reasoning as to why it should be changed other than "it looks better on a histogram" in the OP.

[Hubaris]

As a person who frequently has to hit 12 charges to spin (no kidding, I'll dredge up the replays), I support this.

Just don't touch Blacksmith (because someone somewhere will mention that)

[[S2]MacroHard]

I am confused as to why this current thing is bad. Now it looks more or less like "Look at this, it's bad, let's change it". I'm not saying you don't have good intentions or haven't thought about it, but there's no reasoning as to why it should be changed other than "it looks better on a histogram" in the OP.

It's not so much that it's bad, rather than it could be better. If the designers were happy with an overall 17% chance, then they could leave it at 17% without charges and I would be happy with that. My concern is if the goal is ~19% spins then there are better ways to accomplish that. This new design will dramatically reduce the "feeling" that spins are happening too much (from enemy point of view) or not happening enough (from Legio's point of view).

[[TRb]RowSkin]

I like the charge based, non-random fix better.

[[S2]MacroHard]

I like the charge based, non-random fix better.

This suggestion I feel brings the best of both worlds: still random based yet more consistent. Even if you prefer my original charge-based suggestion, please do not down-vote this one (unless you prefer current over this, of course). As long as you feel this is an overall improvement please show support. =)

[[SMBN]iruul]

Whys is lego's move the only one thats like this and not all the other random proc abilites?

[LordTroll]

I've actually been thinking of an exact same system as Macro suggested for over a year, it would simply make much more sense.

[GregerMoek]

Whys is lego's move the only one thats like this and not all the other random proc abilites?

You mean with a higher cap?

Every other ability that is "random" works like the 11 first instances of the histogram. One way or another.