I have an almost finished paperdoll character builder and the basics of a simulator. You can even add other classes. All that in lua and as an addon. I just didn't finished it, because SWP gear was clearly better and right now I don't even play.

It's basically like Rawr, but the way I like it. Easier to use and more customizable. Item comparison is done with a spreadsheet, can't be done via simulation because of rounding errors (even after 1000000 fights).
The addon has some bugs (gems..) and I couldn't force myself to finish the build-in spreadsheet. The simulator is event driven, no need to check every x milliseconds (it is very accurate btw). You can insert anything there. I even figured out stuff like Flurry or procs. It can also be slowed down, so your game doesn't lock up and you can do other stuff while waiting. You should be able to do anything with the data you get, sky is the limit. I made a thread in the german forum once, but I think I lost it. They also aren't helpful at all, noone there has a clue about deeper warrior mechanics.


Mine is ten to twenty times faster, if I recall correctly. Depends on how much stuff you cram into it.

Standard deviation is way higher, so high you can't use the numbers for item comparison.

Some things can't be simplified, mostly because of the rage machanic. It will at least be very interesting.
Random numbers are not what slows a simulator down and if you do one you want it to be as realistic as you can.

There is one thing I'm not quite getting. We're simulating the dps output and getting extremely high variance, how does this variance compare to the true variance for "real" wow fights? My dps normally varies by about 10-20% up and down for a specific boss fight (and out of those my guess is that more than half is due to human errors). Is the simulation variance worse than this? In that case something is very wrong with the simulators.

Still, even a 5% variance would make it impossible to use for item comparisons. Would it be possible to instead use a set list of random numbers? That is, you use exactly the same random numbers for all swings but only change gear stats. Some things would have to be rerandomized (e.g. increased rage income makes it possible to do an extra Bloodsurge slam or whatever), but in principle the variance should go down a lot just by having a set random number list for all white swings.

I was thinking if a bunch of "specialized" RNGs would work. Basically, a rng-state would be kept per type of result required: white swings, yellow attacks, on-hit procs, on-crit procs, etc...
These specialized RNGs would be adaptive, basically after running for a while, they would tend to "correct" themselves, and try to yield results that converge to what would be expected of them, or within some set threshold around it... The randomness will be kept somewhat, as for different runs of the simulator, the auto correcting would happen at different times, and never during the initial first few results, ensuring a negligible chance of repeating sequences... This would be statistically incorrect, but correct enough, and it would drastically cut on the amount of simulations required for truly convergent results...

Also, when every modern CPU has at least two physical cores and/or hyper-threading, it's a waste to not make use of this parallelism, so this would again greatly reduce the amount of run-time needed, in addition to making the whole thing scalable...

If we want to get fancy, network-distributed simulations would also be something to consider at the expense of a lot of work, but would make those million-hour simulations possible in a matter of seconds, especially if we're talking about simulating 25-men raids a few hundred-thousand times. A "1-coordinator with n-slaves" system would be somewhat easy to implement given enough time... I believe there are open source frameworks that deal with most of the synchronization and network communication work so it might not even be a lot of work... Might be somewhat unrealistic to think of this as a one-man project, though, especially for a game...


There's a morning un-caffeinated brain-fart...

When running a multi-player sim for just 10 cpu seconds a bunch of times I saw a max variance of only 0.5% (it was the Enhancement Shaman).

Unfortunately, 0.5% variance is still too high for EP generation, but that was only a 10sec run of not-yet-optimized code......

In order to generate valid EP values, the dps_increase from increasing a stat must be far greater than observed dps_variance.

For stats that scale linearly, this is easy: Just increase the stat of interest very high.

For stats that do NOT scale linearly (which is many of them) it is not so easy. If your bracket around the baseline is too large (base-stat_delta, base+stat_delta) then the calculated slope across that range may not represent the actual slope at the baseline point.

But as you narrow your bracket to reduce error from non-linear scaling, you fall prey to error introduced from variance.

When I was maintaining scaling tables for casters over a broad range of gear I found that some stats (and classes) were easy to calculate whereas other stats (and classes) were much harder. Where "easy" and "hard" represent the amount of runtime required to get convergence.

I have not yet modeled Warriors, so I cannot speak for that class in particular........ but so far I have yet to run into a class/spec that could not be analyzed via simulation in a "reasonable" amount of time.

Dude, you're pretty much right on the exact same page as me. Flurry and similar proc-based haste mechanics make event-based a bad idea, imo. Have to be able to handle those mid-swing procs. Really, that is my entire motivation for taking on this project: To get a more accurate picture of warrior DPS. From the spreadsheet work I've done, I can see where there are some serious issues. People mentioned ones like mid-swing haste, flurry up-time, rage spikes/starvation, etc... Another HUGE deal though is execute when dual-wielding with different speed weapons. There is simply NO good way to model this in a spreadsheet. I don't have a lot of confidence in the model I currently use for execute speed in the spreadsheet. It's a lot better than a lot of the other methods that have been used, but at the end of the day it's still a stop-gap.

