WoW Simulator - What do you want?
 

There seem to be several tools already in use for world of warcraft theorizing and analysis, but they have been developed independently of eachother. By integrating the technology of all of these tools into one portable program, and exposing the API, existing analysis could be conducted much faster, and whole-raid theorycrafting would no longer be prohibitively time consuming.

I have a substantial amount of experience developing complex mechanical engineering simulation software, and simulating WoW combat is not very different. I hope to provide a much easier to use theorycrafting tool than the various spreadsheets on these forums, and allow whole-raid analysis (think: equivalent of having a spreadsheet for every member of your 25 man raid, and playing with different factors to optimize -- but it takes 5-10 minutes to set up instead of hours).

I have chosen to develop this application using the Netbeans 6.5 Platform on Java, because it lends its self well to a modular architecture. For example:

CORE MODULE:
User Interface, Parties, Raids, Classes, Stats, Talents, Player Spells

SIMULATION MODULE: (requires CORE)
WoW Combat, Enemies (via very short user-created java files), Combat rotations

ARMORY INTERFACE MODULE: (requires CORE)
Provides functionality similar to Rawr. Optimization is left to the next module

OPTIMIZATION AND ANALYSIS MODULE: (requires SIMULATION, CORE, ARMORY INTERFACE)
Combat log parser, Raid makeup optimizer, Talent optimizer (find the optimal dps build for a particular boss fight), Performance analyzer (compare a player to their simulated performance).

Using Java allows easy HTML or XML output for posting reports on your respective guild websites. I do not plan on involving hosting like WWS, although I am looking into the possibility of pulling data off the WWS site. Furthermore, using Netbeans allows people to easily add modules to the software (i.e., performance-based DKP or something like that).

What I would like to know from the EJ community is:

What would you absolutely need in order for this tool to be something you'd use? What types of features would make you use it more frequently? What do you see in existing WoW analysis tools (Spreadsheets, Rawr, Combat log parsers, theorycrafting add ons) that drives you crazy?

More feedback on this concept means the result will be far more useful.

