Tifordin

TL;DR version:

MageTheorycraft is an application which aims to simulate accurately what happens in WoW when a mage is casting for the duration of a boss fight. Parameters about what the mage's stats are, and what spells/talents he is using are input to the application, and a simulated combat log is displayed for the duration of the fight.

Factors such as spell haste, spell hit, talents, trinkets, mana regeneration, player mana, etc etc are all taken into account. All appropriate mechanics are simulated in the same manner as they would be in-game.

Get it here: [ magetheorycraft.zip ] (367kB)
Screenshots: [ Screenshot 1 ] [ Screenshot 2 ]

NOTE: Currently there is only support for fire mages, and there is not yet a full set of gear/spec options. Read down for details.


Long version:

Looking at various other theorycraft tools related to mages (spreadsheets, websites, etc) over the last few months has inspired me to take a crack at my own spin on theorycraft. The end result is MageTheorycraft, an application designed to simulate what happens when you are in a boss encounter in WoW.

MTC is a work-in-progress attempt to accurately model WoW at a simple level - casting mechanics and an event-driven timeline. MTC does not offer any information such as the value of various stats, or what gear can improve your DPS. It does not hold your hand and suggest what you should improve on. But in a very real sense, you can plug in different stats, gear choices, and talent choices, and receive an accurate summary of simulated damage for a particular fight duration, in a way which I believe is relatively unique to MTC.

In a nutshell (for the geeks):

