Design Document: Classes in a Skill-Based Game

Some games such as Asheron’s Call or EVE Online are (character) skill-based rather than class-based. This means that instead of selecting “Warrior” or “Wizard” at character creation, players can choose from a menu of powers and skills, possibly assigning points to specialize in them. Most such games will offer default suites of skills that replicate the standard warrior and wizard classes.

The standard suites of skills are almost always suboptimal, and players can unintentionally select sets of skills that make characters unplayable or underpowered, particularly in later levels. This creates a large power gap between min-maxers and casual players.

Some players will be upset that their main characters are weaker because they did not research or use a spreadsheet way back at character creation. This may be especially the case if they selected a recommended default package that turns out to be suboptimal. Power build X is a better swordsman than the official Swordsman class.

The power gap creates obvious balance issues. In PvP, optimized characters tend to win, and few want to be the underdog. In PvE, content is either trivial for optimized characters or nigh-impossible for unoptimized characters. The same content will not challenge both.

Let us take “flavor of the month” classes as a known issue, one that is more prominent in (character) skill-based games, particularly ones that allow easy respecification of skills.

Proposed Solution:
A flexible system of default “classes” will retain the strengths of the original design while circumventing some of the problems. It can also create a sense of buy-in for hardcore players, encourage casual players to engage the forum community, and provide other benefits.

A “class” should be taken to mean a default package of skills. The “warrior” class might be swords, spears, crossbow, light armor, medium armor, heavy armor, and field first aid (arbitrary example). Players will develop and name de facto classes even in a purely skill-based game, so the game’s structure should recognize and embrace this eventuality. Note that the default class package will be defined with some flexibility: it will not spend all the initial skill points, or if it does some of the selections will be recommendations rather than requirements for a character to still be considered a member of the class.

The character creation screen will retain the default class options box. The box must allow for an arbitrary number of classes, with updates expected after the game goes live. (A “completely freeform” option remains.)

Initially, during early beta, this will be populated by a small number of developer-created classes with bare-bones descriptions. These will be placeholders until players start developing their own de facto classes.

During beta, a developer will harvest classes from player-made guides on the forums. These will replace the default classes as appropriate. These will be the official versions of the min-maxer approved options. The intent is to find the “best” or most popular classes and make them common knowledge. While developers frequently fail to anticipate player behavior, they can document it after the fact and provide new or casual players with the benefits of hardcore players’ efforts.

(This information-gathering can assist other balance efforts. For example, if a skill appears on almost every class’s list or never appears, that is a potential balance issue.)

Each class description will start with a introduction. It will list the name of the class, its intended focus, and perhaps some flavor text. Note things such as if the class soloes well, needs a group at low levels, or is recommended only for advanced players for reasons to be outlined.

This will be followed by a list of the skills and attributes that make up the class. Even if these are duplicated elsewhere and automatically selected by selecting the class, they will be documented here for ease of player reference.

Next is a development plan. The initial build will be supplemented with a standard “where do we go from here.” Few builds are complete at level one. If they are, note this and mention the freedom to develop.

Follow this with strengths and weaknesses. Here is what this class does well, here is what it does poorly. This is why you would want to take the class, here is why you might not, and look at class X if you want Y.

Variations will explain common ways to fiddle with the default class. Vary the weapon proficiencies, add a different creature specialization, whatever. Establish a range over which it would still be considered the same class but with more of a group/solo focus or stronger in the early/late game.

This is a good place to add a link to the forum discussing this class. If there is a player-made guide that created this class, link it. This is a de facto FAQ for each class. If the forum environment is toxic, this might be a bad idea; do not scare off the new players.

Conclude with a creation section. This class was designed by @TimTheEnchanter, and the original OgMage was SomeCallMeTim. It was created under patch 12.035 on January 02, 2007, and this description was last updated under patch 17.456 on February 23, 2008. (This could also be a place for a metric of how popular the class is, such as the number/percentage created in the past month or the percentage of playing time attributable to this class, with a ranking against other classes. This could reinforce herd behavior, sending people to the most popular classes, or it could inform players that tanks and healers are rare and therefore may be in demand.)

Finally, remember to include any decorative details. If there is an example avatar, video, song, etc., make one for the player-made classes. A fun option could be showing the same character at three stages of its life, say early-, mid-, and late-game (“here is what you aspire to”). This is a professional character creation screen, and we will not imply that the character-made options are less worthy of attention than the developer-made ones.

A minor staff commitment will be needed to update class skills and descriptions, and to watch for new ones. Community development will help identify popular candidates. The final decision-maker for what makes the official list should have written criteria, which may be provided to players if they are not especially gameable. (Everything is gameable, but we must weight that against the appearance of favoritism.)

The initial character screen design should keep in mind this intent to alter descriptions and add new classes. It should still look professional, and non-programmer design staff should be able to make updates. Document.

