2010-11-27, 11:54 PM
Russt Wrote:But you could probably come up with something to account for endpoints, and criticals and attack combinations and whatnot.
In principle for the more simple ones you could just do
nc(hp) = number of hits to kill, when the next hit is non-crit
c(hp) = number of hits to kill, when the next hit is crit
The two would be calculating with different min+max + size, and then combined to give
e(n) = %crit * c(n) + (1-%crit)*nc(n)
Which would be fed into the next recursive step.
I expect it would take twice as long to run compared to the non-crits version.
For example (simple) if your non-crit range is 1-2, and your crit range is 2-4, with 50% chance of crits,
nc(i) = nc(i-1) + 1/2 * (e(i-1) - e(i-2))
c(i) = c(i-1) + 1/3*(e(i-2)-e(i-4))
Plus some initial conditions
nc(1) = 1
c(1) = 1
c(2) = 1
Which leads obviously to
e(<=0) = 0
e(1) = 1
nc(2) = 1.5
e(2) = 1.25 <- (nc(2) + c(2)) *0.5
nc(3) = 1.625
c(3) = 1.333...
e(3) = 1.4791666...
nc(4) = 1.7396
c(4) = 1.7497
e(4) = 1.7446
etc.
I'm not sure this approach is valid though since it's weird c(4) < nc(4). Probably better to work through the logic on the recursive definitions for nc() and c().

