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.

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!

Mage Calculator Ideas

Since I’ve got more time to work on SpellDamage 2.0, I’m rethinking my calculation output. Here’s some ideas I’m throwing around right now:

• Dynamic. The output must be dynamic. Currently, the output is molded to a preset output that the UI expects to receive. This MUST change, the output simply must be dynamic. I don’t want future ideas/features to get held up because I have to manually jam a bunch of UI changes.
• Advanced calculations. This is sort of a tag-on to the dynamic output. I’d like to code the calculator to give you a choice. Do you want to see a simple, basic calculation? or do you want to see an advanced calculation that takes crit/hit rate into consideration? I also want to code some spell rotations. What are your favorite rotations!?
• Tallies. Under the basic calculations, I want to add tallies that show the total casting time, damage, dps, dpm, etc… for the spells that have been calculated. This will assist players wanting to add up how much damage a few select spells will do all together.
• Compare. I’d love the ability to compare 2 or more characters side-by-side. While this is much lower priority than the dynamic output, this would be a really cool feature. It would be even cooler if the output windows were draggable and you could line them up the way you wanted.

You have any ideas? Share them by commenting to this post. Thanks!

Mage Calculator is Complete

Well, the SpellDamage 2.0 Mage damage calculator is complete. I’ve decided once I’ve finished the Warlock calculator, written some articles, and polished the site up a bit more, I’ll release the new SpellDamage. I just can’t stand having that old one online, it’s so crappy compared to the new one.

So, if things go well, I should be able to launch the new SpellDamage by December 1st. After launch, I’ll work on more articles and the other class calculators (and top score pages).  Very exciting times… so much goodness in the next release, I can’t wait to show it to you!

Uh oh! ASP.NET MVC Framework? What does that mean for SpellDamage?

First, check out this post from Scott Guthrie about the ASP.NET MVC framework, http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx.

Once upon a time, I was interested in Ruby on Rails for the clean separation of code and responsibility… but primarily for the native url mapping of an MVC framework. Well, now that I know there will be an ASP.NET MVC framework, I HAVE to port SpellDamage to it. The problem is, the MVC framework isn’t out NOW… should be released sometime by the end of the year.

What does this mean for the SpellDamage 2.0 release? Nothing… yet. I’ll probably call the MVC’d version of SpellDamage version 2.1 or something. Since the MVC framework isn’t available right now for me to begin porting, I have to wait. I don’t want to take too long to publish SD 2.0.

Why do I even want to port to the MVC framework? Because of two things primarily. First, and most importantly, the native URL mapping. I like clean URLs and I like having URLs that Google likes to parse. It also makes it easier to remember a direct link to specific character is in the calculator. Second, AJAX integration is much easier with an MVC framework over a postback model. An MVCd SpellDamage would have a much richer, cleaner, more modular UI and would be much faster with some simple AJAX UI parts.

Stay tuned for more.

Euro Support & Perhaps Korean Too… how ’bout a sneak peek too?

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!