I expect to make available an alpha release (haven't decided if it will be public or not) of at least the core module at around new years, at which time I'll provide a link to the source code and a place to report bugs/enhancement requests. In the mean time, please think of this as a "need/wish list", and a discussion about possible use cases and features.

There is already a full raid simulator in progress: http://elitistjerks.com/f31/t33457-s...l_development/

Perhaps you could contribute to that project rather than re-inventing the wheel? I don't know if maybe that project is smaller scope than your intent, or whatever. Just trying to possibly save you a lot of work if your only goal is one unified raid simulator.

It's in C++.

This project is beyond the scope of simcraft, and I really dislike using C++ for this type of project for various reasons. Finally, there's no UI for simcraft, which makes it far less easy to use and accessable. I'm not sure what the developer's vision for the project is, but it seems like 8% of the wheel has been developed, and I'm choosing to start over instead of continue the existing wheel.

The most appealing thing about using java is the user's ability to write small chunks of code to define things specific to what they're trying to do. This has the potential to allow simulation-generated data to much more closely resemble combat logs from the fight being simulated, because you'd be able to code up ("at 66% and 33%, the boss fears all players in melee range, and unless they can trinket or use some fear-breaking ability, they take 10 seconds to resume combat")

Adding this type of thing to simulationcraft would require writing a whole lot more code, and recompiling every time you change something.

This is what I would want/use, not considering the complexity or viability of such thing:

Imagine something like Raidcomp where after selecting the players, you could click on one of them and then a Rawr-like window would pop open and you could edit the gear of each character. Maybe even import the whole guild from the Armory and let you select which members would attend that given raid and import all the gear/stats/talents for them.

In addition to that, the program would be able to model all current boss fights and calculate the DPS, Received Damage, Tank TPS, Healing done, etc of each of those players, using the optimal known rotation and maybe even let you play with the rotations to figure out the outcome.

It could also use average presence time and dps time from existing WWS reports (or calculate that on its own from a combat log, to be less dependant on another web-app) to figure out how much movement you would need during that boss fight.

To create the ultimate theorycrafting/simulation tool, one could probably think of many other features, but that's what I thought of for now. I'm not even sure that's doable, but since you asked, there you go!

Yep, this is certainly a given, and will most likely be availble in the early versions of the armory module

It would take a very long time to code up all the boss fights. It would be pretty much like rewriting WoW. What I have decided to do is allow users to code up a boss fight themselves in java. You would define boss behavior as events that happen at certain times, boss health levels, boss mana levels, cooldowns + random wait time, etc...

If I can pull data off WWS, averaging that would provide a good baseline. I'm trying to use individual combat log data as a point of comparison only, because I don't want any mistakes to be interpreted by the program as boss mechanics. For example, if you import a combat log from a murmur fight, where your melee takes way too long to get back in range after a sonic boom, basing boss behavior off the combat log would distort the mechanics of the fight.

I know this is a pretty extravagant request but I think it would be pretty awesome if you could set up who is in your raid. Then your doing whatever instance and X item drops. You can go to the program and put in what item dropped and have it tell you who in the raid would get the most dps/healing throughput. I know that is probably a pretty time consuming feature to implement but you did ask. It would make the loot council in our guild go a hell of a lot faster I'd imagine.

This is a good example of something that will be very easy to implement once we have a gear optimizer like Rawr combined with a combat log parser and a combat simulator. Since these tools are all independent it would take a whole lot of time to figure out how much of an upgrade it is for each player, given their talents, combat rotation, etc... Making this easier is one of the clear motivators for this project.

I would say start out simple with just Testdummy dps or Patchwork dps. Facturing in all bossfights would be a possible future feature.

But the idea of the lootcouncil thing would be great.
Something i would like to see, dont know if its possible because i havent seen it in any simulation, rotation advisor.
That it would analyse which abilities do most damage and gives the highest priority to those abilities, factoring gear configuration.

It absolutely must have find-as-you-type dropdown boxes for gear lists, or something equally easy when trying out different pieces of gear on a character.

There's nothing more annoying than trying to find that one specific piece of loot in a list that scrolls to three times the vertical size of your monitor.

Ideally I would like to see a rule-engine based simulation tool. Check: Jess, the Rule Engine for the Java Platform

Something like JRule or Drools (if you go the java way), here's a list of open-source rule-engines:
Open Source Rule Engines in Java

The problem with many simulation softwares produced by the community is the mechanics and calculations are coded inside the program and corrections or alterations require a new build. Spreadsheets naturally don't fall into this category.

I think the best results from the community of theorycrafters could be gained if meta-data which changes the results could be easily edited and altered via some api, be it in xml or other suitable format. This would also lead to experimenting and finding the best solution for each mechanic/calculation.

Thanks for directing me to Jess, I may end up using it or another similar library to allow the user to specify some custom optimization function.

All numbers having to do with mechanics are stored in an XML file. Any changes the user makes are stored in a preferences file on their machine, as I want to retain the ability to revert to known, valid values.

This sounds like an exciting project! I wish you the best of luck!

Regarding "all numbers having to do with mechanics"..... While tweaking coefficients is handy/helpful.... I've found that the stuff that changes is most is the actual "mechanics" (ie: the formulas and code segments) into which these numbers are fed. Being able to completely replace the implementation of a spell would be quite powerful.....

You will already have a natural string-to-action-class method...... It is not hard to imagine allowing users to override that relationship to replace the functionality of specific class abilities.

I've found Java to be an excellent "teaching" language.... and it has a wealth of standard and contributed UI-related features........ but performance may become an issue if you want to generate reliable scaling info.

Good luck.... and have fun!

PS: SimulationCraft has absolutely zero plans for a nice UI. I'm simply not interested (and not qualified!) My focus remains first on class support..... then unique item procs..... then boss events. I see it primarily as a tool to corroborate other forms of theorycraft.

Although it's certainly possible, and not that hard to do this with Java, I'm probably going to opt to release new versions of the software as major mechanics change. Another option would be providing a base model for each class (containing a model for each spell), and allowing custom code to override these, but it's a trade off between customizability and usability that I need to consider. Someone would have to provide me with a convincing use case to get a definite "yes".

Certainly things will run somewhat slower compared to a C++ implementation, but the drawbacks of using C++ for a project like this (nice UI, grabbing data from armory, etc..) make my head hurt. In fact, doing what you described above (allowing custom code to be executed at runtime) would be a project in its self! WoW combat is just a bunch of arithmetic happening on various timers, so I expect things to run at least several hundred times faster than actual WoW combat, even on slower machines. If things are too slow, I could always write the actual simulator in C++ (or use SimulationCraft) and have some sort of client-server architecture.

What's more, the fact that Java is quite a bit more forgiving bug-wise will allow people to contribute who have minimal experience. Ideally, someone who is an expert on Mages would not have to be an expert programmer as well in order to use the program, or even to implement a raid encounter.

Things are moving pretty quickly! I've got parties, raids and stats, complete with UI and the ability to execute java code at runtime using these objects! Next up: spells! I should be posting a screenshot of the UI sometime next week.

Sounds like a huge undertaking - developing and especially maintaining the mechanics for every class and every spec on top of the other features seems like it would be a full time job. Are you sure you have the time to dedicate to this, or will you be looking for other developers to help? Like how Rawr has a developer for each class.

And, not to dissuade you or anything, but I have to question the necessity for a program like this. It doesn't feel like raiding is as min/max dependant as it has been in the past. I'd hate to see so much work done for a program intended to squeeze out that last bit of potential for each raider, when the requirements for raiding successfully are so low that following the instructions: "Show Up, Stay Out of the Fire, Click Frostbolt" are all that's really needed anyway.

But, of course, if this is something you want to put your time in to, I'm sure you'll get nothing but gratitude from the community. Features I'd like to see were already mentioned: an upgrade planner that would show who will receive the most potential dps/healing/not-dieing from each piece on each boss planned that night, so loot councils can be a lot more prepared.

There no necessity for any of these tools, but they are useful and appreciated by the wow community. I'm going to design the software with easy maintenance in mind, and whenever possible pull data from places that are already routinely updated. As for min/maxing not being required for wotlk raiding, it wasn't really required in the first 6 months after WoW classic or TBC was released, but when it came to the instances near the 1.5 year mark (Naxx-40, Sunwell), things changed.

Also understand that I have an industry-leading simulation platform to build this thing on, and a whole lot of the more tedious things have either already been done in the code I write at work, are available in Java SE, or are available in a Netbeans module.

No worries here, I'm developing it on my iMac. I have been using Rawr through VM Fusion as well and it really screws things up if I have the game running at the same time.