Grim13

I am giving serious consideration to writing a DPS simulator for Warriors and would like to gague interest as well as solicit input from the potential users.

What it would do: Input your unbuffed stats, talents, buffs, encounter info then output DPS-relavent statistics of varying verbosity, to include: avg DPS, min/max DPS for interval x, min/max hits/crits, rage generation (rps, min/max rps for interval x), min/max/avg stats (AP, ArPn, Haste, etc), proc stats

What it would not do: Paper doll - Easy enough for me to add another sheet to the current spreadsheet to handle data export, maybe even write an automated export method if I feel industrious. Coding a paper doll method would involve a lot of stuff that I am not sure if I know how to do. Maybe it'll come eventually, but the priority is the sim, which mostly involves stuff I am pretty good at.

Interface: Right now, I am looking at doing a simple windows-based GUI with a style similar to the spreadsheet for buff and talent input (lots of checkboxes and listboxes) and something similar to dr_AllCOM's 2.0 sheet (the foundation for Warrior_Sim.xls in my sheet).

That's what's on the top of my head. I'll be coming up with more ideas as I ahift focus to this project, and hopefully the community will have some input too.

 

SeanDamnit

You may want to wait until WotLK is complete before spending time on this.

Card carrying member of the Inapropriately in Love with Hilary Duff Society.

"Yeah, well, if we could all get what we want I would be eating dinner out of Hilary Duff's skull right now" - Salabesh

 

• frmorrison

Rawr 15 already has a module for Arms Warriors, so I don't what you are trying to show that Rawr does not.

 

Deathwing

I believe Rawr is still just a pretty spreadsheet(and nothing against Rawr). A simulator goes far beyond that, especially when calculating such headaches as flurry uptime.

 

Mardraum

I think it's a great idea. Build it now for current wotlk abilities/talents/builds and update it as they change stuff. I really liked your old spreadsheet grim i'm sure you'll do a fine job on a sim. I wouldn't waste any time or effort making a lvl 70 one however.

 

Shha

Some Rawr modules are simulators, but not the warrior one.

 

Gruntle

As mentioned above Rawr will not do a fullscale simulation but rather emulate the spreadsheets. In my opinion this is kind of pointless, a full scale simulator is way more interesting. Secondly, Rawr b15 is not even released yet, so why are you bashing on someone for doing a new thing?

Anyway, I think it would be highly interesting Grim13. I've started writing a simulator myself, but there is never enough time to work on it so I'd rather use whatever you can make. I think it will be really hard to figure out optimum cycles for dps warriors in wotlk, having a swing simulator where you can set rage priorities (e.g. give priority to the ability with highest damage/rage in ragestarved conditions) will be a great tool.

 

Grim13

Ohhh, now there's some interesting stuff Gruntle.... Thinking along the lines of being able to set thresholds to tweak the decision process. As in, making the cycles somewhat dynamic, based upon user specifications. This is really getting my wheels churning, thinking of stuff like setting rage thresholds for pretty much everything....HS, execute, MS/BT, etc... Plus, it would REALLY help clear up some things with Slam cycles that spreadsheets have a really hard time with, especially the bursty nature of 2h rage generation. Ohhh, I'm also thinking about learning this XML stuff so that it can interface with the armory to pull your current gear. Really, doing that is a step towards paper doll functionality, which I have not ruled out, just not likely to be in the first version.

I hope to get the updated sheet out this week and then start work on this. Just tough to make time for this, the sheet, the web site and actually playing the game. Not to forget work too, heh. I should be able to do this though. I can kinda visualize the functions in my mind for a lot of the stuff needed for this project. Just need to learn how to do a GUI and I'l be off to the races.

As to the concern over doing it for lvl 70 vs lvl 80, 95% of the stuff will remain unchanged. The hard part is the mechanics. Once I have a modular framework coded for the warriors base mechanics, adding new and different stuff should be easy. That is one thing about this project: since it will be 100% my work from the start, I'll be able to use the type of modular framework that I prefer. Not to condescend towards the original authors: it was great work, it's just different methods of overall design. Not that any of this matters to anyone so long as it works, right? Actually though, if I follow through with the principles I intend to focus on, it should make it MUCH easier to add new gizmos.



Ok, enough with all that, I'm thinking about the "time scaling" of the thing, and how to do it. Right now, I am leaning towards writing everything at real-time, but with a multiplier variable built in that is user definable. Like, so they can run the thing slow(or just less fast) if they want, and watch the action unfold. Like, maybe so they can personally watch things over for rage starving or whatever they may want to look for.