The intent is for updates and new classes to go live around the mid-point between substantial patches, or if patches are far apart, once initial post-patch activity has settled down. This gives players time to come up with new ideas and alter old ones in responses to changes in the game environment, without waiting until a new patch alters it again.

If there are questions over who originated a class, resolving that issue will take staff time. Ideally, a forum check and a character database query could answer the question. Explicit predetermined policies are important, this time for player recognition.

Player-made classes will be recognized. First, the in-game documentation will list the character and forum names of the originator(s), unless they wish to remain anonymous. Parallel or cooperative development can lead to multiple recognition. Again, standards will be needed to resolve questions of multiple claimants, with a “contributor” recognition option for those not the primary author/creator.

In-game recognition will follow. Whatever system of badges or titles exists will allow for special (and permanent) awards to individual characters. These will be purely decorative awards. The creator of a class will receive the honor of “Original X,” while substantial updates or contributions will merit a “X Trainer” honor.

Players creating the original classes in beta will receive the honor in-game within the first month that the game goes live, with a pre-announced award ceremony. Friends and media are invited. (These events would be a good test of GM tools for limiting abuses at in-game events.)

Explaining the recognition process to players should emphasize the possibility of parallel development. Several people will think of the same class around the same time; there are a finite number of possible starting options. Trying to recognize all contributors must be balanced against making that recognition trivial. Not everyone will agree on who should be recognized. List things that will be taken into account, such as writing good explanations on the beta forums and actually creating and playing a character to test the class. (Similar issues will arise from whether a new class is different enough from existing classes to merit inclusion on the creation screen.)

Initial classes will not be set before the manual goes to the printer, possibly not before the game goes gold. This will be noted in the manual. Before describing the skills, a section will say substantially the following:

Classes: [Game] has a flexible, open-ended skill system that puts you in charge of determining what your character can do. Design your own wizard or warrior, or pick a path entirely your own!

This freedom can be daunting. There is much to be learned here, and your first attempt at the hero of your dreams may not work out according to plan. We are here to help! When you go to select your initial skills, there will be several default class options, paths others have taken in making their characters. After reviewing their strengths and weakness, you can pick the one that suits you best and tweak it to perfection. If your hero is not there, you still have the freedom to select whatever skills you wish.

What are these classes? We don’t know! Instead of telling you what sort of hero you should be, we are asking players what they want to be. [Game]’s classes are player-designed, tested on [game world] itself. By the time you read this, we will have found the most popular and successful types of heroes on [game world], and those paths will be available at character creation. We expect the standard archetypes of wizard and warrior to appear, but players may find interesting and unintended options.

Maybe you will be the next to discover a new path to heroism. Your name could be in lights, with young apprentices setting out to emulate you. [Game] puts the options in your hands!

Whatever system exists to allow players to re-pick skills should let them re-pick a whole class set, including classes developed after the character was created. They follow the same rules for receiving the new class title as a newly created character. (Depending on the rest of the design, players could re-spec to “start over” and earn titles/badges/honors/whatever from multiple classes, or they might surrender existing class-based honors to earn new ones.)

Disadvantage: Credit

Anything that can go well can go badly if mishandled. Even with good handling, some situations will have no fully satisfactory outcomes, because of unreasonable and/or mutually exclusive demands.

Players have a sense of ownership in their ideas. Having those ideas included in the game can make someone a lifelong player. Feeling that those ideas have been stolen or twisted can make someone quit in a cloud of flaming drama.

The first opportunity is class selection. Some classes will be chosen, others will not. Some proposed new classes will be judged too similar to existing classes, or else not something we wish to include in the game. There will be long-term lobbying for some class to be added. When a new class is selected, there will be complaints from those who had similar ideas.

Once a class is selected, there will be disputes over who should get recognition. Expect multiple claimants for everything. This is the reason for pre-written guidelines: arbitrating claims. Someone will be left unhappy, either because he thinks he should have gotten (more) recognition, or because he objects to sharing recognition with (so many) others.

That hurdle past, there may be disputes over what is done with the idea. The creator may object to edits to the original write-up. Someone will demand that his name be taken off the class (“They’ve ruined it!”). Down the line, there will be balance changes, and those whose names are attached to classes may take them personally, with good reason. We really did nerf his class. Expect gloating and claims of favoritism along the same lines.

Opportunity: Flavor

This is a potential disadvantage that could be used to improve the game, so I call it an opportunity.

