December 22, 2010

Designing From Top to Bottom

A common complaint I see when comparing one system with another is disassociated mechanics. Basically the mechanics do not emulate the players’ idea of the story. This is a load of bull.

ALL mechanics in RPGs are disassociated from their actual action. Casting a spell in universe is nothing like pointing to a block of text in a book and picking a target or two. Hacking a computer in game universe is not anything like rolling a pile of dice and hoping for enough high rolls. Swinging a sword in universe has nothing to do with rolling a die and praying for a high roll. Fortunately, or unfortunately, all of these mechanics are disassociated from their actual action in universe because we, the players and GMs, cannot do these things in real life with the same skill or speed our characters can manage. So we abstract them as dice rolls in an attempt to roll the characters’ skill, luck, environmental concerns, and other factors into a single easy to calculate system. Until you’re calculating attack damage with physics equations, you’re using disassociated mechanics.

That long winded explanation out of the way, I finally managed to figure out what people mean when they ask to remove dissociative mechanics. What these players are asking for aren’t mechanics related to the action involved (Really, would you want to cast a literal magic missile every time you wanted to use the spell in Dungeons & Dragons?), they’re asking for top down game design.

For those new to game design theory as a whole, and maybe even to games, top-down game design is when you take a concept, let’s say a wizard, and design all of the mechanics to support that mental image. A good example in games is Magic the Gathering’s Sleep card. Another example is pretty much all of the OGL rules for Dungeons & Dragons and the new Essentials classes for 4th Edition.

Top-down design has some major traps, primarily in the balance category. Back to my Dungeons and Dragons example, wizards in the OGL were just better, because that’s what the designers, and even some players, expected. Other times, it’s making options not powerful enough due to that flavor you’re aiming for.

The direct opposite of top-down game design is bottom-up design. In this case, you create a set of mechanics, and then add the flavor afterwards. Dungeons and Dragons 4th Edition’s core classes all use mostly bottom-up design: solid rules that are given tenuous flavor that is simple to rearrange or ignore all together.

The traps in top-down design come in when things become far too homogenized, and therefore boring. When all options are literally the same, there are no interesting decisions left to be made. Beyond this, a number of players don’t like the feeling that the mechanics don’t actual mean anything and can be redefined at will.

As player, I much prefer bottom-up game design as it lets my imagination spin as fast as possible and lets me do things that top-down design often says are impossible. Really, no mechanics are so well defined as to be impossible to change the definitions to suit your taste, but many players and Game Masters have trouble making that leap from one set of descriptors to another.

As a designer, I do a little of both. Behind the scenes in ExoSquad I have a long list of ‘equal’ abilities that can be mixed and matched into the various weapon abilities, but the ones I choose for each weapon are based on a top-down analysis of the abilities and what I’m trying to emulate. Velocity’s pre-alpha rules, on the other hand, are purely bottom-up and are incredibly flexible as mechanics go.

My question for the comments is this: which style of design do you prefer, and why? If you’re a designer, let me know in the comments, and explain what challenges you’ve experience on either design ethos!


  1. I don't think I'm a huge fan of the terms "top-down" and "bottom-up" design. I think, really, it's a matter of fluff first or crunch first.

    In virtually all of my systems, I design crunch first. Now, this might sound misleading, as I typically create the fluff before I create the system, but - to me - a beautiful system can better streamline the fluff.

    Let's look at your comparison of fluff-first 3rd edition versus crunch-first 4th edition.

    The inherent issue with the fluff-first 3rd edition wizard was that an entire subsystem had to be developed for that character. Then that subsystem had to be balanced against the subsystems of other characters. Each class has its own unique mechanics, which makes balance very difficult. But the mechanics were developed based on the fluff.

    Fourth edition, however, looks to have been made via a system, then the fluff added on top of it. Now, honestly, most people will have no problem installing their own roleplaying and imagery on top of the same over-arching system. Sure, my ice storm spell might be the same as the ranger's volley of arrows, but they're flavored very differently. It definitely cuts down on the unique feel of the classes (or makes it better, since I can now flavor my ranger to be a mage!), but if you're looking at it from a roleplaying standpoint, it helps alleviate the system as a distraction for the players.

    Which one's better? It's admittedly hard to say. I do believe that fluff should play a major part in the crunch, but the crunch should be fun in-and-of-itself. And sometimes (if you're like me) you'll create some awesome systems that just deserve some lore written to accompany them. And then, voila, you have a game.

  2. Alan: I definitely understand the dislike of the terms, I actually only use them because a few other designers set a precedent of it. Mark Rosewater actually has a spectacular article about it. Your definitions hit the nail on the head. I also completely agree with your analysis of 3rd and 4th Edition.

    Those systems that start as mechanic games and become very flavor oriented are probably my favorite, as they do accept reskinning of their terms without much trouble, but are still mechanically interesting even if you ignore the flavor completely.

  3. Yes, there are, which is why I broached the subject. And welcome to the blog, labatterie.