Jump to content


Photo

WoW Simulator - What do you want?


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

#1 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 10 December 2008 - 06:30 PM

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.

Attached Files



#2 ildon

ildon

    Collateral Damage

  • Members
  • 1459 posts

Posted 10 December 2008 - 06:43 PM

There is already a full raid simulator in progress: http://elitistjerks....el_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++.
<Kalroth> ( . Y . )
<buttbot> ( . BUTT . )
<Kalroth> <3

#3 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 10 December 2008 - 06:59 PM

There is already a full raid simulator in progress: http://elitistjerks....el_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.

#4 fredshino

fredshino

    Glass Joe

  • Members
  • 20 posts

Posted 10 December 2008 - 07:02 PM

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!

#5 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 10 December 2008 - 07:13 PM

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.

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

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

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.

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.

#6 Dollar

Dollar

    Piston Honda

  • Members
  • 239 posts

Posted 11 December 2008 - 03:27 AM

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.
"Oh he's a sad little man? He's thrown a kettle over a pub, what have you done?"

#7 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 11 December 2008 - 06:24 AM

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.

#8 Grimzilla

Grimzilla

    Glass Joe

  • Members
  • 18 posts

Posted 11 December 2008 - 08:30 AM

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.

#9 Noraj

Noraj

    Don Flamenco

  • Members
  • 406 posts

Posted 11 December 2008 - 08:43 AM

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.
"The question is not how far we are going to take it... the question is, do you possess the constitution to go as far as needed?" - Il Duce

#10 Redbeard

Redbeard

    Von Kaiser

  • Members
  • 52 posts

Posted 12 December 2008 - 07:01 AM

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.

#11 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 12 December 2008 - 02:37 PM

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.

#12 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1302 posts

Posted 12 December 2008 - 04:26 PM

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.

#13 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 12 December 2008 - 06:08 PM

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.

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".

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.

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.

#14 SeanDamnit

SeanDamnit

    Piston Honda

  • Members
  • 173 posts

Posted 12 December 2008 - 10:10 PM

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

#15 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 13 December 2008 - 10:22 PM

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.

My one request, is make it mac compatible. The one thing I hate more than anything is getting great tools and having to jump through hoops to use them efficiently.

Rawr is awful on mac, Many amazing spreadsheets use functions that don't work on mac (armory loader) and add in simulation craft thats all PC based. I am nerdy enough to beable to run windows/linux when ever I please, it's just an extra step or 2, then you add in things like graphics card errors because I'm running via VMware Fusion, and I have to reboot...well you get the point. Make it mac friendly. Thanks!


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.

#16 Bethink

Bethink

    Von Kaiser

  • Members
  • 54 posts

Posted 15 December 2008 - 12:16 PM

I like this proposal.

With the increased dynamics and interdependencies in WoW 3.0, simulation is increasingly becoming a "must have" for accurate results. I believe that numerous spreadsheets that have been providing good use to us in WoW 2.0 are quickly approaching their limit.

The main problem with existing simulation tools is that some of the most interesting questions cannot be easily asked in a declarative way. Instead, they are dependent on changing the strategy of individual units, which generally requires coding. Consider the following question for an Affliction lock: When Nightfall procs (making the next Shadow Bolt instant), is it better DPS-wise to cast the Shadow Bolt (and drop the rotation, possibly missing a Haunt renewal and dropping Corruption of the target)? Or is it better to maintain the rotation until Shadow Bolt is cast as a natural filler spell (possibly missing the Nightfall proc)? With a simulator, questions like these are easily answered.

Since I have a deep Java background (and only limited experience with C++), I went ahead last weekend and implemented a combat simulator for affliction warlocks. It is personal throw-away code, but already sufficient to answer quesetions like the one phrased above. I have no plans of productizing this simulator. However, once you get your framework going, I would be happy to contribute modelling code for affliction warlocks.


As mentioned above, I do not buy into declarative parameterization of the simulation. Is is a good starter, but only that. Interesting questions often require changing the actual code that controls the actions/spells of the the units involved. In my personal simulator, this aspect is implicitly adressed since I control the code myself. In a more productized approach, I would suggest looking into the use of scripting to control the units and their actions, thus allowing users to customize unit behavior in a flexible way. Lua would be a natural choice as a scripting language since many World of Warcraft players are familiar with it. Incidentally, I have been working on a project called JNLua which provides a type-safe integration of Lua for Java, including full reflexive access to Java objects from Lua. If you are going the down the scripting path, you may want to have a look at it.

