+- Southperry.net (https://www.southperry.net)
+-- Forum: Maplestory (https://www.southperry.net/forumdisplay.php?fid=15)
+--- Forum: Game Mechanics (https://www.southperry.net/forumdisplay.php?fid=33)
+--- Thread: How can this be explained mathematically? (/showthread.php?tid=31594)
How can this be explained mathematically? - Fiel - 2010-10-16
1. Question:
In the big bang mob damage formula - Given mob attack and player defense, how can I calculate the breakaway point?
Breakaway point - The value in which the defense type chosen by the mob attack formula changes from Flat to Percentage reduction.
2. Observe:
The mob attack formula is well known for using square roots and multiplication. The entire source code is available in the javascript for verification here.
The percentage reduction and flat reduction are also available in the readout of this HTML page, as well as which reduction type the formula chooses.
3. Hypothesis:
The breakaway point is determined by multiplying the Percentage value in the readout by 10000. This is the first value in which the result is reduced by a percentage. Subtracting one from this value ([Percentage Value * 10000] - 1) is the last value in which flat reduction is used. All values at and above [Percentage Value * 10000] are Percentage reduction, and all values at and below [Percentage Value * 10000] -1 are Flat reduction.
4. Experiment:
| DEF | Percentage Value | Mob Attack | Percentage or Flat? | Hypothesis Correct? |
|---|---|---|---|---|
| 10000 | 50% | 5000 | Percentage | Yes |
| 10000 | 50% | 4999 | Flat | Yes |
| 20000 | 70.71% | 7070 | Flat | Yes |
| 20000 | 70.71% | 7071 | Flat | No (Expected Percentage) |
| 20000 | 70.71% | 7072 | Percentage | Yes |
| 20000 | 70.71% | 7073 | Percentage | Yes |
| 9900 | 49.75% | 4975 | Percentage | Yes |
| 9900 | 49.75% | 4974 | Flat | Yes |
| 25000 | 79.06% | 7906 | Percentage | Yes |
| 25000 | 79.06% | 7905 | Flat | Yes |
| 200 | 7.07% | 707 | Flat | No (Expected Percentage) |
| 200 | 7.07% | 708 | Percentage | Yes |
5. Analyze & Interpret:
Some of the values did not turn out as expected. For these values I'm going to assume that they are merely rounding errors and that the base data was not accurate enough. The executable leaves all decimal places during this calculation, and the final result shown in the Percentage Value in the HTML document is rounded to 2 decimal places.
In the course of the game, one additional defense point made a marginal difference on damage taken at the breakaway point. For a very good heuristic, the [Percentage Value * 10000] is still surprisingly accurate and would be worthwhile for any user to quickly determine his damage from the mob without relying on the Javascript calculator.
For future exploration, I think it would be interesting for the mathematicians of Southperry to determine why this heuristic works at all.
How can this be explained mathematically? - Stereo - 2010-10-16
A minor point... if I read the code right, it was flattening percentage based reductions down to the nearest percent. So 70.71% will become straight 70%.
As to why the formula works like that... the exact damage reduction is:
flat: def/4
percent: (def)^.5/200*atk
Solving for atk, such that flat=percent
def/4 = def^.5/200*atk
Rearrange a bit by multiplying by 200 and dividing by def^.5
50*def^.5 = atk
Throw it back into percentage form by extracting 10000
(50*200*def^.5/200) = atk
10000*perc = atk
noting that 70.71% is 0.7071, 10000*0.7071 = 7071 as expected.
How can this be explained mathematically? - Fiel - 2010-10-16
Definitely not truncating the square root. The square root goes into a double and never uses (int) to truncate. It keeps all of the decimal places.
How can this be explained mathematically? - Stereo - 2010-10-16
From http://www.southperry.net/showthread.php?t=31437
Simplified to remove the if stuff, percentage based damage only.
Code:
int v5;
double PDDMultsqrt;
double v11;
PDDMultsqrt = sqrt(PDDMult); // 70.71
v5 = (a5 * PDDMultsqrt) / 100 + PDDMultsqrt; // a5 is some other defensive buff, I don't know what. Anyway, if it's 0, this will be v5=70
(if moblevel > charlevel there's additional work here to reduce the value in v5)
v11 = (100 - v5) * mob_base_damage * 0.01; // 30 * mob damage * 0.01
return v11;v5 is effectively truncating the percentage to a whole number (in this case 70%
.
How can this be explained mathematically? - Fiel - 2010-10-16
Well well, color me wrong then. I'll fix up the formula. Would this make calculating the breakaway point any more difficult?
How can this be explained mathematically? - Stereo - 2010-10-16
It doesn't seem to make a difference, as long as you use the properly truncated percentage. Just due to the /4 rounding I think there's a minor error, though.
Ex. at 10403 def, you get 50% vs. 2600 def -> 5200 is the breakaway point. (50% * 10403 = 5201)
I'd rather just let your automated testing check it out though, if that's what you were using.
How can this be explained mathematically? - Fiel - 2010-10-17
Only my HTML page and guessing is how I arrived at that conclusion.
DEF vs. % Reduction
How can this be explained mathematically? - Russt - 2010-10-17
Truncating the percentage weakens it by a sometimes noticeable amount. It also complicates things, so you'll need an auxiliary value.
For a given value of d, let p = [√(d/4)] be the percentage. Then you have
percentage = flat
pa/100 = d/4
pa = 25d
a = 25d/p.
For instance:
d = 20000
p = [√(20000/4)] = 70
a = 25*20000/70 = 7142.85 <-- this is when flat = percentage.
7142 should favor flat by a marginal amount; 7143 should favor percentage. Note that to find the "breakaway point" as you defined it, you have to take the ceiling of 25d/p. (This also explains the rounding errors in your first post. You took the floor, not the ceiling; same thing applies.)
Verify:
flat: 20000/4 = 5000
percentage: 70*7142/100 = 4999.4 (= 4999)
percentage: 70*7143/100 = 5000.1 (= 5000)
But given that you have to calculate the percentage anyway, I don't see any advantage of this over just comparing the two reductions directly.
How can this be explained mathematically? - Jellyflower - 2010-10-17
Umm Fiel, the reason why those values are off is because pddRounded is rounded, if you get rid of the flooring and +0.5 in that line, I bet your table will be as expected. As to your hypothesis of breakpoint and why it's true, here's your proof:
y = c - x (flat base)
y = (1 - sqrt(x)/100) x c (percentage)
Equate both equations and solve for x
c - x = (1 - sqrt(x)/100) x c
1 - x/c = 1 - sqrt(x)/100
x/c = sqrt(x)/100
Square both sides,
x^2/c = x/10000
x = c/10000, and there's your break-even point.
And for your calculator, you can't use this shortcut because the % curve is not continuous, discrete rather since % reduction is floored. Meaning you should just stick with your code and just add in floor in (100 - floor(sqrt(pddrounded)) * mob attack * 0.01). But you can still use the approximation, which I've been using if your brain works fast, very convenient. And by the way, it's % * 100, not % * 1000 as you said in your first post.
How can this be explained mathematically? - Fiel - 2010-10-17
Jellyflower Wrote:Umm Fiel, the reason why those values are off is because pddRounded is rounded
Well, at least I got that the error was in rounding, just on the wrong value!
Thanks for the proof.
Jellyflower Wrote:And for your calculator, you can't use this shortcut because the % curve is not continuous, discrete rather since % reduction is floored
I went into this topic thinking it was not floored, and now I know that it is floored after this thread. It was because I thought it was not floored that I thought this heuristic would work.
Also, it's not % * 100. 70% is 0.70 in decimals, so multiplying that by 100 would only give you 70 and not the 7000 required.
How can this be explained mathematically? - Jellyflower - 2010-10-17
Yea it was just my shorthand, I was just wanting to point out your typo in section 5. You got it right at the start though.