I'm wanting to do this because I am interested in the results, and because it looks like a fun challenge for me. Language-wise, I am most likely going to use C++, since it's the only language I really know. All this new shit like Java and Python and C# wasn't invented yet when I learned how to program. I do think I'm gonna say fuck the GUI for now and use data file input.

Ohhh, another idea that popped into my head....maybe do support for two different configs and have them run side-by-side. Like, if you want to use different rage spending parameters or different specs or something.

Also, I don't know what my availability for working on this is going to be for the near future. There is very likely going to be a strike starting on Sunday. I am a contractor, so not only will I still be working, but I'll be working 12 hours per day, 6 days per week. Now, if it's really dead here that means MORE time to work on stuff, but with so many less people, I may end up getting swamped. No idea how long the strike will last either. We'll see. I mainly say this as a reminder to people to be patient. I intend to follow this project through. It's just gonna be a little slow getting off the ground.

Both systems are "event-based"...... The difference is merely how those events are stored.

A classic "timing-wheel" simulator uses a specific granularity..... which become the buckets on the wheel.

A simple ordered link list is another alternative.

In both cases, rescheduling a swing event represents the same amount of complexity and runtime.

A timing wheel system makes for faster event inserts into the "future"....... and the cost of potentially many empty slots in the wheel that you waste your time checking for "next event".

My recommendation to you is to abstract the event storage system from the rest of your mechanics so you can tweak it at a later date.

For instance, when I'm only simulating one player, the simple ordered event list is fastest..... When I pile 10+ players into the simulator, the timing wheel starts to look good.

I know it wouldnt be able to distinguish between using DW 2 or 3 times a fight, but would just running one long sim and stopping when the average dps change is less than a really small number give a good baseline? Something is nagging in my head saying no but I dont know what.


For the sim a feature I would like to see is record wasted rage, such as rage >100. I think that would be very important for things like Titan's Grip or sword spec.

Also how does WoW handle rounding? It seems like it keeps the remainder for the next hit but Ive never seen it tested.

Event lists can be of arbitrary time precision. For a system with small number of events it may be faster to check all events in the list everytime. But if the system needs to scale larger you will need to make it a time ordered event list.

Maybe I am missing something important in this whole "modeling Flurry is hard" discussion. I have no doubts that it is not hard, but there already is a working Simulator that works with Flurry: The Enhancement Shaman DPS simulator. Wouldn't it be possible for you to contact Yo! (he also posts here) and ask for the Flurry calculations part of his sim to include it in yours? I don't know, maybe I am seeing this too simple and this isn't even possible (or maybe you want to do everything yourself), but hey, no harm in suggesting it, right? :P

It's not flurry that's hard to model, it's the rage generation and what miss streaks will do to your dps that is tricky. Flurry uptime will be 98-99% anyway with TG, you might as well not model it at all.

Actually, you got me to look at it from a different angle wording it like this, and I don't know how i missed it in the first place. It'd be pretty easy; something like

onFlurry()
t = swingEnd - currentTime
t = t * (1 - flurryHaste)
swingEnd = currentTime + t
swingSpeed = swingSpeed * (1 - flurryHaste)
flurryEnd = currentTime + swingSpeed * 3
return(swingEnd, flurryEnd)

...or something like that anyways.


The thing that i was stuck on before, and this made me solve was for some reason I was thinking that there wasn't a time reference for a mid-swing flurry, since it would be triggered by an instant crit rather than a swing crit. But, of course, there would be a time stamp on instant hits as well as swings, so it works. I just forgot that the triggering instant will itself provide the necessary time reference to calculate the new swing end time. Doing it this way, i think, will provide the resources to operate with a significantly greater amount of precision. Though, I would REALLY like to know how many significant digits WoW uses internally. Too much precision is better than not enough though, as being over-precise is much more likely to average out to where it should be than is the case with not enough precision.

**EDIT**

As to flurry up-time, my current spreadsheet is telling me about 80% for dual-wield and 99% for a 2-hand slam warrior. That's with 33.17% crit, 2.8 mace MH, 2.6 axe OH vs. 34.71% crit, 3.6 sword 2H. I imagine this is why the sheet says crit is more valuable for a DW warrior than it is for a 2H warrior. The DW gains a lot more flurry up time from crit. Looking at this actually helped me come up with an improvement to the flurry model just now. My current spreadsheet flurry model is:

1-(1-critChance)^(3/(MHhitsPerSec+OHhitsPerSec))

1 - (chance to NOT proc) ^ (time it takes for 3 swings)

1 - (flurry down time)

(flurry up time)


Oh, to Liar, re: modeling flurry haste... The main difference between warrior and shaman models is that a shaman doesn't have to consider instants to the same degree a warrior does. They have what? Like one instant? And it's a 31 point talent. You could probably get away with not even considering mid-swing flurry in a shaman sim and not even feel guilty about it. For a 2-hand warrior, 7 out of every 11 attacks in your rotation are instants. As such, we need to be really anal about shit like mid-swing flurry.

All those instants make for freakin' awesome proc up time though. On average, a 2-hand warrior probably has around 66% better up time than a shaman and about 33% better up time than a dual-wield warrior. Don't know much about rogues, i think they'd probably have a little better up time than a dual-wielding warrior, but not as much as a 2-hand warrior.