G
Guest 6801328
Guest
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.)