Which makes me think of another idea: Rage bar and target HP bar, updated in time with the sim, of course. Would make the watching over of some things a little easier.

All this talk about time, I also need to decide on a resolution for the simulator. 0.01s? 0.001s? One of those two most likely, I'd imagine. I'll probably make that adjustable as well, if it can be done without too much hassle. No idea how much of a resource hog the thing might be. I think, instead of the user being able to enter whatever they want, I'll just have 3 choices: Low, Medium, High. Like, 0.01s, 0.001s, 0.0001s, or whatever I end up using. The ability for the user to reduce the timing resolution by an order of magnitude could be handy, as it's a pretty significant difference to the CPU.

You may think this sort of stuff sounds minor, but this is the kind of stuff that makes for a MUCH better program if it is foreseen and implemented from the beginning. We need to come up with EVERY feature and option you guys can think of. I need to design the base framework properly to handle it all. I would really like to do this right, because there are some things I suspect will come out a bit different than they do in the sheets.

 

• Aldriana

It's not immediately clear to me that you need to set a specific, fixed resolution like that; it seems to me that it might work better to seek from event to event. That is to say: almost all events that are of interest in this sort of thing are either triggered by a cooldown being up, or an attack being launched. For instance: a proc cannot occur without a weapon attack. Rage cannot be regenerated without launching an attack (usually). Abilities with cooldowns can't be used until the cooldown is up. And so on. Hence, rather than checking the status of the character every .001 seconds (or whatever), it's probably more efficient just to build up a sorted list of events. For instance, if at T=0 you land an autoattack with a 3.0 speed weapon, you add to your list an entry for "next autoattack" at T=3.0. If you then land a Mortal Strike at 0.5 seconds, you add an entry to the list for "MS cooldown up" at T=6.5. If the MS procs DST, you add an entry for "DST buff fades" at 10.5 seconds. At any given time, there's thus a reasonable short list with perhaps a dozen elements in it specify when the next interesting thing can happen. Your program can this just step through this list - at each instant in time, grab the "interesting event" that's going to happen next, update the list based on that event, and repeat. If no interesting event is possible for the next 1.5 seconds, there's no real reason to make 1500 checks while you're waiting - you can just seek that 1.5 second forward and get on with the show. Seems to me that this would result in a less computationally intensive simulation than just checking the status of everything every .001 seconds.

 

Excession

I've thought about writing a warrior simulator before myself, just haven't had enough motivation. Good to see that someone else has that motivation.

Personally I wouldn't bother with a GUI initially. I'd make it run from a config file and/or API, at least at first, rather than spend time on a component that isn't core to the problem. With the simulation itself up and running you could make it a rawr module and use their interface, write a GUI later, or someone else could write a GUI for you.

Sounds like you're on the right track with keeping the mechanics separate from the simulation engine; that's going to be important. Do the separation well and you could use the same engine for any class, maybe even simulate an entire raid to model synergies.

Do you need to have a fixed time resolution? The simulator I started writing a while back was purely event driven. Everything that happens (melee swing, buff fading, ability cooldowns, periodic damage) is coded as a separate event class with a "process" method that models everything that happens instantaneously at the time of the event, and generates more events for things that happen in the future. Events are added to an "event queue" along with the time until they will occur. The event queue "next" method removes and returns the next event and the new current time. For example, a "mainhand melee swing" event would:

• Use random numbers to simulate a swing, whether it misses/hits/crits etc.
• Generator a virtual combat log entry for the swing.
• Add the swing damage to the damage total.
• If the swing crit, add the flurry buff and create an event to fade flurry after it's timeout.
• Add an event for the next mainhand swing, queued to happen after the correct delay.

I had the event queue thing working, but I lost motivation when trying to work out how to model stats and buffs. What language were you planning on writing it in? I'm most familiar with Python, but I could probably contribute some code in a few different languages. I would recommend something high level though; ease of programming new mechanics and decision code is always going to beat having your code run a bit faster.

Feel free to PM me if there's anything I can do to help.

Edit: sorry Aldriana, I missed that you said the same thing I did. I think my eyes slid off the wall of text.

 

Gruntle

Yeah, an event driven code will most probably be a lot faster than having a fixed resolution. The stuff I started to do was in Python and with a fixed resolution. I'm not really an expert on optimization but only the white hits and rage generation seemed to be very slow with a 0.001 resolution. Too many loops are spent doing exactly nothing. I started to remake it into using events, but then my vacation was abruptly interrupted by having to go back to work .