Good luck with the project and keep us posted :dance:

#17 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 15 December 2008 - 02:58 PM

As mentioned above, I do not buy into declarative parameterization of the simulation. Is is a good starter, but only that. Interesting questions often require changing the actual code that controls the actions/spells of the the units involved. In my personal simulator, this aspect is implicitly adressed since I control the code myself. In a more productized approach, I would suggest looking into the use of scripting to control the units and their actions, thus allowing users to customize unit behavior in a flexible way. Lua would be a natural choice as a scripting language since many World of Warcraft players are familiar with it. Incidentally, I have been working on a project called JNLua which provides a type-safe integration of Lua for Java, including full reflexive access to Java objects from Lua. If you are going the down the scripting path, you may want to have a look at it.

Good luck with the project and keep us posted :dance:

I don't see any reason to use LUA for scripting. Right now I'm working towards allowing custom code to be written in Java. What I have completed is the necessary code for "journaling", meaning you click a "record actions" button, and the equivalent actions are written to a specified text file as Java code. Thus, you could record some process (setting up of a simulation or something), and then have a kind of macro that you can adjust and play back. The fact that this macro is in its self a java file means you can easily integrate with just about anything else.

I would prefer to keep everything consistent (i.e., not using multiple programming languages) to keep as easy a learning curve as possible for potential contributors and developers.

#18 Bethink

Bethink

    Von Kaiser

  • Members
  • 54 posts

Posted 15 December 2008 - 05:53 PM

I don't see any reason to use LUA for scripting. Right now I'm working towards allowing custom code to be written in Java.


I personally do not mind writing Java code. Potential users of the non-programming kind might :)

Will there be support for Javassist-style runtime compilation of the custom Java code?

#19 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 15 December 2008 - 06:18 PM

I personally do not mind writing Java code. Potential users of the non-programming kind might :)

Will there be support for Javassist-style runtime compilation of the custom Java code?

Lua is considerably more obscure than Java, especially now that intro programming courses are given in most universities for anyone in a technical field (math, science, engineering). Anyone who knows C++ could probably make the small jump to java easily, especially if I make one or more tutorials (which I plan to do anyway, just to demonstrate the features of the API).

I'm not sure I want to get into Javaassist, as I always want to be able to rely on the integrity of a default set of mechanics. Instead of allowing people to modify one set of mechanics (requires modification of java bytecode at runtime), you may select one "representation" to use when running a simulation. There will most likely be one default representation (not modifiable), and the ability to create additional custom representations that override some or all of the default representation. I (or other developers) may release a new version of the software every time major mechanics change, and the default representation will be updated as such.

You could help me a lot by answering the following question:
What, specifically, would you want to write custom java code for? How complicated would it be, and what other types of objects would you want to be abl e to listen to and/or access (i.e., listening to target health, # of debuffs on target, etc...)?

Also
I'm looking for some help in retreval of information relating to WoW mechanics. For example, I was looking around for a table of base stats vs. level for each class/race. Apparently, such a table does not yet exist, but the information should be relatively easy to obtain. Without this, it's difficult to do things like allow leveling players to select the most effective quest rewards.

#20 Ullas

Ullas

    I hate springtime

  • Members
  • 41 posts

Posted 16 December 2008 - 10:07 PM

Hi all,

I finally have something to show you guys. I have added a screenshot of the user-interface to the first post. Obviously it's still a work in progress, but hopefully it will give you an idea of what it will look like, and how you might use it.

The pane in the bottom will have one tab for the program output (println), and another tab for the combat log of the simulation. The pane in the middle will show a variety of things (more tabs), including tables, plots, and web content.

I know it doesn't seem like much, but for a project like this there's a whole lot to do before you can do anything of interest via the gui. I still expect to be able to give you guys something to play around with between christmas and new years. You most likely will have to plug your stats in manually (as opposed to linking to armory, picking from a list of gear, etc...), and attack a stationary opponent who doesn't fight back. My aim is to get you guys testing the hell out of it while I'm working on the next step.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users