How can this be explained mathematically?

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.

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.

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.

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%).

Well well, color me wrong then. I'll fix up the formula. Would this make calculating the breakaway point any more difficult?

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.

Only my HTML page and guessing is how I arrived at that conclusion.

DEF vs. % Reduction

% Reduction	Minimum DEF
1%	4
2%	16
3%	36
4%	64
5%	100
6%	144
7%	196
8%	256
9%	324
10%	400
11%	484
12%	576
13%	676
14%	784
15%	900
16%	1024
17%	1156
18%	1296
19%	1444
20%	1600
21%	1764
22%	1936
23%	2116
24%	2304
25%	2500
26%	2704
27%	2916
28%	3136
29%	3364
30%	3600
31%	3844
32%	4096
33%	4356
34%	4624
35%	4900
36%	5184
37%	5476
38%	5776
39%	6084
40%	6400
41%	6724
42%	7056
43%	7396
44%	7744
45%	8100
46%	8464
47%	8836
48%	9216
49%	9604
50%	10000
51%	10404
52%	10816
53%	11236
54%	11664
55%	12100
56%	12544
57%	12996
58%	13456
59%	13924
60%	14400
61%	14884
62%	15376
63%	15876
64%	16384
65%	16900
66%	17424
67%	17956
68%	18496
69%	19044
70%	19600
71%	20164
72%	20736
73%	21316
74%	21904
75%	22500
76%	23104
77%	23716
78%	24336
79%	24964
80%	25600
81%	26244
82%	26896
83%	27556
84%	28224
85%	28900
86%	29584

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.

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 &#37; 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.

Quote:

---

Originally Posted by Jellyflower

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.

Quote:

---

Originally Posted by Jellyflower

And for your calculator, you can't use this shortcut because the &#37; 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.

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.