Optimal Number of classes?

[TwoSix]

Somewhere between 6-12, each with 2-4 high-level cascading options (in the sense that making that choice is a strong determiner as to how the class plays). Within the high-level option, between 2-5 options at various level break points.

Why? Because that's how successful RPGs do it.

WoW: 10 classes, with 3 subclasses in each class.

SWTOR: 8 classes, 2 subclasses in each, 2.5 build options in each subclass (2 unique, 1 shared between subclasses).

Pathfinder: 11 core classes, each with multiple subclasses (called archetypes).

4e Essentials: 10 current classes, most with multiple subclasses.

 

[RandomCitizenX]

I kept the initial question broad because I wanted a wide range of opinions in the hopes of furthering the discussion and refining my own ideas. Obviously there is no concrete answer beyond each person's preferences. Personally I always found it odd to have very specific archetypes along side the much more broad classes like fighter, wizard, and cleric. Assuming a deep multiclass system what makes the paladin warrant its own class instead of making a fighter/cleric? I think that in D&D (and therefore Pathfinder) it exists today as a legacy item from before certain rules concepts were in the game, but what does it bring to the table that justifies it's independence?

Imho, it's impossible to give a concrete optimal number of classes without defining what constitutes a class. Is a class just a bundle of 'powers' and 'abilities' or does it also qualify as an (adventurer) archetype? Does the system allow for multi-classing or are there additional elements that are used to shape a character (e.g. backgrounds, feats, themes, etc.)?

The answers to these and similar questions will affect what would be an optimal number of classes.

I didn't define class for the reason I gave above, but for my purposes a class is currently a broad archetype that provides thematic abilities relating to combat and adventure appropriate to that archetype with the possibility to multiclass existing alongside other layers of character customization including a social class/skill archetype, race, and something comparable to feats.

 

[Jhaelen]

I didn't define class for the reason I gave above, but for my purposes a class is currently a broad archetype that provides thematic abilities relating to combat and adventure appropriate to that archetype with the possibility to multiclass existing alongside other layers of character customization including a social class/skill archetype, race, and something comparable to feats.

In that case, imho, the number of classes should be kept quite low. Basically, I'd set up classes to have different degrees of combat aptitude (possibly split between melee and ranged) combined with a focus on zero to two areas of typical 'skill sets' (e.g. social, exploration, lore, ...) that are relevant for the setting and typical type of adventures.

I'd say anything from 3 to 9 classes should be sufficient, depending on how broad the archetypes should be and how customizable skill sets are.

What mostly influences the final number of classes is what you consider relevant skill sets. E.g. are combat aptitude and spellcasting abilities (assuming the system/setting includes something similar to magic, psionics, etc.) also just skill sets or do they use a different subsystem.

Finally, I'd consider the targeted typical group size and composition: It should be possible for a party to cover every relevant skill set with at least moderate expertise and I'd like to offer players at least two class choices with moderate or better expertise in a given area.

 

[AeroDm]

In my opinion, the optimal minimum number of classes is equal to the number of significantly different mechanics you want your classes to have. It's in the idea of significance that you'll arrive at a more granular or less granular system.

Using 4E as an example:

Basically, there are two broad mechanics: weapon attacks and implement attacks. Is it excessive (ie, non-optimally minimal) for there to be a Ranger and a Fighter when both are basically weapon-users? Is there really a difference between the Invoker and the Wizard?

You can make the classes less granular by introducing more mechanical categories. Classes are broken down by combat role and each has a generally unifying mechanical theme. Psionics uses power points. Essentials has alternate leveling schemes. So on and so forth.

You can turn the dial to naught and say that classes are restrictive and we'll have a non-class system. You can also turn the dial to eleven and say that any character concept should be its own class and have its mechanic. Neither is qualitatively wrong, it's all a matter of preference.

Now personally, I feel there's only a few basic categories: melee/ranged, offense/defense/support, maybe combat/non-combat. So my optimal minimum is somewhere between 6 and 12. Again, those are the categories I find significant, and definitely opinion.

But you still need mechanisms to flesh out those various roles. If you decide that both Fighter and Ranger are "weapon users," you still need some way to differentiate the Ranger's feel from the Fighter's feel. So you are mostly transferring the complexity from the class rule-device into a different rule-device. There is nothing inherently wrong with that, but it needs to be addressed or else you have to just declare that archetypes are achieved through RP instead of the rules.

 

[Crazy Jerome]

I'm divided on this question.

1. Part of me wants a tight, relatively small (4-12) set of mechanically distinct classes. And by that, I mean really distinct. If you fight with weapons, you have some fighter levels. Or if you want to be closer to 12 than 4 classes, you might divide that into "fighter" for melee weapons and "archer" for ranged. And once you've divided the relevant mechanical bits among your classes, that's it. No more classes, ever.

Then, since those aren't archetypes, let alone viable characters, and I agree that D&D needs those, I think you need the archetypes defined separately. Here, you can define a few of the more common combinations, with suggested ways to realize them.

All the mechanic interaction is through the classes or other mechanical elements, though. Archetypes are just ways to put the mechanics together and attach flavor to it, to simplify play and getting started.

I'm not that picky about what you call "class" or "archetype" in such a system, though I will note that what I've called "class" above is mechanically broad enough to not be subsumed into skills. I want more than 12 skills in a skill-based system. I did rather like the DragonQuest take on this, BTW. It's a shame that WotC sits on the DQ IP and will never let it out.

2. But back to the divide. Part of me also recognizes that once you dilute "class" that strongly, you might be better off writing a different system.

 

[LightPhoenix]

But you still need mechanisms to flesh out those various roles. If you decide that both Fighter and Ranger are "weapon users," you still need some way to differentiate the Ranger's feel from the Fighter's feel.

Alternatively, one of the classes is not truly necessary. If you have to force mechanics to differentiate archetypes you're trying to model, perhaps it's better to let fluff speak for itself.

To put it more bluntly, a ranger could easily be just a Fighter with fluff.

 

[Calzone]

How many classes do you want? Well, first answer the question, "What do you need classes for?"

There seems to be two main reasons popping up for classes: mechanical and flavor differentiation. Either you need/want 'n' discrete mechanics for conflict resolution, or you want 'k' discrete archetypes for character portrayal. Obviously in most game systems there is overlap between these two motivations, ie. a given class will have some resolution mechanic and some archetypical character portrayal.

• The story requires, at a minimum, that there be 'k' classes to accurately portray all characters in the narrative.

• The game itself requires that there be 'n' sets of conflict resolution mechanics in order to ... ? (I'm having trouble with this one. Perhaps to ensure player engagement in the game?)

Assuming the above is correct, the minimum number of classes is somewhere in the range

maximum(n,k) <= number of classes <= (n x k)