When it came to updates, he had said previously it was best for one of the devs to send a Pull Request on GitHub because he was on that constantly. To get those latest fixes to the backend implemented required me to contact him directly since I don't have ability with GitHub, but once I did he was very quick about updating it after he got my request.

It might be worth spending some time thinking about how to make modeling more accessible. I get the sense that the perceived complexity is what puts a lot of people off. It would be interesting to know what you guys spent the bulk of your time on in terms of modeling after you got done with the initial implementation. I'm guessing that it was mostly tweaks and bugfixes or implementing new skills or procs.

I can imagine an interface that helps a user gather the data needed to model a skill for example. Maybe you start by picking a comparable skill that's already been modeled, then the interface could provide instructions for producing and uploading a log that demonstrates the skill so the coefficients could be converged upon, etc. It would be tons of work for skilled programmers but possibly less work than those same programmers doing all of the modeling.

As for specific implementation details: what about js or coffeescript (pythonesque js - gets turned in to js and run on the browser or node just like it)? That would give you the expressiveness of an high level language with the accessibility and offline characteristics of a spreadsheet.

I can't speak for all people who contributed to ShadowCraft, but from an engine perspective, my sense is that the leading sources of ongoing work were a) set bonuses, b) procs whose mechanics were sufficiently unusual that the basic proc modeling built in from the outset did not apply, and c) improving modelings in places where we'd half-assed it in the first place in the interest of getting things out for launch.

That said: I don't think the model is any more complicated than it needs to be. The fact that its big and complicated and somewhat nasty to modify is precisely because a good model of what's going on is actually pretty complicated. Its just not going to be possible to write a general model that you can just plug new abilities into with a reasonable expectation of accuracy, because every ability is used differently and has slightly different mechanics, and they interact in subtle ways. It will get somewhat easier in Mists - the simpler talent system means you need fewer options to support various talents, and Anticipation simplifies a lot of cycle calculation logic... but sooner or later it will be useful to have non-Anticipation cycles, and there will still be complicated procs and set bonuses, so it will remain a somewhat complicated problem to solve. And I just don't see any way around that.

Most of the complexity is more around cycles and how skills interact with each other within the scope of the cycle, rather than just implementing the basic effects of a skill. Exposing base coefficients for skills seems simple enough (and is often all that needed changing for a patch), but having the ability to allow for the addition of a new skill is, except in the simplest of cases, beyond a reasonable complexity to attempt to implement.

While I think allowing the modelling of a fight to be split into sections to be modelled separately is probably a positive step forward, thought needs to be placed on how to cope with edge cases; skills with long cooldowns which don't apply to each step of the fight, or conversely, coping with skills/effects which need to traverse fight sections (which strikes me a significantly difficult problem to solve). Easier implemented via a step by step simulation. It also requires significantly more input from the user, but I think that is an acceptable situation.

I found the UI side of Shadowcraft a significantly positive step forward. I didn't find it particularly difficult to see what my nearest upgrades where (and I definitely fit into the lower end raider that isn't going to see the BIS stuff as Aldriana mentions). I don't see a large benefit as a user in being able to make significant cycle changes, but I do miss seeing the intermediate calculation steps and being able to play with the base coefficients (in the basic sense).

I think there's two main challenges in doing more encounter-based modeling.

First, there's the simple challenge of defining a syntax to describe the various patterns a fight can take. Some mechanics - particularly procs - are very sensitive to the exact pattern of uptime and downtime, so you can't just take the naive approach of looking at % time on target. There are differences between a fight segment that lasts for a particular amount of time, and one that lasts for a particular amount of health. There are differences between a target that dies or goes immune causing you to switch off it, and one where DoTs can keep ticking as you switch to a higher priority target. And so on. Coming up with a model that can handle all these different special cases turns out to be pretty hard.

Second, the hard part of DPS modeling is usually figuring out how many moves of each type you perform in a given period of time - your cycle, basically. And usual approaches for figuring this out rely on the fact that you're generally doing the same sequence of moves many times in a row, so you can pull time-averaging tricks to simplify some calculations. But as the fight segments get shorter, the edge effects get larger, and it gets harder and harder to break the circular dependencies and account for the large variance of cycle elements.

Hence, while a general approach to fight segments would certainly be useful, I don't know how feasible it will be. At the very least, it seems ambitious to attempt initially. If it were me, I might start not with fight length and interruption patterns, but with modeling for AoE situations - knowing how Blade Flurry, FoK, and Crimson Tempest influence your stat priorities on various numbers of targets seems valuable.

To get modeling of different fight lengths and interruption patterns, I might try a simplified model based on breaking fights into segments - i.e., rather than modeling a "6 minute fight", you model it as a 20 second rampup, and 330 seconds of "sustained DPS", and a 10 second "conclusion". This would significantly increase your ability to model shorter fights, although there's still a question of how you deal with temporary buffs and cooldowns and the like.

Or perhaps someone out there has a clever idea for getting around these problems, and in that case I look forward to seeing it; all I know is that I haven't yet been able to come up with a satisfactory way of modeling all the different complicated fight patterns in detail.

