Primer on calculating DPS stat weights

[LagunaD]

(02-09-2012 04:04 AM)Gorlough Wrote:  Point is, there is no exact mathematical solution to this problem and anything you'd get out of a hypothetical one, would be simply worthless.

Even using simulations, you're only able to find tendencies for a optimal distribution. But the moment you switch one variable (mob, skill, stat, whatever) out - you might be completely wrong again.

Hate to quibble, but there is an exact, mathematical solution to the problem of stat weights (assuming we agree on other player-controlled parameters like ability selection priorities), just like there is an exact mathematical value for pi.

How you go about finding that solution is not really important. Whether iterative, or recursive, or not, any calculation which contains no errors can get arbitarily close to the true value.

I don't see why we should treat this as some kind of metaphysical problem. Anything that happens in the game is ultimately determined by a computer program, and the logic of computer programs is completely predictable. The fact that an RNG is involved does not change that, because RNGs are also predictable, when averaged over a sufficiently large number of samples.

IMO, the real limitations are:

1) Players don't perform deterministically
2) The performance of the network and server are not under player control, and aren't predictable in practice
3) Our knowledge of the game mechanics is imperfect
4) There are practical constraints and diminishing returns on the effort which is worth investing in the problem

[Cosmic Osmo]

Thank you, Laguna, for finally bringing some sense to this discussion.

The variation in player performance and boss-fight scenario restrictions put a limit on how good we need a dps spreadsheet/simulator to be. The game mechanics are actually not that complicated for any class. We can calculate "good enough" stat weights with what we know.

[Caltiom]

Interesting discussion, Nate ( SimulationCraft founder ) already wrote many points you mention between simulation and formulation down on this Wiki Page

Personally I'm a big fan of simulations, mainly because of the complexity argument. Simulating something is extremly easy, as you only have to replicate the InGame behaviour, which is usually done with 2-3 lines of codes, which are also extremly transparent and can be reviewed by other peers.

But to be a bit more on topic:
I remembered a very old thread found in the EJ mage forums:
http://elitistjerks.com/f75/t40398-mathe...ic_cycles/
It's a very interesting read, and it might help those trying to model proc-based classes.

As far as I know most WoW spreadsheets ( including Rawr ) have embraced to some degree a hybrid aproach between formulation and a little bit of simulation. For example the Warrior spreadsheet calculates percentages of certain states with a interative method, and then uses those for calculating the dps with normal formulas.

[RuQu]

Question on stat weights.

It is accepted by all parties, I assume, that if we know the current level of relevant stats and we have an approximation of ability usage, we can arrive at values that show the change in DPS/HPS for a given change in said stats. Whether we arrive there by explicit calculation or through simulating a rotation is not necessarily relevant.

So once we have a value, what exactly is the value of that value? Obviously it will change with gear since there are diminishing returns on most stats and interactions between them.

Assuming that a player's gear bears an opportunity cost, I think it is valid to assume that adding Stat_1 means not adding Stat_2, so it is valid to hold the other stats constant for small changes in Stat_1. But what change do we model for Stat_1? +1, +10, -200 to +200? Obviously we would normalize them to the change from the linear stat (power), but what is the useful range to model?

Or do we simply report Stat+1 values, normalized to Power, and provide a way to directly compare upgrades?

[Cosmic Osmo]

(02-09-2012 11:52 PM)RuQu Wrote:  Assuming that a player's gear bears an opportunity cost, I think it is valid to assume that adding Stat_1 means not adding Stat_2, so it is valid to hold the other stats constant for small changes in Stat_1. But what change do we model for Stat_1? +1, +10, -200 to +200? Obviously we would normalize them to the change from the linear stat (power), but what is the useful range to model?

Or do we simply report Stat+1 values, normalized to Power, and provide a way to directly compare upgrades?

Changes in gear (as in swapping a power mod/enhancement to a crit one) tend to be on the order of magnitude of 10-30 points for the "secondary" stats (power, crit, absorb, defense) and 30-40 points for the "tertiary" stats (accuracy, surge, alacrity, shield). So you can model that range of stat changes if you like. I just calculate the instantaneous slope (the derivative of DPS with respect to power, for example) and keep in mind that the values change as I go.

[LagunaD]

