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.

Character Comparisons on SpellDamage!

I released an awesome new feature for SpellDamage today. It’s a Mage Warlock Priest comparison tool, which will visually show you how the characters stack up to each other.

Made a video about it, check it:

The tool took 2 days to make. Nailed down the code the first day, polished it and prettied it up the second. If you find any problems, let me know!

Minor Upgrades: 06/03

Today I made a minor upgrade to spelldamage. It’s primarily a code maintenance release, but the upside is that you should see the error page less often (if you even saw it at all). According to my logs, quite a few of my visitors were being directed to the error page for various reasons.

Hopefully this release makes spelldamage so stable you never see the error page. But if you do, please let me know.

Thanks!

Very big changes coming to SpellDamage

In case you missed this post, “SpellDamage to Focus on Cloth Casters“, go read it. Basically, it says that Druids aren’t coming soon anymore. Sorry Druids, Shaman, and Paladins. Perhaps someday I’ll get to you.

So, the big changes. Yes, I’m reworking spelldamage again. I don’t want to write articles, and I don’t want the homepage to focus so intently on articles. So, I’ve rewritten the homepage (and a large portion of everything else too). Read this post, “Big rework coming soon“. It goes over a bit of what coming.

SpellDamage:Discovery is Live, and Druids are Next

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.

Facebook, really

I don’t really update here much anymore, for the latest, make sure you checkout the spelldamage facebook group. Let’s get some discussions going, I’ll work to make spelldamage what you want it to be.

Thanks.

SpellDamage on Facebook

I’ve opened a Facebook group for SpellDamage. Please, login to Facebook and get into the group. Let’s talk about what you want from SpellDamage. From now on, I’m going to be using Facebook for feedback and discussion.

Thanks to all SpellDamage supporters, let’s get together on Facebook at talk about the future!

See ya!

Code Name: Discovery!

For the first time ever, I’ve decided to name the next upgrade to SpellDamage. The next version of SpellDamage (version 2.5) is code named Discovery. There’s a very significant reason that it’s named that way. In the coming weeks I’ll be releasing some sneak peeks into the new version.

Let me just say that the next release will blow you away! I’m not kidding here folks, the port to the ASP.NET MVC framework is coming along MUCH better than I expected… In fact, halfway through porting the Mage calculator, I stopped… stunned! At a sudden realization that with just a few tweaks, SpellDamage.com could become a serious contender as one of the most useful WoW fansites.

Here’s a little tidbit of what’s in the works right now. Now think big… no, bigger! I’m cutting the Top feature. “Wait, that’s not big!”, you say? Well, your right… it’s what it’s being replaced with that is HUGE! It’s so huge that I’ve named the feature “Discover” (which has such an impact on SpellDamage, that I’ve named the next upgrade “Discovery”!).

I’m going to leave it at that for now, let you try to imagine what Discovery could possible mean for a site like SpellDamage.com. But, for now, go to the spell damage calculator of your choice, play with it, get used to it… but get ready for it to change drastically (ok, not the calculator itself, although that’s in the works too)!

Thanks for reading!

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.

New Feature of SpellDamage 2.0 – Spell Database

Today, I’m going to start a series of posts about the new features of SpellDamage 2.0. The first post in this series will be about the Spell Database.

Using LINQ, I can easily pull the spells that are required for each class/level range. Doing this means that the SpellDamage calculators now support the full level range, from 1 to 70 (80 once WotLK comes out). What’s the benefit? Well, personally I like it for the level 29 bg characters I run… I’m sure others will find the same to be true. Plus, the calculators now cover you while you’re leveling.

To see it in action, visit www.spelldamage.com/Mage and run some calculations.

I’ve written some tools to help me manage the spell database, which will (hopefully) allow me to keep up with the changes (ahem, nerfs) that Blizzard comes up with. It’s a slick way for me to maintain the spell data without having to actually get my hands dirty in the code, like I did with SpellDamage 1.0.

In the future I could use the data in other ways as well, such as to dynamically pull spell data based on other factors such as mob immunity, etc… I’m far less limited when the spells are in a database than hard-coded.

Stay tuned, tomorrow I’ll discuss the Top feature, and how it’s going to change a bit when I port SpellDamage to the MVC framework (which has already begun).