Among other projects, I've been designing a MMORPG. In the process, several ideas I once held about how MMOGs should be designed have been upset -- it's been a great learning experience. (Not that it's over yet; I still have a lot to learn.)
One of those ideas was that it's relatively simple to have a playable game world based purely on skills -- no classes. That's how my original design looked; I'd create a bunch of cool skills and then dream up a lot of things that players could do to use those skills. And then -- because I had to -- I started asking myself: how do I decide what content to add? How do I key features to character abilities?
If individual skills didn't interact much, I could dream up individual bits of content (which I loosely define as "things to experience") associated with each skill. Each content nugget could be designed in a near-vacuum, keeping the process simple enough to be manageable.
But in building a game world where players will group several skills together to try to achieve some gameplay goal, there wind up being so many ways that different skills can overlap and interact that I found myself hitting a combinatorial overload wall. Maybe it's just me; maybe I'm simply not sharp enough to figure out how to design content in a massively multiplayer game with 50+ completely independent skills. Or is it just really hard, period?
Either way, I wound up creating a set of "careers," and building content keyed to those careers instead of to individual skills. (That doesn't mean there's no other "content," just that the breadth of the gameplay-specific activities got condensed.)
By doing this, I reduced 50+ modes of play to 16. Sixteen different brands of "things to experience" is still complex, but it's comprehensible by mere mortals.
The point to all this is that I wound up designing a game with a form of classes even though my original intention was to create a totally skill-based game. The process of trying to construct my own game offered insights into why MMORPGs tend to look the way they do that I might not have gotten otherwise.
Which leaves me a little less ready to verbally hammer professional MMORPG developers for not designing the pure skill-based game I prefer. It might be possible, but I think I can see now that it's harder than I thought.
I wish someone would write a "design your own online game!" game.
Side note: Some of this discussion reminds me of the old CISC vs. RISC wars.
CISC microprocessors like my old friend the Motorola 6809 were said to be highly "orthogonal" -- they had only a relatively small number of instructions, but each one of those instructions had some function that was completely unlike the function of any other instruction. Usually each instruction had a lot of addressing modes (ways to operate on data). This made each instruction very powerful, but at the cost of being hard to design efficiently in hardware.
The RISC philosophy was to give each instruction/mode combination its own instruction. Each instruction would thus be relatively simple to build in hardware. The downside was that there sprouted a profusion of instructions, each subtly different. Writing an optimizing compiler for a RISC chip was thus hairier than for a CISC chip because the compiler had to have a lot more intelligence about which combinations of umpty-odd instructions were most efficient.
Like models, no analogy is perfect. But also like models, a good analogy can still be useful.
So is a class-based system like a CISC processor while a skills system is like a RISC chip? And if so, is there some insight we can glean about classes vs. skills from the CISC vs. RISC comparison?
Or is the fundamental difference between class systems and skill systems not really about complexity, but something else?
