Storms on Cloud 9 #23:
Case for Simplicity?
by Scott Holliday
Following my previous article, I got a lot of great comments both here on Skotos and over on Slashdot. I had already planned for this follow-up article, so I didn't respond. Most of the discussion seemed to revolve around the definition of complexity as opposed to depth. Certainly, the meanings of all of these words aren't as simple as I hoped. Regardless, one especially profound comment stuck in my head, paraphrased, "MMORPGs aren't too complex, they're too simple!"
Of course, I agree, and this is the crux of the complexity problem. From a programmer's standpoint, it's downright easy to produce an online mathematical design. Number crunching is what computers do best. In the time it takes you to read and consider a set of numbers, the computer could have already performed more calculations than you can count. Any amount of exact values you can get your brain around, the computer won't even sneeze at. So, the designer's natural desire is to bring all that power to bear. Why not? More processing power means better graphics and sound for the client, as well as better AI and environmental tracking for the server. In contrast, this has nothing to do with complexity of game-play.
The same issue could be applied to the table-top game, which might help shed some light on the issue. Depending on your game system, you might need a degree in mathematics in order to build and control your character well enough to do them justice. The first warning sign is if other players are doing calculations at home to find "the best" combinations. In this case, there is no computer involved, but the game can easily be just as complex to play! Which means that complexity in design does not require a computer. In fact, from some of the washed-up tabletop game systems I've seen, complexity does not even require an intelligent design.
Yet, last time, I determined that players aren't as likely to pay to play a game that is too simple. But what makes a game too simple? In the case of RPGs, this is usually a question of semantics. Complexity in RPGs often refers to the choices available and the depth of resolution based on those choices. A common complaint about skill-based systems is that often the players all end up with very similar characters. In contrast, a common complaint with class-based systems is that there aren't enough choices. A common complaint in systems with many outlined actions is that those who know the system better are more likely to excel (regardless of their character's strengths). But, systems with fewer actions available ("I attack", "I dodge", "I attack", "I dodge") give no form of character control or expression.
So where is complexity good and where is it bad? Or, more aptly phrased, how much complexity is fun? Obviously, the maximum amount of complexity that a player will put up with will vary from player to player. However, the point here isn't to look at the limit, but at where game-play complexity improves the overall experience.
Perhaps the best summation is a simple question: "If you were magically transported to a fantasy realm, what skills would you expect to need?" Simple question. But then why is success in a fantasy game determined by your skill (and tenacity) at number crunching? When you go to play soccer do you take a calculator? When did the words 'Role-Playing Game' become synonymous with 'Fun with Numbers?' Do you honestly think "your elf" thinks about percentage of ability increases? Then why do you?
So far, so good. But there is a caveat. Players want to make choices, and they want to be informed about the result. A game without choices isn't much of a game. And without information about your choice, you might as well pick at random. So what is the simplest way to give weight to a player's decisions? Quantifiable results. Do you see the hole I just dug for myself? Choices lead to consequences, consequences lead to quantifiable results, so unnecessary complexity in game-play is a direct result of the reward system?
So I guess my next article will be about managing the reward system...
[ < #22: A Case for Complexity? | #24: Challenge and Reward > ]