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

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.

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.

Although this is certainly possible once we get the gear into the program, figuring out what's in your bank without requiring you to manually add each item (from a list of items) is difficult/impossible. Even if one day you can see what's in your bank via armory, it will certainly be password protected. I have no intention of providing a means to access the password-protected sections of armory (guild bank, calendar, etc...), just because that's substantially more complicated than XML parsing (which is pretty much all that's required for just getting things like items, character data, etc...)

I don't have an answer for you here yet. This type of thing is easy if I design a specific "main/alt raid optimizer" action, but I would rather have a more elegant solution that is more broadly useful (i.e., you have two warriors, both with tanking and dps gear, but you only need one of them to. Which one should tank, given the nature of the fight? Maybe one of them has an enhancement shaman alt, and the other has a mage alt. What's the optimal setup?)

Many people have asked for this. This feature will be available very soon after I release the armory module (looking at mid to end of January for that).

This is a complicated problem, and if you can tell me exactly how you would methodically figure it out by creating hypothetical WoW encounters and comparing results, I can implement it. This is a simple matter of finding the increase in dps per unit of each stat ( the "value" of each stat to that character), and then computing the total value of an item to each character. That being said, I have no idea how to figure this type of thing out for a healing class, other than by picking some arbitrary metric of performance like throughput or regen.

For example:
Do you test each character independantly or in a raid or both? Who's in their party? What buffs do they have? What is the nature of the boss fight? Do you take raid maintenence into account (i.e., a melee class often needs more healer attention than a ranged class)? Maybe combat rogues perform better than either destruction warlocks and spriests, but the spriest and warlock together do better than both rogues?

I love the discussion that's going on here. You all are steering me towards providing the WoW community with something really cool.

While Ullas's tool may answer most of these questions, but at least for now Rawr.Ret can answer all those questions pretty well.

Rawr is a decent comparison tool once Ullas starts adding class spells in.

Not to bash Rawr or anything, but it can only offer suggestions as to what upgrades can be found out of a list of all items available in certain categories of dungeons. What he's asking is, out of the gear he has on his character and in his bank, what should he wear. To the best of my knowlege, there's no way to filter the gear that Rawr offers as selections, other than by dungeon.

It's relatively simple to write a small addon that will write out what's in your bank into a SavedVariable file. Once this is done you can either provide an importer for that file or just allow a plugin (or whatever Netbeans calls them - modules?) to do so. Given that what you're writing is going to end up as more of a platform than a complete and closed program, I'm more interested in making sure that I can get at the data than that you already provide the functionality to do so.

On alt optimisation, your way of thinking about it is probably the way I'd choose to solve it too. That said, I couldn't think of a use-case for the more elegant solution, so I just wrote the simpler one.

I think you have misread my last quoted use-case. Specifically, if I'm in charge of recruitment, and I have 25 players who show up for 100% of my raids, and one leaves, I have a spot for recruitment. I'd like to use your tool to evaluate what I should be recruiting, i.e. what the raid DPS increases of each class - with nothing else changing in my raid - are.

Rawr goes a long way to answering the question but doesn't include whole-raid optimisation. For example, "the single highest average DPS spec" for a deathknight in a caster-heavy raid but no moonkin/warlock (Unholy) is *radically* different for a deathknight in a melee-heavy raid with no hunters/enh shamans (Blood, ceteris paribus).

For Ret specifically, I agree, it's most of the way there, but that's mainly down to the single-tree nature of Paladin DPS than any essential completeness of Rawr.

I would still like an answer as to specifically, what people would like to be runtime-customizable via their own java code. Do they want to experiment with new ideas for talents? Spells? Relationships between stats (i.e., changing the attack power to crit ratio)?

Making everything conducive to using custom code will make development take a bit longer. Right now I'm making it so you can import your own talent trees, eventually maybe there will be a wizard or something. I'm going to make some of the combat-related parameters adjustable, but the fundamental way in which they will work (the nature of dodge, block, miss, parry, crit, etc...) will be somewhat hardcoded.

Question to you guys
The best way I can think of implementing talents, buffs, etc... is to have a bunch of keys like PROP_STRENGTH, PROP_CHANCE_TO_HIT_WITH_OFFHAND, etc..., and express all buffs, items, talents and on-use effects (i.e., trinkets) in terms of these keys. It's not so easy for users to add their own brand new spells at runtime, but it makes the creation of talent tree files much more straight forward (only certain parameters need to be stored in the file, as opposed to serializing the behavior of the talent its self).

A fantastic alternative would be pulling spell data from some online database. However, I have yet to find a site like wowguru, that allows spell data to be accessed by third party programs (wowhead provides easy access to items only). If such a database exists for spells, could someone point me in its direction?

What do you mean by 'easy access to items only' regarding Wowhead? Spells, their names and descriptions are all in Wowhead DB. Accessing them in a sane manner would require some crawling probably. Mechanics must be hard-coded or the metadata provided by you anyway, but for complete listings and descriptions Wowhead DB is available.

For example: Mage - Skills - World of Warcraft produces a list of max-rank mage abilities. In that pages source code you have: Taking Slow Fall as an example, if you paste "?spell=130" after "http://www.wowhead.com/" , you'll get to slow fall spell page and can get more specifics from there. (admittedly slow fall isn't a prime example for a combat mechanic simulator - but that's the general idea)

Using the filters at Wowhead can land you at the right data quickly, but the max output is 200 per page so to avoid page navigation with filters you could define the starting filter's in a way it provides the correct data.

Sorry if this wasn't what you meant with the easy access part

Hi Ullas - I think it would be fairly simple for Wowhead to implement that per your request, especially if they already have that for items. Worth a shot at least I guess