I’ve been thinking about it a bit
I think the best way to implement this would be to have damage as a floating points to 2 decimal places, and multiply the damage by a small random factor.
Currently
Damage = floor(20*(3+R)/(3*R+1)) =floor(20*(3*A+D)/(3*D+A)).
Option1: simple to implement, much better then the old jump point system, but far from perfect (i'm a perfectionist).
So if we change it to
Int Damage
Damage = floor(20*(3*A+D)/(3*D+A)+Random)
Where: -0.5<=Random<=0.5
You get something like the black line in the following graph
now to calculate the probability of success
Success=prob of win with N hits*chance of N hits+Chance of win with N+1 hits*chance of needing N+1 hits
This is a linear relation actoss the affected area.
Option2: much better, works smoothly in central region
The best way to do it, (but would require floating points). Is not to round damage off and keep it as a floating point.
This would make a
float Damage
Damage = 20*(3*A+D)/(3*D+A)+Random
or
Where: -0.5<=Random<=0.5
end of combat:
Winner final HP= roundup(HP)
It must be rounded up, as if the winner just wins with 0.3hp leftover, it’ll cause mutual destruction if not rounded up.
One effect of this is that the graph will be more smooth, as the change in damage would be not descrete, and would be dependant on the exact ratio.
Eg the point currently at R=1.83 where damage changes from 17 to 16. in a floating point system this would occur at a more appropriate place, when damage=100/6=16.67. Thus it would slightly change the location of the jump point so that all jump points are evenly spaced out, giving a much smoother curve when rounded off. Hence the region of effect would be 16.67±0.5. the 14-15 jump point would be moved to 14.28, and have region of effect over 14.28 ±0.5
Naturally damage approaches 6.666 as r approaches infinite, meaning that R±0.5 is not a problem as approaching infinite R
Option 3: smoothest probability curve.
Alternatively the random aspect could be applied as a multiplyer. Eg damage*random. Hence making the random factor smaller when damage gets smaller.
Jump point 0: R=1
JP1: The point of 16.67 corresponds to R=1.4438, and
JP2: The point at 25 damage is then R=1.571
JP3: The point at 14.28 damage is when R=2.02
So ratio change from point 0-1 is 1.4438,
From JP 1-3 is 2.02/1.4438 is 1.4
Damage ratios between jump points:
25-33.33 (4 to 3 hits)=1.333
20-25 (5 to 4 hits)=1.25
16.67-20 (6 to 5 hits)=1.2
14.28-16.67 (7 to 6 hits)=1.167
The jump points become closer together are extremely high ratios, but the JP become less significant, e.g. from 99.8% jumping to 99.9% a reasonable choice would be looking at the range to JP3, choosing random equal to 0.2/2+1=1.1 and 1/1.1=0.91. this would mean that above this, (ratios of 3+) there will be a chance that the random factor can make a multiple jump point shift, but that is insignificant as the jump points are insignificant at ratios of 3+, the line from jp1 to 3 would be fairly smooth curve, and the line between jp0 and jp1 would be mostly smooth, except for a very very small ratio region around 1.2 where it would be temporarily changing linearly instead of asymptotically as it wouldn’t be affected by any random factor, this linear region is significantly smaller then the linear region that would be present in option 1 or 2, and overall the probabilities could be approximated by the blue line graph below.
if if you wanted to smooth it out you could chose 0.91<=Random<=1.1
thus at 50% ratio you do 18.4 <damage<22, (50% 5 hits, 50% 6 hits) at J1: D mean=16.67 R=1.4438 you do 15.15<damage<18.34 (50% 6 hits, 50% 7 hits) and at mean damage of 18.18 you do 16.9<damage<19.99 (100% chance of needing 6 hits).
Thus the end points of one probability blending region nearly touch the start of the next region, and hence creating a smoother transition curve as smooth as possible.
Removing the linearity by changing it to integers would change the resulting graph to make it more similar to the blue line (only slight variations).
this will perform more accuratly than option 2 at higher ratio rates as the random factor is scaled with the damage instead of a constant magnitude, but calculating the probability of requiring a certain number of hits and hence hand calculating probabilities of victories will be slightly more complicated then option 2.
Floating point Damage
Damage = 20*(3*A+D)/(3*D+A)*Random
Where: 0.91<=Random<=1.1
End of combat:
Winner final HP= roundup(HP)
Note: that HP left over after victory will be on average the same as before, but instead of having 13, 32, 51hp left over, you’ll probably have a random value in 5-21, 22-40 or 41-59hp left over after battle.
Thus as a side effect we also improved the increments in leftover hp. The probability of having an extra hp left over is directly related to the attacking probability.
xanaqui42, how easy is it to use floating point in the combat damage? Does this provide you with sufficient information to implement it? please feel free to ask any questions.