• Written in C# (.NET 2.0). While I realise I will probably cop some flak for not using C or C++, C# affords better OO control and makes for cleaner code, not to mention extremely simple UI coding.
• Various details are plugged into the application such as player stats, available spells, fight duration, etc. A "combat log" for that fight is displayed, along with a summary of damage done.
• MTC utilises a custom timeline class to handle all events.
• Base classes for Spell and Buff are extended to simulate various effects (Fireball, Combustion, trinkets, talents, etc etc).
• A single State class is used to drive the simulation. This class is initialised and run by the UI component.
• An "AI" class is used to simulate actions a smart player would take. This can be tweaked as desired (Player.cs). At this stage it does things such as:
  - Pop Combustion at appropriate times.
  - Use gems, evocate and potions at appropriate times (eg. Evocation won't be popped if a rescorch is needed soon).
  - Scorch to keep debuff up as necessary.
  - Wand when mana drops below a certain level.
  - Fireball if nothing else needs attention.
  - Etc.
• Roughly 2200 lines of code so far.

What IS present in the current application:

• An event-driven timeline (events can be slotted in at any time, and are performed in chronological order).
• A spell framework.
  - Cast time, mana cost, cooldown, effect delay (eg. for a fireball, which takes some time to hit its target after cast is completed), etc.
• A buff framework.
  - Active/passive (eg. auras are passive), duration, etc.
  - Full support for procs off other events such as damage, spell cast, etc.
  - Full support to influence various game mechanics, such as spell haste, mana cost, crit chance, bonus damage, etc.
  - Passive talents implemented as passive buffs.
• Buffs and spells both easily extensible to allow for new abilities.
• A damage framework.
  - Bonus damage coefficients.
  - Damage type (fire/frost/etc, hit/crit/resist/miss).
• Casting/non-casting mana regeneration (mp5).
• Haste.
• Non-zero reaction time for player actions.
• GCD.
• Mana gems (including a 3-charge Emerald), mana potions (an infinite supply assumed), evocation.

What ISN'T present in the current application:

• Support for classes other than mages, or specs other than the cookie-cutter fire specs. In theory such things should be as easy to add as creating more Buff/Spell classes. MTC has been built from the ground up for simulating casters however, and as such would not be suitable for simulating melee classes. It also has no in-built support for pets (although these could be represented as a buff).
• Partial resists - a ?? boss has a 6% chance for a partial resist which isn't yet accounted for.
• Proper support for wands - currently wands are treated as Physical damage (instead of that particular wands true damage type) so that they do not reset the 5 second rule. Wands are also affected by things such as (non-fire) crit rate, spell hit, etc, as though they were a normal spell. This may be inaccurate (but I was unable to find good information regarding wand mechanics at the time of writing the wand code). Note that wands have a bonus damage coefficient of 0 so are NOT affected by bonus damage - at least this part is accurate :P
• A full range of spells and buffs is NOT present. I have focused on the framework at this stage (like creating a game engine, then paying designers to build the actual content later :P). For example, the following are some glaring items which are missing from the current set of spells/buffs:
  - A range of trinkets (currently only Quagmirrans Eye is implemented).
  - Icy Veins.
  - Fire Blast.
  Note that the common talents in a 10/48/3 build are accounted for - I haven't had time to fully adjust MTC to 2.3.2 yet!
• Support for mechanics such as fight movement, or spell pushback. The fights are currently assumed to be happening under optimal conditions - 100% fight presence, no pushback or movement, no loss of character control, no range issues, etc etc.
• I have not yet included support for buffs to influence several mechanics, particularly spell cooldowns, and passive mana regeneration (eg. for an Innervate).
• In terms of programming/OO style, the application currently has high coupling between classes (particulary the State class - most other classes have the State object passed into their methods!). While this makes programming complex behaviours into the classes more straighforward, it exhibits poor programming practice. Any buff or spell programmed by the user has access to change any part of the simulation, which can be bad for obvious reasons. I hope to change this at some point in the future, but for now it suffices, and simplifies many complex operations. However most objects exhibit good cohesion. For example a Buff class represents a buff - nothing more, nothing less. Also, the core simulation classes are separated from the external UI classes which set up and run the simulation.

Notes:

• DOTs are not displayed in the combat log as they would be too spammy. Note that Ignite is considered a DOT, but a custom log message has been added to show it.
• Because damage is assumed to be against a single target, buffs on the player and debuffs on the target are loosely lumped together. All damage done is assumed to be done against the target.
• Passive talents are implemented as passive buffs.
• Source code is commented thinly but (I hope!) concisely.

To come in future versions:

• The ability to save and load configurations to/from files.
• The ability to pull down player stats from the Armory.
• More meaningful output and analysis/breakdown of fight statistics (WWS-esque).
• Better wand support.
• Fight mechanics such as movement and pushback accounted for (to better simulate a particular fight).
• Improved support for "non-player" actions. Ie. the actions of those around you - WOA totem, heroism, vampiric touch, drums of battle, etc etc.

Above all, remember that MTC is a curiosity, and a work in progress. Like any theorycraft, take it with a grain of salt. Feel free to alter the source code in any way you wish, however if you create new buff/spell classes, or improved AI/UI, do the rest of us a favour and post them below


Disclaimer:
This application should be considered "beta" software. If you encounter bugs (there are bound to be some), post them below. This is not a keylogger and I am not trying to obtain your personal information. Having said that, I have no way of proving it other than you inspecting every line of source code yourself. You do, however, have my word that the code is non-malicious, however much that counts for

I have only tested and developed this on Windows Vista, mileage may vary on other OSes.

 

Tifordin

Application Usage

To use MTC you will need to have the .NET 2.0 Runtime installed.
Extract the contents of the .zip file and run "MageTheorycraft/bin/Release/MageTheorycraft.exe". Hit Config to fill out your player stats. Be sure to mouse over the blue help icons to see full descriptions for each stat. Click Done to return to the simulation window, then Run to run the simulation.


To edit the MTC source code and compile, you will need to have the .NET 2.0 SDK installed. This ships with VS2005+.
Edit the project files as you wish, then use build.bat to build the application. Run it from the same location as above.

 

◊ manly

I will take a serious look into it given that I have been programming in C# since the first day it came out.

With this said, I would strongly advocate that you build the UI using .NET 3.5. It would much further simplify the programming of it (assuming of course some knowledge of XAML).

EDIT: I forgot to mention -- for purposes of making graphs, and to display a tiemline where you would see when cooldowns are popped.

Log on with different model:
1- Create a character of the desired model. Log on/off.
2- At character selection screen, select your actual character; mouseover the new, desired model character, and hold down left click; hit enter and release left click at the same time.
bug Arcane Potency only applies to the first Arcane Missile bolt.

 

Tifordin

Ahh yes I was contemplating the best way of generating graphs etc. Will have a look at porting to VS2008 this weekend

 

Hate Monkey

While this is looking like its going to be a fairly decent simulator, if you get everything coded and working correctly, the one thing I will say is be careful on haste calculations for troll berserking(if you get there ever).

Just from looking at the screenshots, do you got your MoE calculation correct? It should be 127/128 mana returned, not 135.

 

Tifordin

You are correct, sir. I had Fireball's mana cost entered as 464 not 425 for some reason. It is also currently being affected by Pyromaniac's 3% mana cost reduction I believe (ie only 29.91% of the base spell cost is being refunded, not the full 30). 30% of the actual mana cost is getting refunded. Will work on a fix

 

Tifordin

I have spent the afternoon fleshing out the available talents and spells to include 90% of all 3 trees. (Still need to code some of the more complex talents such as Water Elemental, Icy Veins, and Molten Fury). However I am stumped as to what common Arcane/Frost specs would be. Having only ever played deep fire, the best talent choices for the other cookie cutter specs is a mystery to me. It would be of great assistance if someone could bash up some example specs for the following:

10/0/51
Any other common deep frost specs?
40/18/3
40/0/21
48/13
33/28

Using WorldofWarcraft.com -> Info -> Classes -> Mage -> Talent Calculator or similar.

I won't pretend to know the best way to use a Water Elemental and its cooldowns either, so if someone could fill me in on that so I can write some decent Frost AI that would be great also I'm guessing it's along the lines of: summon as soon as Winter's Chill is stacked, pop Cold Snap then summon again, then every time its cooldown is up? Is it crucial to summon after popping trinkets etc? Wouldn't want to inadvertently gimp frost's DPS any more than it already is

 

CHeeSY-CrAfT

Could you model 0/40/21 as well? Something like this: Talent Calculator - World of Warcraft

The basic idea behind this spec being double icy veins under heroisms at the cost of a few fire talents.

 

galzohar

If you didn't include this already, make sure to run over the same fight many, many times, and then list the average DPS as well as the deviation.
With Xi=X1...XN as the result of each seperate test, N being number of tests, and Xa their average, estimated deviation is:
{[1/(N*(N-1))] * sum[(Xi-Xa)^2]}^0.5

where sum[(Xi-Xa)^2] = (X1-Xa)^2+(X2-Xa)^2+...+(XN-Xa)^2


A major issue with a simulator though is that there are many descisions that will need to be made during the fight, and a simulator can't decide on them by itself other than just trying all of them and picking the best one (like mana pots vs destruction pots, mana gems vs flame caps, saving cooldowns for stacking vs popping them as soon as they're up...).

 

