Jump to content


Photo

DPS Simulator


  • This topic is locked This topic is locked
133 replies to this topic

#1 Grim13

Grim13

    Piston Honda

  • Members
  • 105 posts

Posted 29 July 2008 - 07:37 PM

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.

#2 SeanDamnit

SeanDamnit

    Piston Honda

  • Members
  • 173 posts

Posted 29 July 2008 - 07:45 PM

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

#3 frmorrison

frmorrison

    Protector

  • Allied Members
  • 11,427 posts

Posted 29 July 2008 - 07:49 PM

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

#4 Deathwing

Deathwing

    Bald Bull

  • Members
  • 1,126 posts

Posted 29 July 2008 - 07:54 PM

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.

#5 Mardraum

Mardraum

    Von Kaiser

  • Members
  • 45 posts

Posted 29 July 2008 - 08:17 PM

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.

#6 Shha

Shha

    King Hippo

  • Members
  • 646 posts

Posted 29 July 2008 - 08:32 PM

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

#7 Gruntle

Gruntle

    King Hippo

  • Members
  • 509 posts

Posted 29 July 2008 - 09:11 PM

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


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.

#8 Grim13

Grim13

    Piston Honda

  • Members
  • 105 posts

Posted 30 July 2008 - 12:46 AM

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.

#9 Aldriana

Aldriana

    Mike Tyson

  • Moderators
  • 13,510 posts

Posted 30 July 2008 - 12:59 AM

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.

#10 Excession

Excession

    Von Kaiser

  • Members
  • 36 posts

Posted 30 July 2008 - 03:17 AM

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. ;)

#11 Gruntle

Gruntle

    King Hippo

  • Members
  • 509 posts

Posted 30 July 2008 - 08:06 AM

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.

#12 jimbo229

jimbo229

    Glass Joe

  • Members
  • 16 posts

Posted 30 July 2008 - 02:30 PM

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

#13 Guest_Aeverius_*

Guest_Aeverius_*
  • Guests

Posted 30 July 2008 - 02:53 PM

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


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.

#14 Whistles

Whistles

    Piston Honda

  • Members
  • 124 posts

Posted 30 July 2008 - 03:10 PM

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.

#15 jimbo229

jimbo229

    Glass Joe

  • Members
  • 16 posts

Posted 30 July 2008 - 03:12 PM

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.


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

#16 Nite_Moogle

Nite_Moogle

    I prefer the term treasure hunting

  • Allied Members
  • 11,288 posts

Posted 30 July 2008 - 03:43 PM

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.

Eh, my nostalgia goggles aren't as good as they used to be.


#17 landsoul

landsoul

    Bald Bull

  • Members
  • 1,025 posts

Posted 30 July 2008 - 05:08 PM

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.

#18 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1,302 posts

Posted 30 July 2008 - 05:11 PM

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!

#19 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1,302 posts

Posted 30 July 2008 - 05:22 PM

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.


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.

#20 Aldriana

Aldriana

    Mike Tyson

  • Moderators
  • 13,510 posts

Posted 30 July 2008 - 05:33 PM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users