SpellDamage meets BlogEngine.net

Finally, I’ve integrated BlogEngine.net with SpellDamage. This gives me the capability of treating the homepage of spelldamage as my blog and get all those cool blog services like pings, social buttons, etc…

It wasn’t really all that hard, blogengine.net is setup quite nicely for integration. Although I did have some problems with jQuery which has caused me to hold back some features that I would have liked to release now (post comments, tabbed sidebar widgets, etc). I’ll be working to resolve those issues and get them up.

I’m not quite happy with the front page design. It’s too big, so I’ll be working on streamlining it some more… and adding some more polish to various UI parts. I’m also not really happy with the sidebar, partially due to the jQuery troubles and partially because I had to scrap some graphics I had planned for it. That will definitely be changing in the somewhat near future.

One big change is how I reworked the site navigation. It’s now grouped by functionality. The navigation bar has the following links: Home Browse Calculate Compare Leaderboards & Contact. When you hover your mouse over Browse, Calculate, or Leadersboard a small popup will appear allowing you to choose between Mage, Warlock, or Priest. Hopefully this navigation is intuitive, as now you choose what you want to do, and with which class. If you have any problems, let me know.

A loss I had to take in the nuts are the articles I’ve already written. I’ve got them all backed up to Word docs, but the entire article system I had before is gone. Now, those cached backlinks and pages in Google are wasted… I’ll have to work on getting them back again. Oh well… the loss is worth it I think.

I’ll be writing some articles, and making some videos about my journey of merging SpellDamage and BlogEngine.net.

The (Upcoming) Lifecycle of a Calculation

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.

SpellDamage 2.0, It’s Getting Close!

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:

• Spell Database – Probably the single most important update. Now that I have an accurate database of the spells for each class, I can provide calculations to every level range. Yes, that’s right, you 29 twinks out there can now use SpellDamage too! I’ve even developed some back end tools to help me keep the spell data current (in case Blizzard changes things).
• Full Level Range Calculated – I know I mentioned it above, but it’s worth making it into it’s own bullet. The entire level range, 1-70, can now be calculated.
• US, EU, and Korea Support – Well, actually I’m not sure about the Korea support, but 2.0 fully supports the European WoW players! If you happen to know a Korean character/realm, test it out when 2.0 comes out, let me know how it works.
• Tabbed UI – The tabbed UI saves tons of screen real-estate, which frees the site up to better display the calculation results. It also helps a ton to keep everything clean and organized. It’s a billion times better than the current UI, and it’s AJAX’d so it’s nice and fast switching between tabs. To top it off, if the tabs are in the way, you can hide them!
• Top <class> – Each class has a Top <class> page that lets you show off! The data is filterable so you can see who’s truly top of their class. For example, the Top Mages page by default shows the mages who have the top mana, hp, spell damage, etc… with no filters. You can begin applying filters to it, such as level range, realm, battlegroup, etc… If you wanted to see only the 20-29 mages in the vindication battlegroup, you can!
• Article System - There’ll be an article system in 2.0, where I’ll write articles about class balance, theorycrafting, and anything else I feel like!
• LINQ - Actually, this is a feature of ASP.NET 3.5, but LINQ has allowed me to be extremely productive with the little free time I have. The auto-generated classes right from the SQL database top the cake!
• WoWArmory Data – I’m pulling a bit more armory data than before, and storing more of it as well. This supports the Top <class> pages.
• And more…

Hope you all enjoy SpellDamage 2.0 as much as I like developing it!

Quick CSS Tip

Do it right from the beginning! Don’t do what I did, just write quick CSS classes for each part of the presentation, just to get it done. Take some time, write practical, reusable CSS classes.

I’m diving back into my stylesheets and cleaning up tons of code! Every byte counts when it comes to high performance websites… and hefty CSS stylesheets can be blamed for some slowdowns. Going back and polishing a poorly written stylesheet is boring, error-prone, and frustrating… ugh.

So, do it right from the beginning!

Planned Buffs/Debuffs/Talents Change (After 2.0 release)

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.

Woot! ASP.NET 3.5 Released Today!

Well good news,  ASP.NET 3.5 was released today. I haven’t asked my host yet, but they should be able to support asp.net 3.5 soon. Once they have upgraded, I can release SpellDamage 2.0. I don’t have time to port it to the MVC framework, so that will come later… probably version 2.5 or so.

What will be in the first release? Calculations for Mage, Warlock, and Priest. The other classes will come after that, but not too long after. Since this will be the first release of the Priest calculator, expect a few inaccuracies. I’ll get them fixed as they’re reported. There is also a top <class> feature, that is filterable and pretty fun to use. There are more features in the works… SpellDamage will never be complete, there will ALWAYS be something new to add.

I’ll be releasing a video tonight that will show a quick look at SpellDamage 2.0 in  action. It’s not much, but shows a couple of the new features. Stay tuned, SpellDamage 2.0 is coming soon!

Quick Update: WoWArmory Pull Fixed

Well, turns out there were some changes to the backend XML data output from the WoWArmory. I’ve made the updates needed, everything’s working again… phwew!

ASP.NET MVC Framework…

A little while ago, Scott Guthrie introduced the ASP.NET MVC framework, you can read my initial post on the topic here. Well, today I read Scott’s next ASP.NET MVC post, and holy crap the ASP.NET MVC framework looks awesome!

What would the MVC framework do for SpellDamage? I hinted at it in my previous post, but an MVC framework enables some seriously cool features.

First, the native URL routing is simply perfect for my type of application. The URL routing in an MVC framework maps controllers to actions. A template of what a URL would look like in a MVC SpellDamage.com is this, www.spelldamage.com/<class>/<name>/<realm>/<continent>. There would be a controller for the <class> and the other parts would be variables into that controller. The controller would then call on the appropriate view to render the HTML to the visitor.

Second, AJAX! Now, I know… to most AJAX alone means diddly. And, in the world of ASP.NET AJAX it’s generally done wrong simply because the UpdatePanel control is horribly inefficient. But the MVC framework fixes that and allows for smoother calls to ASP.NET AJAX to update only the portions of the page that need to be, severely reducing the amount of traffic to the web server (in turn, increasing performance for the visitor).

Last, but certainly not least, fast, clean, efficient pages. In the MVC model, things like session state, view state, control IDs, etc… are not generated. Only elegant, clean, efficient HTML code is emitted to the browser. In the postback model, there is a ton of extra crap that gets generated into the output to the browser (increasing page size, reducing performance).

In closing, porting SpellDamage to the MVC framework makes perfect sense to me. If MS holds true to their deadline, I should have the MVC framework in my grubby mitts in a few weeks. After that, a quick port to the framework, workout some of the kinks, rework a bit of code, and voila! SpellDamage 2.0 MVC’d!

Warlock Calculator Primary Development Complete

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:

1. I want to ensure the data is accurate. Too many downloadable, parsed databases running around… plus they have more properties for each spell than I need.
2. I want to  add in some spell properties that aren’t standard properties. They are simply there to help me pull the correct spell for each level/class combination.

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!

Progress is Bliss!

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!