Shape of a Mechanic

I wanted to talk about a concept I’ve recently hit upon that I’m calling a mechanic’s “shape”. To do that I have to introduce a few prerequisite concepts, but first, a caveat. I don’t believe in a grand unified theory of game design. Instead, I take a view that’s closer described as “there are many facets to truth.” So, when I say that I need to define what I mean by mechanic in the first place, I’m not claiming to have a perfect, complete, or final definition of the term. I can only bring up the parts that are currently on my mind here.

To me, a game mechanic is a rule, strategy, behavior, or convention that governs some sort of activity or sub-activity in a game. It has a domain that it applies to—where it fits in the entire system of mechanics. A simple mechanic might be “when you hit someone with a weapon, you roll that weapon’s damage dice and inflict that many hit points of damage.” The mechanic tells you what its domain is or the activity that it applies to—in this case, hitting someone with a weapon. It also tells you what to do when that thing happens—roll damage and reduce hit points.

Okay. So that’s what I mean when I say a mechanic. When I say that any given mechanic has a “shape”, I mean that the nature of the mechanic and the domain of the mechanic combine to form a feeling that happens when the mechanic is invoked. In our previous example, weapons could just as easily use a static value instead of rolling dice and the “function” would be basically the same. But the shape is very different.

Some might argue that these would be different mechanics for the same domain, and there’s a bit of truth to that. But in my mind, they’re just alternatives that fill the same hole in a system but with differently shaped pieces. One way emphasizes the resolution of the task as a point of interest, whereas the other emphasizes maintaining the flow of the combat. A third way might do something else entirely. Any way is fine but the specific choice is meaningful.

Here’s another example: percentile based skill systems versus skill point systems. Both are skill systems, and in practice, they both operate pretty much the same. But they have different shapes. Percentile systems tend to favor an “anything is possible” approach to skill checks. They treat the difficulty of a task as more about the character than the circumstances. Skill point systems tend to favor a view of externalized difficulty levels, with the difficulty of the task being more about the factors of the situation than the person.

Neither view is especially right. In d20, where you want to make certain things impossible to certain people for reasons of class differentiation, skill points are the right way to go. In Eclipse Phase, where it’s entirely setting appropriate to download a new emotion, it really is all about the character. In game design, we’re looking not just for what to mechanize—the “function” of the mechanic—but also the “shape” of how to mechanize it. I’ve learned that I personally have biases in how I view specific shapes. I dislike systems that create derived values from some sum of other characteristics—such as DVs from Exalted or bonus-to-hit in D&D. However, I like spending points of any kind—action points, plot points, whatever.

Regardless of my personal biases though, some shapes work well for specific functions, and others don’t. Recognizing whether a particular shape suits both my personal bias and fits the feel of the game can be challenging. It seems like one gets better at this over time, but recognizing that I can introspect my thoughts to determine what I like and also to build up a catalog of shapes in my head that evoke given feelings is a small breakthrough for me. And I’m keen to know: what sorts of shapes do you all naturally prefer?