Ever since I discovered them, I used the spreadsheets and, more recently, Shadowcraft. I'm the sort of person that can understand and explain to someone why something works better than something else once someone else has proved the maths, but the maths goes way over my head to the point I wouldn't have a clue where to start with working things out from scratch. Therefore I have found these tools invaluable to me and heavily rely on them. The work undertaken by all the people that have worked on them over the years is incredible and thank you for it.

Spreadsheets - It was quite fun to be able to poke around with stat weightings and cycles but gear recommendations were difficult to gauge without selecting and recalculating after writing previous results down. I did like that, if an item had an error, or was not in the database for whatever reason, you could quite easily add it manually.

Shadowcraft - I do like the interface - I'm a visual person and it helps me see at a glance what I have and whether it looks right to me. I also like the fact that the items list is much much longer than the spreadsheet's ones ever were - I have runs of dire luck where upgrade items just will not drop and it's nice to be able to still get a reasonable model with the odd older item still in various sockets. Visually again I do like the numbered bar-graph of how much of an improvement an item is - is it worth spending tokens/dkp etc... to get an item for slot A now, or would it be better to save up for an item in slot B because the difference is that much greater.

As many people have already said there are elements of each system that were great and others that didn't work as fluidly. I like the visual aspects of Shadowcraft and the "tweakability" of the spreadsheets. I like the fact that Shadowcraft is online as I can access it from pretty much anywhere without worrying about whether it has the latest data on what my character has, or whether the code is the most recent. I liked how you could choose where your upgrades were coming from in the spreadsheets (deselecting heroic modes if your guild wasn't there yet).

It would probably be way too much of a nightmare to implement but an interesting future feature would be if you could tick-box what classes are actually attending a particular raid and make suggestions as to spec or rotation alterations that might help out. There are certainly fights we've done with such a bad group comp (but without the option to change due to availability of raiders/characters) where we've got through on almost luck alone and I've wondered whether I could do something to improve our chances without knowing quite what. I guess a lot of that is down to experience though.

I think anyone that takes up the gauntlet of developing the next generation of rogue tools has a pretty solid position to work from from the point of what people want or expect to see. I think the only difficulty is the "frills" added outside of the necessary parts and the tools used to create such a tool.

One huge difficulty I see with simulating short fights, in relation to what Aldriana mentionned, is the RNG factor. On a 6-minute fight, most RNG tends to cancel itself out. On a 20-second burst phase, your DPS can be, all other things equal, radically different depending on things such as trinket procs: whether strong trinkets are on or off ICD is going to have a huge effect, especially if it's a 15-20s proc (the case with most trinkets).

And that's not even taking into account the problem of CD management. Bosses with repetitive phases can very much change depending on your comp. Typically, any fight with HP%-based burst phases, as opposed to timer-based burst phases, will mean that you will reach a certain point where your CDs are mostly up on burst phases, and then you'll be back to a point where they aren't. I remember this being considered problematic even on patchwerk-style bosses - Deathbringer Saurfang to be precise - where the spreadsheet gave mut rogues above combat rogues, but where combat rogues got out above because the duration of the fight gave them just enough time to slip in an extra AR.


All in all, I'm not that sure that actual, precise burst-phase simulating is possible. Simulating fights based on, as Aldriana put it, a simple Ramp-up | Cruise speed | Execution phase model, might be more interesting, especially in allowing you to time your fights, and make spec decisions based on knowing if you'll be able to use more of a certain CD to greater effect.


Finally, on an unrelated note: modeling AE would be awesome. For fights such as Yor'sahj, Blackhorn, Ragnaros or even Halfus, being able to know how AE is going to come into play would be fascinating indeed.

Well, if there was a scheduling application coupled with it. You could pick a boss fight and add in certain blocks that you could change position and length of. Such as "Out of Melee (In throw range): 10 sec" "New target" "Boss specific mechanic (2 stacks)" etc.

Then if you manage to code the base to take these blocks into account, it would seem it would be quite easy to simply add new blocks with different code in them.

This might prove to be very helpful, but having a background in programming; getting the foundation to work would be quite a pain.

I am afraid that those time-blocks might be simply too short to provide any accurate results with current modelling that is based on averaging everything (average buff uptimes, average combo points per second, average finishers per time and so on).

I found using the Shadowcraft tool more fun to use then the excel spreadsheets of the past. So I would say keep with that approach.

As for the code part I would love to help. Even though I am a .Net MVC guy, I am capable in Java but have very little experience with Python and none in Ruby. Either way I am sure I could be of assistance. Just let me know what you need of me.

I previously only used the Shadowcraft spreadsheet, however I was using AskMrRobot for all of my other toons so i switched to using that on my rogue.

I feel that that site has a little less customization, but gives a gear upgrade path. The only difference I found is the difference in reforges, they don't match at all but I think it's because the EP values are different. Would it be worth talking to the devs of the site rather than trying to completely re-invent the wheel? Seems like it would be simpler...