(02-09-2012 11:15 PM)Caltiom Wrote:  Personally I'm a big fan of simulations, mainly because of the complexity argument. Simulating something is extremly easy, as you only have to replicate the InGame behaviour, which is usually done with 2-3 lines of codes, which are also extremly transparent and can be reviewed by other peers.

If you want to hard-code everything quick and dirty, yes, probably a couple lines of code are adequate. But to write something which is extensible and general, you need a description language (analogous to what the NodeViewer shows for abilities in the client files) and a database (XML or otherwise).

You also need a way of describing a priority list, including conditional logic, and plenty of other plumbing.

This is what discourages me from writing a simulator...I don't want to write a different program for every Advanced Class+spec, but I writing a single program that can handle any Advanced Class+spec in a general way is a huge commitment.

(02-09-2012 11:15 PM)Caltiom Wrote:  But to be a bit more on topic:
I remembered a very old thread found in the EJ mage forums:
http://elitistjerks.com/f75/t40398-mathe...ic_cycles/
It's a very interesting read, and it might help those trying to model proc-based classes.

Yes, that is quite interesting. My first impression is that it would tricky to model resource constraints in such a method, a least without making the number of states unacceptably huge.

(02-09-2012 11:15 PM)Caltiom Wrote:  As far as I know most WoW spreadsheets ( including Rawr ) have embraced to some degree a hybrid aproach between formulation and a little bit of simulation. For example the Warrior spreadsheet calculates percentages of certain states with a interative method, and then uses those for calculating the dps with normal formulas.

This is on my list of things to try for my Carnage theory-crafting.

[RuQu]

(02-10-2012 12:10 PM)LagunaD Wrote:  If you want to hard-code everything quick and dirty, yes, probably a couple lines of code are adequate. But to write something which is extensible and general, you need a description language (analogous to what the NodeViewer shows for abilities in the client files) and a database (XML or otherwise).

You also need a way of describing a priority list, including conditional logic, and plenty of other plumbing.

This is what discourages me from writing a simulator...I don't want to write a different program for every Advanced Class+spec, but I writing a single program that can handle any Advanced Class+spec in a general way is a huge commitment.

You can simplify the problem by not allowing the user to select the priority list, or by selecting from predefined rotations. Those are then hard-coded on the backend.

For my Combat Medic Commando one I wrote a simply Ability class that takes the torhead coefficients and initializes the abilities used, after that the stats do the rest. I haven't overloaded the functions to take weapon damage yet since I don't know enough about Gunnery or Assault Specialist to code their rotations. Function calls convert the raw ratings and stats into derived stats, and a hard-coded rotation logic function takes the relevant stats and returns HPS. Cycling through large ranges of stats is as simple as changing the conditions on a for loop that calls the function repeatedly.

Combat Medic is convenient in that it has no RNG beyond base crit change, which can, on average, be folded into the healing value of the spell. Doing Scoundrels will require multiple simulation runs and averaging them to account for the RNG of their energy regen from DS and UH generation from SLRM.

[CaseyTheRetard]

(02-10-2012 12:10 PM)LagunaD Wrote:  This is what discourages me from writing a simulator...I don't want to write a different program for every Advanced Class+spec, but I writing a single program that can handle any Advanced Class+spec in a general way is a huge commitment.

Perhaps you should consider writing modules for the ACs that interest you for simulationcraft-SWTOR? I hear those guys are always looking for more knowledgeable people.</shamelessplug>

[Kaedis]

Quote:Perhaps you should consider writing modules for the ACs that interest you for simulationcraft-SWTOR? I hear those guys are always looking for more knowledgeable people.

I was halfway through writing a near-identical response when I noticed you'd beaten me to it...

[LagunaD]

(02-11-2012 06:05 AM)CaseyTheRetard Wrote:  Perhaps you should consider writing modules for the ACs that interest you for simulationcraft-SWTOR? I hear those guys are always looking for more knowledgeable people.</shamelessplug>

Well, I downloaded the code and looked through it. It appears to be 99% WoW code, with a tiny bit of Consular/Sorceror stuff hacked in. No offense to the folks who did the hacking, and the WoW simulator is nice, but it seems like a shaky foundation to build on for TOR, considering that a huge fraction of the code is (or should be) dead.