I'm unclear as to what R, A, and D are. I'm pretty certain I follow your point though, since I'm using the above equation to compare it to the below ones.Ive 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)).

I think that we're largely on the same page. Here's my thought for interface; each of these would be accessible via XML: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, itll 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 wouldnt 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, youll 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.

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS (default value: 0) This would allow a variation of +/-

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS/100 points of damage.

COMBAT_SMOOTH_RELATIVE_HUNDREDTHS (default value: 0) This would allow a variation of * +/-

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS/100 points of damage. This is applied before COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS .

COMBAT_SMOOTH_ABSOLUTE_DICE (default value: 1) If COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS is set to a non-default values, then this indicates the "number of dice" used to generate the value in the given range. The "dice" would be of largely equal size.

COMBAT_SMOOTH_RELATIVE_DICE (default value: 1) If COMBAT_SMOOTH_RELATIVE_HUNDREDTHS is set to a non-default values, then this indicates the "number of dice" used to generate the value in the given range. The "dice" would be of largely equal size.

So, for a few examples (any non-described value would be a default):

**COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS = 100**

If the base damage were 20, then the actual damage would be 19..21, with an "equal" chance of each result 19.00, 19.01, 19.02,...20.98, 20.99, 21.00

**COMBAT_SMOOTH_ABSOLUTE_DICE = 2**

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS = 100

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS = 100

If the base damage were 20, then the actual damage would be 19..21, with the following probabilities of values:

1/10302 : 19.00, 21.00

2/10302 : 19.01, 20.99

3/10302 : 19.02, 20.98

.

.

.

COMBAT_SMOOTH_RELATIVE_HUNDREDTHS = 10

COMBAT_SMOOTH_RELATIVE_HUNDREDTHS = 10

If the base damage were 20, then the actual damage would be 18..22, with an "equal" chance of each result 18.00, 18.01, 18.02, ... , 21.98, 21.99, 22.00

**COMBAT_SMOOTH_RELATIVE_DICE = 2**

COMBAT_SMOOTH_RELATIVE_HUNDREDTHS = 10

COMBAT_SMOOTH_RELATIVE_HUNDREDTHS = 10

If the base damage were 20, then the actual damage would be 18..22, with the following probabilities of values:

1/40602 : 18.00, 22.00

2/40602 : 18.01, 21.99

3/40602 : 18.02, 21.98

.

.

.

**COMBAT_SMOOTH_RELATIVE_HUNDREDTHS = 10**

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS = 10

COMBAT_SMOOTH_ABSOLUTE_HUNDREDTHS = 10

If the base damage were 20, then the actual damage would be 17.9..22.1, with the following probabilities of values:

1/8421 : 17.9, 22.1

1/8421 : 17.91, 22.09

1/8421 : 17.92, 22.08

.

.

.

1/8421 : 18.0, 22.0

2/8421 : 18.01, 21.99

3/8421 : 18.02, 21.98

.

.

.

Technically, floating point isn't the best way to implement it (why? because only fractions that are powers of 2 can be represented in floating point). Unless you can think of a reason why hundredths aren't sufficient, I'll suggest calculating using hundredths (that part is already coded, and mostly tested).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.

My main questions are the following:

1) I don't know if you'd have any interest in using both absolute and relative numbers, but if you are interested, is the interaction suggested above useful?

2) "DICE" are designed to make the curve less like a line, and more like two halves of a normal curve (kinda like an s-curve); presumably, the more dice, the higher the smoothing. Do you think that this sort of feature may be useful?

I guess that I should note that modifying combat is pretty easy - I can probably do that in a few hours. The tricky part (both coding and computationally) is calculating odds. I think I have a good approach, but it will take a bit more time.