I'd be willing to help out as well if you need, not sure how much time I'll have but feel free to ask.

 

jimbo229

In regards to adding an HP/Rage bar, I can understand having the rage bar, but how are you going to simulate the HP bar? Without doing encounter specific programming i mean. I think that is going much past being a simple simulator and into being encounter by encounter raid simulator. It seems to me that if you wanted to the the HP bar you would have to know: current encounter, how many healers present, what type of healers, the healers +healing/crit rate. Just seems much more complex than a simple tank and spank sort of simulator

 

Aeverius

He did say "target" HP bar. As in, "Is it Execute time now?" Not that there wouldn't be some tricks involved in modeling that too, of course.

Improved Lay on Hands is really fucking good:

 

Whistles

Depending on the language it's written in and whether you want to throw it up on Sourceforge or Codeplex or somewhere I'd be interested in contributing to this. I've written XML parsers in a couple languages and would be more than willing to do GUI/Armory work since it seems you aren't too excited about that aspect.

Depending on how much of a pain to run I'd love to be using a sim instead of the current spreadsheets. You can streamline a lot in an application that is a bit of a pain now, not to mention the possibility for a much more realistic model.

You absolutely want to go event driven instead of fixed time intervals. Your average time between events is probably going to be somewhere around a second but you'd need a much smaller interval (and thus a ton of wasted cycles) in order to model anything properly.

 

jimbo229

So he did. Im an idiot, that makes perfect sense now

 

Nite_Moogle

I have one that's very far along in development but I've more or less halted work on it pending a more finalized set of talents in WLK and some real life insanity. I will be happy to release it and its source code after the next major push if I get some time to work on it.

 

• landsoul

I think this is a great idea, if done correctly. If not apporached with the right frame of mind this cuold turn into a huge nightmare, Grim. The strengths of this idea is so huge and I wish it could be easy but I fear that there are an overwhelming amount of variables to be able to build enough loops for. Is this a brute-force project or a finesse project? A combination of both?

Potential Roadblocks
An event-driven system I fear could propogate into inaccuracy inflation. For example, if the calculated swing time was 2.93 seconds but in reality was 2.9348732 via calculation, that .0048732 could add up over time to be 3 seconds over a long fight. Multiply that by 10 different mechanics, and the automatic decision making engine will start making incorrect decisions even if one mechanic is slightly off.

Computer processors are pretty fast these days. Even with a 1ms (.001s) resolution we just don't know how fast it will run. It might just be that what you think would be slow having too many instances going through too many loops, might be too fast for you to even be able to follow in a display.


Haste mechanics I fear will completely run you around. What happens when you crit on your off-hand whirlwind, proccing DST and a new flurry when your main hand is in mid-swing? You would have to take the remainder of your main hand swing's time and add the haste application to only that section.

The problem of procs is that they are not static. How could you update dynamic changes to the warrior's stat table to your calculation loops while the loops are running?

Suggestions
Give it a shot, but make the code available for the community to see, test, and comment on. This project is going to be a big deal, with lots of little small parts forming into bigger and bigger parts that will finally come together. You could probably start working on it now and have untalented mechanics working befre the final WOTLK changes are made. Build the input, and an auto attack loop and let's see how it looks!

Make it resolution based, because at least that way you can make a variable that defines time left on swing that can be modified on the fly. Procced haste while midswing? then you do "Set Swing_Left =Swing_Left/(1+Haste_Proc_Percent).

Ask for a lot of help. You sound like you may not know a lot of neat programming tricks, which is what will be needed here. I don't know very much myself, but there are plenty of people I'm sure that do who would also have interest in helping.

What I would like to see:
For a display window, have 3 seperate columns streaming events with timestamps. Column 1 would have auto attacks and heroic strikes, Column 2 would have special attack damage, and Column 3 would have buffs gaining and fading.

 

dedmonwakeen

Heh.... Simulators abound! And why not!? They are certainly a fun project......

Feel free to check out my signature link to SimulationCraft. a multi-player event-driven simulator.
You are certainly welcome to poach anything you like.......
So far I've only implemented Druid (Balance Only), Priest, and Shaman.
I had planned on doing Hunter/Warrior next, but intense pressure from my friends over at shadowpriest has switched my priority to Mage/Warlock.

If you end up going with a cmd-line/parm-file interface first, it would be great if we could at least share the same control-file format.... If not, no biggie! Enjoy the fun!

http://code.google.com/p/simulationcraft

 

dedmonwakeen