zurmagus

This sounds exactly like what I was trying to do with the simulator I coded (in C++) and posted here a few months back, only with a nice UI and other bells and whistles already in place. As I read through your implmentation notes you seem to have designed your simulator in a similar fashion. Hopefully I can find some spare time at work to help this project along.

 

Tifordin

Have been putting in some more work on this project recently, here's a little preview



Want to hold off releasing a build for a little longer as the threading model it uses to render the graph and run multiple simulations is still slightly buggy (half-drawn graphs = fail). But watch this space in the next week or so ... The hard yards have mostly been done, all that remains is to code up the last of the AI for things such as a water elemental, and more efficient cooldown management.

As you can see from the screenshot above, I have added the ability for the user to select N number of repetitions to perform. The DPS Profile Graph and Statistics given are the average of all repetitions.

As a side note, I'm fairly happy with performance for multiple repetitions... On my (admittedly fairly new) PC, 100 simulation repetitions for a 300 second fight takes roughly 2 seconds. The simulations are run in a limited number of simultaneous threads, so should scale well on multiple cores. Also, memory usage is insignificant... Once all repetitions are complete only statistical data is kept, and this only seems to use an additional ~50kB per data set (just looking at task manager). Graphing is also basically instantaneous, taking negligible time in my testing, even with several hundred data sets.

With respect to decisions about cooldowns and consumables, I believe an AI approach is sufficient. The AI has access to all the same information a human player would have access to (Approximate fight time remaining, time left on all cooldowns, remaining mana, approximate rate of mana drain, etc etc). In the same way that a human player simply looks at his available information and makes a decision based on the current circumstance, an well programmed AI player can arrive at the same decision. The aim for for MageTheorycraft is not to give a value for absolute maximum possible DPS (surely this would be a fight where, by lucky chance, everything procced every time, every spell hit for the maximum possible value, and every hit was a critical hit). The aim is to show what damage the average player (or even good player) will achieve given all the starting parameters. If the AI is able to make circumstantial decisions about cooldowns in the same way as the player then I believe this is sufficient for the purpose of MageTheorycraft. The challenge now is to create an AI which is up to the task with regard to cooldown selection. Ultimately I'm going to be looking at some messy decision trees :P but these can easily be represented graphically for scrutiny by the less programming-inclined. Again, watch this space

 

Tifordin

An example of a decision tree to pop Combustion, Icy Veins, and trinkets. Things such as Cold Snap and Water Elemental can be processed in a similar manner.

[ Image ]

It's a bit large, so click to view.

EDIT: Has a few mistakes I can spot already >.> but you get the idea... AI can be easily scrutinised for errors.

 

orionnt

Displaying your Current Mana Pool next to each event in the Combat Log, as well as displaying when Mana Pots/Gems/Evocation are used would be useful

 

Seela

Do you have a read-only subversion link available to the public, where we can check out your bleeding edge version?

Also, would you accept unsolicited enhancements to your application? Taking a quick look at the code here, you have the bulk of the heavy lifting finished and just need more specs, trinket frills, etc. Specifically, I was interested in arcane builds and rotations as they are incredibly difficult to calculate on a theorycraft page and I think someone would get a lot of use out of them if they were run through a simulation engine several times.

 

Tifordin

I have created a SourceForge project to keep the latest source code - you can now grab it from there: SourceForge.net: MageTheorycraft

SVN details are:

https://magetheorycraft.svn.sourcefo...rycraft/trunk/

No password for checkout. Let me know if you wish to have write access to work on features. I encourage others to get in there and work on it! Just check out some of the existing files and adapt them to your needs.