Exaggeration

One of the things I like most about working at Klei (and not to be a douche, but that is a pretty long list) is working with some incredibly talented animators. All of our animators come from cartooning, and the perspective they bring is something I find consistently interesting and refreshing. It has had the side effect of turning me into a horrible animation snob and I find myself noticing poor run cycles and ugly poses where before it just would have been unremarkable (not unlike when I started noticing poorly designed doors everywhere after reading The Design of Everyday Things). I'm sure I'll manage somehow.

I've been getting our team together for informal lunchtime talks every couple of weeks. It started with me talking about MDA & Amnesia, and has broadened from there. A few weeks ago, one of our animators talked about the 12 Basic Principles of Animation. They're basically the canonical guidelines for animation, derived from 50 years of work from leading animators at Disney and elsewhere. While I was aware of them before, hearing our animator explain them and then seeing how they're applied in the animation in our games was quite illuminating.

Interestingly, with a slightly different perspective, some of those same principles can apply to design. I may talk about more of them in the future, but today we'll focus on Exaggeration. In the context of animation, it means magnifying characteristics while still remaining connected to reality. Animation that tries to perfectly replicate life ends up dull at best, and often downright disturbing (e.g. creepy Tom Hanks in The Polar Express or all those mocap animated features that somehow think they'll be the ones to beat The Uncanny Valley). There's also a more general lesson in here for the drab and uninspired conclusion that awaits the legion of grey-brown manshoots that hold "realism above all else" as their holy grail.

In the context of design, what does exaggeration mean? It means providing clarity in individual mechanics and contrast between mechanics in aggregate. The role (purpose) of a mechanic is clear. Obviously from the player's perspective there may be experimentation, discovery, etc. But from a design perspective, what purpose a mechanic serves should be clear and should be distinct from other mechanics.

To illustrate, Klei's founder and I were having a discussion about the weaponry in Assassin's Creed: Brotherhood. There are a half-dozen different kinds of melee weapons in AC: B- longswords, greatswords, daggers, axes, spears and hammers/maces. The differences between these categories of weapons are clear and immediate. Different sets of animations, different timings; basically, they feel distinct. They are well exaggerated.

But in any individual category of weapon, each weapon has three properties (damage, speed and deflect) rated from 1-5 in each. One kind of axe may have damage 3, speed 2 and deflect 2 while another has damage 4, speed 1 and deflect 3. The distinction between individual weapons is not exaggerated. Aside from saying "it has more," I imagine the vast majority of AC: B players could not explain the difference between a sword with a deflect rating of three and one with four. It's not even clear if the ratings are relative to that category of weapon (i.e. does damage 4 mean something different for a sword vs. damage 4 on a spear?).

And the further complication is most people want to play optimally. If I get a new weapon that looks interesting, but its ratings are poorer than the weapon I've been using, I'm disinclined to try the new thing I got. At the very least, I know I'm making a decision that is an intentional handicap. The player's desire to express themselves (through selecting how they appear) is now at odds with playing the game "well."

Our founder's contention was that having these properties allow the developers to add more content without needing anything more than a new weapon model (quite cheap) and a new line in a spreadsheet somewhere. While I understand the purpose of this quantification is to give a sense of progress, I said AC:B would probably be better served by finding another way to accomplish that goal.

In a Diablo-esque game (or most RPGs, really), where the game is fundamentally about equipment and the stat differences between different pieces of gear, this kind of granularity is well suited. But Assassin's Creed isn't about that. It's about Ezio and what he can do. The fluidity of his movement, his ability to parry and counter, to outmaneuver his opponents. The game isn't strongest when the player is asked to make micro comparisons between different pieces of gear.

The ability to recruit and dispatch apprentice assassins fits well. It makes Ezio feel like a leader and provides the sense of being connected to a larger group of people. Pushing more of the progress into that system and leaving the weapon selection well exaggerated and more open to player expression would probably suit the game better.

Jamie Griesemer gave a talk about this at GDC '10, in the context of the sniper rifle in the Halo series. He's been posting it piecemeal on his blog and it's a very good, in-depth look at the topic of role and contrast in designing mechanics.

This is a relatively minor quibble in the context of Assassin's Creed, but it's been far more impairing in other games. Especially since the designers understand what the distinctions between different features are, they're likely to see the contrast as being larger than the players will. It's vital to be mindful of this. How something feels is usually far more important that what the differences might be under the hood. Ensuring those two things are in alignment will result in a clearer design and ultimately, a game that better realizes its intentions.