Interesting. This is confirmed? I was under the (obviously false) impression that Parries were the only method of "speeding up" a swing already in motion.

http://code.google.com/p/simulationcraft

 

• Aldriana

One comment I might make about simulators is that while they're really good for some things, they tend to be not-so-good at others. So you should think a little bit about intended usage of the simulator. For instance, if the idea is "people plug in gear and see which combination does the most damage" - a simulator is fine. On the other hand, if you're interested in EP values, even a really good simulator doesn't tend to do as good a job as a more deterministic method (spreadsheets, etc.), for the simple reason that the variance in damage requires one to run the simulator for an extremely long time in order to get accurate values out.

For instance, lets assume for the moment that the standard deviation of damage for a real 6-minute fight is 50 DPS, and one wants EP that are accurate to within 1%. It can be shown that in order to get EP with that level of precision, one needs to run a couple hundred thousand hours of simulated combat per stat, which, even with a fairly well-designed simulator, takes a while to do. So I might think a little bit about what sort of information you're hoping to get out of this simulator before I spent too much time on it; for rogue modeling, I've decided that for the questions I want to investigate, even an imperfect calculator does a better job than a perfect simulator. Which is not to say that you shouldn't go ahead and do this - I'd just be clear on what you're trying to accomplish first.

 

Nite_Moogle

Flurry is the main thing that makes this extremely difficult to represent accurately because it is a positive feedback loop. You can estimate it but it's not going to be accurate. Unpredictable rage gain and accurate modeling of rage income and expenditure make eyeballing warrior damage quite a bit more complex than most other classes that have much more static resources to lean on for determining damage cycles. It isn't to say this can't be done, but it's nearly as complex as just writing a far more flexible simulator.

This is so impractical it isn't even funny. The simulator I've written thus far takes under 30 seconds to simulate 45 hours of combat.

 

dedmonwakeen

Not to rehash entire discussions we've had in other threads on this subject, but.....

I'd like to change your sentence slightly: We would want simulation-generated EPs with greater accuracy than those generated using closed-form approximations (aka formulation). A calculator can deliver a deterministic EP value with virtually arbitrary precision. But "precision" is not the same thing as "accuracy".

In my honest opinion: If a calculator can deliver EP values with an accuracy of 1%, there really is no need to use a simulator. It might be fun to write one..... but the usability of a calculator is far superior.

If the calculator cannot deliver a requisite level of accuracy, then the question becomes: "Can simulation deliver markedly better accuracy in a reasonable amount of time?"

It may not be possible to deliver EP values accurate to 1% with simulation...... but it may be possible to deliver values more accurate than those of formulation for some class/party/raid setups.

Grim: Please note that Aldriana still makes a very, very important point. Do whatever you can to reduce variation where possible because this will significantly reduce your runtime.

http://code.google.com/p/simulationcraft

 

• Aldriana

Agreed, there is an important distinction to be made between precision and accuracy. However, I think there's also something to be said for always getting the same answer - having the relative value of items slide relative to one another depending on luck in the simulation strikes me as a bad thing, so I would argue that it's better to have infinite precision values accurate to 5% than infinite accuracy values precise to 5%. Which basically means that if your calculator is even remotely close, it's going to do a better job on EP than most simulators.

That said: I confess I don't actually know how good the warrior spreadsheets are at the moment. I'm certainly willing to believe there are complications that make it challenging, but, at the risk of sounding cynical: it's been my impression that everyone thinks the modeling of their class is harder than everyone else's. Which is not to say that modeling warriors isn't hard - I'm sure it is. But a lot of other classes also have hard problems of similar sorts and have managed to concoct highly accurate models, so it would surprise me a bit if warriors couldn't do the same. Which, again, is not to say that you should or shouldn't do that, or this - I'm just saying, you should be clear on what information you want, and how well a simulator is going to do towards that end. If your ultimate goal is good EP values, it might make more sense to invest time in a really good calculator rather than a really good simulator. If you're more interested in just a good damage estimator, a good simulator is certainly a better investiture of time. So I simply recommend that you be clear about what you're going for.

 

dedmonwakeen

Grim, even if the simulator does not become the "go-to" tool, it would still be a very critical aid for confirming the accuracy of the formulation used by spreadsheets and calculators.

http://code.google.com/p/simulationcraft

 

• landsoul

This is like comparing apples to oranges to try and determine if the orange is right.

What if you wanted to personally check the results of your work for 1 minute of fight data or would you Save a log file of 45 hours of fighting? I guess you could do a log file instead of a display, but a 3 column system would make it easier on the human to verify his work.