log in or register to remove this ad

 

5E Trivantage Simulator

Thanks to three recent threads (here, here, and here) involving Elven Accuracy, I decided to write a monte carlo simulation to see how it interacts with a few things. I'm especially interested in rogue builds, but I wanted to see what the effects of 1 or 3 level Fighter dips might do.

I didn't model everything, such as Action Surge, or the difficulty/probability of getting advantage. I only included features that would get used every round that the rogue has advantage.

Disclaimer: I didn't meticulously error check the results, so there may be a glaring flaw. Feel free to pick my code apart. (Anybody knowledgeable enough to read the source code also knows how to find it.)

http://trivantage.herokuapp.com/
 

log in or register to remove this ad



Rapier booming blade damage at 18 is less than 17...
Yeah I’m seeing slight declines in straight rogue going from odd to even levels. There should be zero change, but of course this is a simulation with random numbers so anything is possible. I’ll dig around; it might be a bug or it could just be statistical variation.

Or....I could throw out the simulation and just do it analytically.
 




TwoSix

The hero you deserve
Supporter
Yeah I’m seeing slight declines in straight rogue going from odd to even levels. There should be zero change, but of course this is a simulation with random numbers so anything is possible. I’ll dig around; it might be a bug or it could just be statistical variation.

Or....I could throw out the simulation and just do it analytically.
If I remember correctly, the odds for any roll of N with trivantage is 3(N^2-N)+1 over N^3, if you don’t want to brute force the odds.
 

CodeFlayer

Explorer
If you have an intractable error, I find constructing a simpler case, whose purpose is to confirm base assumptions/design, can be very helpful.

Your code has many references to specific class/weapons (which is good in terms of features), but may obfuscate the core mechanisms under test - an additional layer may help that encapsulate core mechanisms (if any, and it may be present I just missed it). Of course, I am 5 years late to the 5e party, so please take my thoughts with a good dose of skepticism.

Consider enumerative solutions in some situations, and the best computational thinkers of our age will also have mastery of analytical methods (imo). One can inform the other, and who doesn't love party tricks with statistics?

--CodeFlayer

added note - not a js person, but is was fun to look around !
 


If you have an intractable error, I find constructing a simpler case, whose purpose is to confirm base assumptions/design, can be very helpful.

Your code has many references to specific class/weapons (which is good in terms of features), but may obfuscate the core mechanisms under test - an additional layer may help that encapsulate core mechanisms (if any, and it may be present I just missed it). Of course, I am 5 years late to the 5e party, so please take my thoughts with a good dose of skepticism.

Consider enumerative solutions in some situations, and the best computational thinkers of our age will also have mastery of analytical methods (imo). One can inform the other, and who doesn't love party tricks with statistics?

--CodeFlayer

added note - not a js person, but is was fun to look around !
Yeah I started off with a simple model with essentially no options and tested/tuned it for a while and am pretty sure it was solid, then started adding in the specific rules/options I wanted to test.

I didn't write unit tests along the way, though, so in addition to having possibly mis-implemented those features, I may have inadvertently broken something else.

If js didn't have such an annoying object model I would have written something more modular.

(I'm not a js person either. Hate it. But it was the tool for the job in this case.)
 


Seems like a solid analysis 🤣
@Charlaquin to be less glib...

I should have (and will...) put a key and some axis titles up. But basically:
  • The blue dots/line are straight rogue, the red is 1 level of Fighter dip, and the yellow is 3 levels of Fighter (Champion) dip.
  • The x-axis is level
  • The y-axis is dpr.
  • If you mouse over a dot, it will tell you what level(s) the dot represents, and what the dpr is.
 

Ok, converted to analytical. Makes a lot more sense.

Note: somebody check my logic on calculating criticals. It occurred to me that computing the chance as 1 - (chance of not critical)^3 is true across all cases, but not in individual cases. For example, if you need to roll a natural 20 to hit, 100% of your hits will be criticals, Since you'll only hit 5% of the time, that means you'll do 10% avg weapon damage. Note that multiplying 5% weapon damage * 1.05 does not give you the correct value.

So I don't want to just take 1 - (19/20)^3 and increase all damage by that amount, against all ACs.

Instead, what I did was this:
  • Let's say you need to roll a 12 to hit. That is, 12 + your attack bonus == the target ac.
  • That means there are 9 possible die results that would hit, 8 of which would be a non-crit. So normally 8/9 times you hit you won't crit. (Or 7/9 with Champion 3 dip.)
  • But this is trivantage, so it's really (8/9)^3 times you won't crit. Or 1 - (8/9)^3 you will crit.
  • So after I compute average damage from dice, I increase it by that amount.
  • Then I add damage modifiers (like dex bonus, or dueling, or sharpshooter damage), then multiply that total by the chance you have to hit, which in this example is 1 - (11/20)^3.
Does that make sense?

EDIT: Or.....is this all just arithmetically identical to:
  1. Compute expected crit damage as 1 - (19/20)^3 times average damage, but hold that number for now...
  2. Multiply average damage by chance of hitting
  3. Add number from step 1 back in
I think it is.
 
Last edited:

FrogReaver

As long as i get to be the frog
EDIT: Or.....is this all just arithmetically identical to:
  1. Compute expected crit damage as 1 - (19/20)^3 times average damage, but hold that number for now...
  2. Multiply average damage by chance of hitting
  3. Add number from step 1 back in
I think it is.
That's the easier way. Just remember crit damage isn't actually average damage. It's just your die damage. You'll lose out on mod which will be slightly less than average damage for a rogue.
 


Yes, the easy way to calculate crit in DPR is to split it off.

a) Hit chance * Average dams=age from normal hit
b) Crit chance * Bonus damage from a crit
c) Sum of a and b is average damage

Note that crits are hits, so Hit#=max(2, min(Crit#,AC-ATK)),

Hit%=1-((Hit#-1)/20)^3
Crit%=1-((Crit#-1)/20)^3

You can include Hit# and Crit# in tooltips to help with validation and debugging.
 




Mythological Figures & Maleficent Monsters

Advertisement2

Advertisement4

Top