Simplicity's Sake

Hmmm. According to my stats, I've lost three followers in the past few days. Guys, what did you think this site was about? What have I not been doing that you wanted me to do? Don't come crying to me when you miss out on all the perks of my quest for global domination. But I guess I should get back to practical game design...

I'm reading the Steve Jobs biography lately. It's the giant white book with the big picture of Steve Jobs on the cover, so you can't miss it. One of the things that obsessed Jobs was simplicity. It was one of the three guiding principles in the original foundational document for Apple. Simple is better. Jobs didn't like software that required too many clicks. He didn't like on-off switches; that's why iPhones have only one button to power up, and the slider bar at the bottom of the screen to unlock the phone. The whole process of using the device had to be intuitive and simple to understand.

Remember that. Simple is better.

But simplicity isn't easy to design. In fact, Apple made hundreds of foam models of the iPhone. Simplicity takes a lot of work. It's a process of stripping away all the non-essential elements from the design. We should do the same thing.

Back in the day, there was a game called Middle Earth Role Playing (MERP). This game had a super-detailed combat system. There was a massive chart for fumbles. And one for critical hits. And hit location. I tried this game exactly once, when I was in high school. A simple fight with four orcs took all night. There was no roleplaying. We never played the game again.

I've never played Aftermath, but I hear that the combat system was a nightmare as well. Trajectory. Hit location. Ammo types.

There are all kinds of places to put complexity. Character creation. Combat. Skill systems. And there are some people who like their games super-complex and "realistic." Hey, that's cool. But I think that a game is better served by simplicity.

The reader should be able to understand the game quickly. The concept should be easy to understand (who do you play, what do you do?). The mechanics should be both consistent and quickly understood. How do I hit a monster in D&D? You roll 1d20, add any bonuses, subtract any penalties, and beat a target number. Simple. Elegant.

Back in the day, the game took speed factor into account. This was supposed to measure the relative speed of the weapon based on it's size and mass. No one I know ever used this rule. Similarly, in 1st edition AD&D, no one used psionics because the system was unwieldy and worked completely different from the rest of the rules. Designers chucked these rules for simplicity's sake.

John Wick (Hi, John!) recently complained about the exisence of falling damage rules in RPGs, and he's exactly right (up to a point). If you have to pull out a Texas Instruments graphic calculator to figure something out, you've bogged down play, and likely confused the gamer. You've pulled them out of the experience, whether that's the roleplaying experience or the game playing experience (those things aren't the same). I don't agree with him, however, that those rules aren't necessary at all. The wizard's fireball blasts me off the top of the ruins, but the spell wasn't enough to kill me; how much damage do I take? The rules are necessary. But they should be simple and elegant.

If you're going to include complexity (called "crunchiness" among gamers), then make sure you understand why you're including it. And still try to avoid making the rules too complex. Even if your market really, really wants to drill down to the nitty gritty of hacking, as a certain point you're only going to be catering to five guys. Even they don't want to be pulled out of the experience of playing the game.

One example from my own experience comes from the Coda System. We had a debate in the office about whether or not to include a saving throw mechanic. This, for those of you not in the know, is a general "save yourself from danger" roll, for jumping out of the way of falling boulders or surviving the bite of a poisonous snake. These things don't come up often in a game, and they could easily be handled as some kind of attribute test. In fact, that's the approach some argued for. It was simple.

I argued the opposite, that it needed just a bit of complexity. Saving throws are a "second tier" attribute. They give you something else to modify through the rules. "Gain +2 to your saving throw, in X situation." Or you could improve saving throws separately through leveling. In other words, if you tied the saving throw directly to an attribute, that statistic would only change if you changed the attribute somehow. Even better if your saving throw were somehow tied to your attributes, so a person with low constitution would have a lower saving throw. I ended up winning the debate. Yes, I added a touch of crunchiness to the rules, but they remained simple and elegant.

As I said, this can take a lot of work. You have to do a lot of design work. Maybe because you have to write a rule several times in order find it's best expression, or strip it down to its salient feature. Maybe because one rule doesn't fit with the rest of the rules. It's a matter of taste and intuition.

Remember, however, that simple is best.