Quick update here, SpellDamage:Discovery is live… check it out www.spelldamage.com. Watch this video to see the new features in action.
All you Druid players out there will be happy to know that Druids are the next class to be implemented in SpellDamage… in the next release. Check the under development page to keep informed.
In order to truly port SpellDamage to the ASP.NET MVC framework, I need to adopt some RESTful conventions. It’s not entirely a simple process to port a web forms ASP.NET site to MVC, especially if the whole MVC pattern is unfamiliar. Some of the things that were handled for me in web forms need to be done more manually in MVC. That’s not necessarily a bad thing, it has forced me to mold SpellDamage into a better application.
First I need to ensure my controllers are doing just that, controlling. You could almost think them as conductors, orchestrating the application. They contain actions, which you imagine are the things that happen on the page such as list, create, edit, etc… Controllers aren’t aware of how to retrieve data, and shouldn’t really contain a whole lot of business logic either. They control the flow and rely on models and views for the other tasks (data/business logic and presentation).
Models need handle the brunt of the work. They perform the data retrieval and business logic. They don’t understand the flow of the application, nor how to present anything to the application user. They rely on controllers and view for that.
Views handle the presentation tasks. They aren’t aware of the flow of the application and have no idea how to retrieve data. They rely on controllers and models for that.
In light of that, I need to make a lot of changes, so I went straight for the notepad and pen. What follows are my plans to change the calculation process in SpellDamage forever. In the process, everything will have it’s place and responsibilities in the application… making future changes a cinch (in case you didn’t see it, check out my preview of next years upcoming features!).
I used a digital camera to make these shots, I didn’t have access to a scanner today. The following picture (click to make it bigger) is the first two steps of the new calculation process:
In the pic above (click to enlarge), you can see the initial UI is responsible for gathering the inputs from the user, creating a UIinputs specification and sending it to the SpellFactory. But, before it can get into the SpellFactory, the SecurityGuard does a quick check to make sure it’s ok (don’t pay attention to misspellings in the pic).
After it clears security (see above pic, again click to enlarge) the SpellFactory reads the UIinputs specifications and “creates” the spells based on the specs. (in SpellDamage, the specs are things such as level, class, talents, buffs, etc…). Once the spells have been created, the SpellFactory passes the spells over to the Calculator.
The Calculator takes the spells and performs the calculations, creating a results package (see above pic) which is then delivered to the UI. The UI then opens the package and displays it to the application user. It’s important to note that, at this point, the UI can be anything. It can show the results package in many formats, such as HTML, XML, JSON, etc…
So that’s a quick overview of the upcoming changes behind the scenes of SpellDamage. I hope it was informative, and you can get a better idea of what’s going on.
Alright everyone, SpellDamage 2.0 is very close now. I’m just finishing up the Priest calculator, should be done by the end of the weekend. After that, I just polish the site until my host has finished setting up ASP.NET 3.5.
So what’s coming? Here’s a quick review of whats new:
Hope you all enjoy SpellDamage 2.0 as much as I like developing it!
Well, I’ve found something that will require a revamp of the calculation process… the way Buffs/Debuffs/Talents are added into the calculation. Currently, they’re hand-coded into each class’ calculator. As you may be able to guess, this is a bad thing. Imagine if a buff was changed in a patch, I’d have to change each class’ calculator one-by-one in the code.
So what’s the fix? Well, first I’ll need to create a database to store the buff/debuff/talent data. Then, I’ll need to figure an efficient way to linking buffs/debuffs/talents to spells during calculation. I will also need to dynamically generate checkbox controls into the UI to allow visitors to choose which buffs/debuffs/talents are applied. Essentially I’m creating a spell/buff/debuff/talent content management system for spelldamage 2.5.
How does this help? Well, the initial programming is going to suck. It’s hard work to get something like this working efficiently and error-free. However, once it is done, maintaining the calculators will be drastically improved. No longer would I ever need to touch the code to add a new spell into the calculations. Same for buffs/debuffs/talents… I’d never have to code anything for them again (unless some new mechanic was introduced).
Here’s how I envision it to work. Lets say Blizzard decided to add a new damage doing spell to Mages. Lets call it FrostBlast, an instant cast frost damage spell with a 20 second cooldown (lol). In the SpellDamage admin panel, I’d click “New Spell”, type in the data, choose the buffs/debuffs/talents that can potentially be applied to the spell, and click save. Viola, a new spell, complete with coefficient/modifier changes from buffs, debuffs, and talents. The calculation engine automatically picks up the new spell and performs the calculations on it, and displays the results to the visitor.
The primary development, that is – the development that needed to be done before any spell damage calculations could be performed, is complete. Now I simply need to add the warlock spells into the spell database and code some simple calls to the calculator engine (which I’ll talk about in a future article). The process is really simple, but a bit time consuming as I’m culling and entering the data into my spell database manually.
I’m doing it manually for two reasons:
Hopefully, I can have the Warlock calculator done this week. I’m still working with my host to find some .NET 3.5 hosting, if I cannot have the hosting ready by the time the Warlock calculator is done – I’ll start working on the Priest calculator.
Damn I can’t wait to get all the classes done… exciting times. Stay tuned for more!
Just a quick update on my progress with SpellDamage 2.0. Everything is coming along great and I plan to have the basic mage calculator done perhaps this week and have the plumbing done on some more advanced calculations.
Then, it’s polish time. I’ll take some rounds through the site to run error checks, take the code through it’s paces and find out what I like and dislike… and make repairs.
After that, depending on my mood, I’ll either release spelldamage 2.0 with Mage only, or get crack’n on adding more classes. Because, basically at that point, everything is done. It’d only be a matter of adding the spell data into the spell store and then some basic coding to get them into each class’s calculator.
Today I added a new feature. You’ll be able to add/remove spells from the calculation results. If you only want to perform the calculation on a few select spells, you’ll be able to in the next version of SpellDamage.
Stay tuned for more!
Well, I hinted at a very cool feature that I plan to introduce with the next release of SpellDamage.com (version 2.0) in my last post. Today, I wanted to delve a little deeper into the feature.
Statistics… I’m trying to make statistics fun, for more than just the math junkies. So, for SpellDamage 2.0 I’m going to try to turn statistics into something of a top score list (like in an arcade game). Each class will have a statistics page. When you visit, for example, the mage’s statistics page, you’ll see a series of categories and a list of the top 10 mages for those categories. The data is taken directly from the WoWArmory for accuracy.
Now, alone this would be cool. The very best mages could claim they’re the best mage in the world! But that’s not fun for the thousands of other mages. So, I’m building filters and dynamic queries to let you shape the statistics to what you’d like to see. For example, a few of the filters are the min/max level, realm, and guild filters. All the filters can be used in conjunction with each other. So, if you wanted to see who the best level 20-29 mage is on the Tichondrius realm, you can… there are more filters, so just wait… the next update is going to be tons of fun!
That’s all I’m going to say about that for now. Once it’s done, I really hope you’ll enjoy the new spelldamage… it’s really hard for me to be working on the new one and looking at the old one online. The old one just pales in comparison… perhaps I’ll break and put the new one online before it’s complete… but probably not.
For all those Euro players out there, spelldamage 2.0 will support player pulls from the euro version of the WoWarmory! The wait will be over with the next release. It’s been tested and the feature is in! I’m even planning on supporting Korean (and perhaps Thai) if I can get some valid links to some Korean and Thai characters from their respective armory pages. In the future, I plan to support any continent that blizzard builds a WoWarmory for.
And, because I’m in a bit of a giving mood today… I drafted a small sneak peek. The following screenshot is of the Mage calculator (with some parts mudged up so there are some surprises left). Bear in mind, I haven’t populated the spell db entirely, so only Fireball, Fire Blast, and Frostbolt are calculating at this time.
You’ll notice the tabbed interface. That will be expanded as I develop the calculator more. But for now, it contains the important parts and does a good job of keeping the UI very clean. If you look up and to the right, you’ll see a blue [hide] button. Clicking this will hide the tabs entirely, and it will change to a [show] button (clicking show brings the tabs back).
Still a lot more to do, but hopefully that soothes your curiosity a bit. At some point in the future, I may release a quick video showing it in action.
Enjoy!
I wish I would have done this sooner. First, I built some tools to add/edit/remove spells from a spell db I set up. The spells contain their normal properties, like range, mana cost, etc… but I also put in the level you get the spell and the last level before you get the next rank.
This has allowed me to pull each spell, based on your class and level… the upshot of this is that I can enter the spell data into the db, and the calculator pulls the correct spells automatically! No longer will I need to hand-code each calculation! I write the calculator once, and it’s complete for the entire level range simultaneously.
This means that I’m going to attempt to launch the next spelldamage with every class’s baseline calculations complete (although I’ll need some testers to ensure the calculations are accurate).
In addition, I’ve come up with some ideas to improve spelldamage, as it will quickly turn into a very data-centric application, I’ll be using it in some very creative ways. Stay tuned, you won’t be dissappointed with the next version!
While writing some of the new calculation code for the upcoming spelldamage.com 2.0, I ran into a small problem. Let me describe the process a bit before I get to problem.
First, one of the major upgrades coming in the next version is a central spell store. This storage will maintain an accurate baseline data for all the damage doing spells in World of Warcraft. This will allow me to perform calculations for every rank of spell simultaneously, I won’t have to worry about hand-writing calculations for each level. Then, if Blizzard changes any of the spell data in a patch, I can change it in my spell store.
