Trending Games | Path of Exile | World of Warcraft | Astellia | TERA

    Facebook Twitter YouTube YouTube.Gaming Discord
Quick Game Jump
Members:3,909,053 Users Online:0

Show Blog

Link to this blogs RSS feed

MMORPG Methodone

First post explains the reason :)

Author: tupodawg999

Class vs Skills Part 2

Posted by tupodawg999 Thursday January 8 2009 at 12:03PM
Login or Register to rate this blog post!

Further thoughts on the class vs skills debate after trying a bit of prototyping.

I decided to try and do quick and dirty prototypes of various of these design ideas separately to get an idea of how difficult they'd be to code fully. I think this is a good way of stopping yourself going down blind alleys. I started off trying to build a little standalone thing using Visual Basic that displayed all the skill trees I had in mind on separate tabs with the code for requirements ( the code that for example stops you selecting "Master Swordsman" unless you already have 24 warrior skills including "Expert Swordsman" ). It didn't take very long before I had skills and tabs out the wazoo and it was all getting a bit too complicated. I could code my first idea eventually but the fact that it turned out to be overly complicated to code made me step back a bit and think harder about why I'd automatically picked a skill based system.

What's wrong with classes?

After thinking about it I came up with three things that bugged me.

1) Freedom within a class:

You start a game and decide to play a warrior. You're okay with playing a class with restrictions etc--you can't heal, can't use spells etc and that's ok. You decide in your head that you want him to be a big dumb guy who uses a two-handed hammer but you can't because the fighter class in the game doesn't work that way. So it can be quite minor like wanting to use a 2H hammer but the game making you use axes.

2) Hybrid, but not my hybrid.

There are archetypes and a class is usually either an archetype or a hybrid of two archetypes. Some of theses hybrids are almost standard, like the fighter/priest paladin hybrid, but some aren't, so a particular game might not have *your* fave hybrid. Games with multi-classing can get round this to a certain extent but even then it might not be enough for some e.g one player might want a hybrid that was 2/3 fighter and 1/3 scout while another wanted 2/3 scout and 1/3 fighter.

3) Right name, wrong hybrid.

With the standard MMO combat system you have the set roles, CC, Melee DPS, tanking, healing, ranged DPS etc and over time (it seems to me) games have become increasingly focused on slotting a particular class into one of those roles. That can cause a conflict sometimes if the role doesn't fit how a player sees a class. For example in most games now a ranger is ranged DPS for group fighting whereas my kind of ranger class would involve lots of non-combat skills that made it easier to explore without dying. So there can sometimes be a mismatch between the game's definition of a particular fantasy archetype and an individual player's definition of that archetype.

So, at least partly... class vs skills is actually a spectrum rather than a clear divide and the spectrum is how much player freedom there is when it comes to customizing the abilities of their character and how much a lack of freedom bothers individual players. My first thought was to have (almost) complete freedom where a player could learn any skill up to a maximum number of skills. But that first prototyping made me stop and think about it more.

So what I'm thinking now is:

1) Freedom within a pure class i.e a warrior talent tree where you pick the individual skills you want as you level / skill up. Or a wizard skill tree with different lines of spells and you pick the upgrades that suit your preferred style.

2) A multi-classing system that lets you make the hybrid you want. One way would be divide skills into categories with a self-contained upgrade tree and then allow players to pick the three categories they wanted. For example a player who wanted a pure fighter would pick the general, basic melee and advanced melee categories while a player that wanted a priest would pick the general skills, basic melee and priest skill categories. You'd build your own class from selecting 3-5 skill trees that each contained a bundle of related skills.

This could be quite a good way to do things even if you wanted to have pre-set classes. By writing the code around a game class being a collection of 3-5 skill trees you could easily create a new class around a different collection of skill trees.

This sort of system might also help with point 3) above with one collection of skill trees suiting a player that wanted to be ranged DPS and another being better suited to exploring.

So, back to the drawing board for me but it does show how useful prototyping can be in getting a clearer picture of what you want.

Edit: Forgot to mention: after having a quick dabble I can see how classes are preferable from a coding point of view. Classes may or may not not be technically easier to code than a skill system but they are conceptually easier to code because they are inherently modular. So I think there's a definite balance to strike between player freedom and ease of coding especially if you have limited resources. Decisions, decisions.