Viewing classes as packages of skills inherently divorces them from the game world. Wizards do not have a special place in the world or history; they are just people who know both life and death magic, with at least four points in elemental. They are generic boxes onto which anything can be grafted. Three options are proposed:

  1. Embrace it and give it to the players. Every player just gets a generic box of skills, and it is up to them to attach significance to it. We can provide tools to facilitate this, such as player-defined titles, guilds, and rankings. This is the sandbox option, where the King’s Knights and the Black Order of the Serpent have exactly the same stats but different tabards and RP elements.
  2. Embrace it and define it in-house. As before, but make the pre-define the options. A warrior may start as a member of the King’s Knights, the Black Order of the Serpent, or whatever other NPC groups are offered (or unaligned). While mechanically identical, each gets its own paragraph of flavor text, recommended development options to fulfill the group’s theme, and potentially a different starting NPC to send them on an introductory quest based on that group. (A system that connects characters to an NPC faction at creation is another design document entirely.)
  3. Define it in-house. Each class will be defined by developers as much as classes are in other games. The creators’ ideas may serve as a basis, but game- and story-specific flavor text will be laid on top of the previously generic mechanics. All warriors (or all of kingdom x) are squires, and squires are this sort of thing; this class combining life magic and poison skills is called the verdant serpent, and it is connected to this new story arc that we are introducing in the next patch, with this origin for the power source that ties these skills together. This is the most focused but limited, with a greater chance of alienating creators (see the previous Disadvantage section). It allows us to focus on a single thing, but restricts players to that single thing as well. This is good for the RPers who wish to act a part in the world, but others will just ignore it in favor of their own flavor (or just ignore all flavor text).

5 thoughts on “Design Document: Classes in a Skill-Based Game”

  1. I think the structure you outlined is pretty exciting, sounds a lot like somethign that could have been done to UO. Gaining merit by contributing to the community whith yu build sounds good to me as well. And then again it would require the DEVs to be on their toes 24/7 basically because you either let all that develop up to the point wehre everyone and their grandma play cookie cutter build x, because it is jsut that good or you have to change skills and synergies between them a lot more often, something which would require a lot of balancing work, always a touchy matter and potentially anger your player base if the respec system isnt flexible enough.

    But overall I can see such a system go far, when done with all these pros and cons in mind.

  2. To avoid favoritism you can simply allow the players to use a very easy to build tool to pre-construct and submit template builds to a community voting management tool which allowed players themselves to directly pick out the templates they like. Not only that, you can show how many players are actually using each template IN GAME, say in percentages, to show exactly how popular each type is. This also prevents the “I did it first” problem entirely by not allowing the same template to be submitted twice while allowing minor variations to occur (and be recognized if they’re popular).

    Hell, you wouldn’t even have to worry about building in community chosen templates if you hooked that database up to the character creation tool to allow players the opportunity to browse ALL of the custom options players have done before them (with the most widely used ones at the top). If your game is balanced properly you will likely see a flavor of the week appear, which quickly gets supplanted as players figure out what template types can beat THAT character, in an endless cycle of 1-uping. If you see a certain template begin to dominate, then you can simply adjust skills or equipment appropriately to make sure it doesn’t become the defacto setup. This also frees up all the dev/community manager time that would have had to be spent capturing new data, comparing posts, examining for “popular” status, etc.

    Guild Wars is a pretty good example of a game that has a pretty decently balanced “free-for-all” skill system (although limited in some aspects) and definitely has flavor of the week syndrome.

  3. Zubon, I’m still working through this, but I think your analysis in the “Problem” section is flawed. Games like WoW and Diablo feature the same problem, as they allow for (semi-permanent) class customization.

    I suggest that Context and Problem be rewritten along these lines:

    Context: To increase player investment, all MMOs allow customization of their avatar. Most allow for customization of the avatar’s abilities, as opposed to strictly aesthetic customization.

    Problem: Some combination of abilities (builds) are more optimal than others. This leads to… (all subsequent problems you’re referring to).

    This, to me, seems like the core of the problem. The game allow players to customize their characters’ abilities. There are two motivations for the player to do this: one, to make their avatar unique, to set themselves apart from others; two, to cause their character to be superior to other players’ characters. Yet this same imbalance cause all manners of playability problems.

    I’ll be good now and read the rest of your post before commenting further.

  4. You should submit this at gameDev in the Game Design forum. You’ll get plenty of good constructive feedback.

  5. Ignoring some of its other problems, both design-wise and company-wise, the concept behind Fury’s character creation is great. Skill based character creation where nothing is permanent. You can rebuild your character at any time you aren’t in a war zone. You can save that build (Incarnation) and build another one. You can switch between them, mix and match, etc.

    I’m no longer there, but the game is still going. It free to download & free to play. Check it out at if just to see how the incarnation system works. My friend Cameron has been doing a great job on the game with regard to making hamburgers from some old sacred cows left over from the previous regime.

    Joseph B. Hewitt IV
    Former Lead Content Designer on Fury @ Auran Games
    Lead Designer @ Interzone

Comments are closed.