Does the MDA Framework Apply to Tabletop RPGs?
Does the MDA Framework Apply to Tabletop RPGs?
No, it doesn’t. I’d argue it doesn’t even apply to videogames.
Mechanics, Dynamics, and Aesthetics is a self-professed formalist approach, a “framework,” to games created by Robin Hunicke, Marc LeBlanc, and Robert Zubek, three videogame developers; Zubek also teaches game design at Northwestern. Since its publication in 2004, MDA has been quite influential—4220 citations on Google Scholar as an easy statistic, at time of writing.
MDA, notably, has the same quirk that many game studies articles written by developers do: it’s very interested in practical problems. That is, MDA is extremely focused on addressing problems that appear in [video]game development rather than making more theoretical or philosophical claims about what games are or do. To me—granted, as someone who has never worked at a professional game development studio—it scans as a bit desperate, a bit cloying. It feels like the article appeals to theory in at attempt convince some producer breathing down the designers’ necks. Which is important! From the stories my friends in AAA tell, directors and producers often lose sight of what makes a game fun in pursuit of some grand vision.
While I can certainly appreciate game studies as a tool for fending off overbearing producers, I don’t think that makes MDA any more correct, nor do I think it justifies the acclaim the article has received over the years. If it can convince your producer to agree with you, godspeed, but I don’t think that means it must be right.
To begin with, MDA makes a pretty bold claim, one that’s baked in to its assumptions: that games are artifacts. That is, that games are a good, an object, something that can be created and consumed. The designer creates the game, and the player consumes it.
This is… wrong. It’s wrong on an academic level, and I think it’s also wrong if you just look at games we play as people.
There are basically two arguments in [academic] game studies about what a game is: that a game is an activity (held up by the likes of Abt (1970), Avedon & Sutton-Smith (1971), and Suits (1978)), something you do and actively engage in; or that a game is a system (from Crawford (1984), Costikyan (2002), and Tekinbas & Zimmerman (2004)), a set of rules and regulations that interact with each other. I happen to favor the former over the latter—a game doesn’t exist until it’s played—but I think there are strong arguments for both. Note that neither of these are an artifact or product: yes, you can charge people an entrance fee to play a game (paintball), and yes, you can sell a book with the rules written down (charades), but in neither case is the game actually contained in the thing being sold. I can play paintball for free if my friends bring their own guns; I can memorize the rules of charades and play them without the book.
This game-as-artifact argument also really starts to break down in the context of folk games: soccer is not an artifact. You use artifacts to play soccer (a ball, a net) but soccer itself is not actually any single object. I cannot put “soccer”—whether as a played experience or as a system of rules—as a complete thing into a box.
What about videogames? You download a game off of Steam, surely that’s a game, right? Right? No, I don’t think so. Yes, you download a bunch of code, 3D models, audio files, and other stuff, but those aren’t the game. How can you tell? Because you can play multiple games with the same piece of software. This is exceptionally obvious with something like Minecraft, but consider a narrower example, like Dark Souls. I can play Dark Souls in a lot of different ways: I can just try to get to the next area, defeat the bosses, and see the credits; I can speedrun, to try to see those same credits as fast as possible; I can do an SL1 build, where I never level up and impose extra challenges on myself; I can do a low-level PvP gank build, where I don’t actually care about seeing the credits but instead try to murder a lot of helpless players and skyrocket my Darkwraith rankings. Each of these activities, each of these systems, uses Dark Souls-the-software, but each follows different rules—the “intended” rules, the rules of a speedrun, the SL1 restriction, and so on. The game is the goal you set for yourself and the means by which you achieve it; Dark Souls is simply the software you use to do it.
You can do this with any game. I can play soccer, sure, but I also could use that ball and try to kick it as high as I can, and the winner is whoever kicks it the highest. I still need the soccer ball—much as a speedrunner still needs Dark Souls—but the game being played is fundamentally different. In the words of Stephanie Boluk & Patrick Lemieux’s excellent book Metagaming: “There is no cheating in Super Mario Bros.” I can cheat at a speedrun and I can cheat at soccer, but I cannot cheat a soccer ball and I cannot cheat software. This is, I think, where a clear distinction between”mechanics” and “rules” emerges (particularly when remembering that really we should be calling mechanics mechanisms): a mechanism is a physical property of an object, like a ball’s bounciness or a videogame’s health bar; a rule is restriction or other condition agreed to by players, like foul lines or going snipers-only. You can cheat at rules, but not mechanics; you play games with objects that possess mechanics, but it is the agreed-upon rules that define how we use those mechanics, and thus what the game itself is.
Okay, so, MDA thinks that games are artifacts, and I don’t. So what? What if we just pretend they didn’t say that, and move forward with the rest of the framework?
Next, they discuss the three components of games: rules, system, and “fun;” followed by their “design counterparts” of mechanics, dynamics, and aesthetics. Here’s their diagram:
Diagram of game components, per MDA
The article immediately elaborates on those three terms:
Mechanics describes the particular components of the game, at the level of data representation and algorithms.
Dynamics describes the run-time behavior of the mechanics acting on player inputs and each others’ outputs over time.
Aesthetics describes the desirable emotional responses evoked in the player, when she interacts with the game system.
As MDA describes it, designers create the mechanics of the game, which determine the possible dynamics of the game, which creates the aesthetic experience of the player. On some level, this makes sense: designer makes game, player plays game, that play informs how player feels. Nice. Tight. Simple.
Except that this doesn’t make any sense at all! A game is not the thing the designer makes, a game is the thing that the player decides to play.
Here’s an example to illustrate: imagine I boot up The Last of Us and then spend the next twelve hours jumping up and down in a corner. My friend does the same thing on the TV next to me, and we take studious notes to see who can jump more times in this twelve-hour marathon: whoever jumps the most times wins. Let’s call this game Jumpy Jumpy Joel.
Now think about playing The Last of Us the “normal” way: the long journey from coast to coast, the fights and dangers along the way, the friends and foes met, the difficult decisions made, and the eventual goal of the player to reach the ending. Let’s call this Joel & Ellie’s Big Sad Adventure.
Both of these are games: they have a goal, they have constraints. Both of them use The Last of Us as an important game piece. The difference is that Joel & Ellie’s Big Sad Adventure is the game that Naughty Dog “intended” to be played using The Last of Us, while Jumpy Jumpy Joel is a game that my friend and I made up together.
This is where the primary building block of MDA, mechanics, starts to break down. The article describes mechanics twice. The first is above—components of the game as data and algorithms (also like, oh my god, you can’t define a component of a game as component again?? huh??)—but the second a page later. Here’s what it says:
Mechanics are the various actions, behaviors and control mechanisms afforded to the player within a game context. Together with the game’s content (levels, assets and so on) the mechanics support overall gameplay dynamics.
So on the one hand, we have mechanics as the components of the game, the data and algorithms. To me, that sounds like software: it sounds like The Last of Us, or Dark Souls. But then, the article flips, and says mechanics are the “actions, behaviors, and control mechanisms” available. To me, that sounds like rules, like system—the more conceptual set of interactions that exist as ideas rather than concrete objects, Joel & Ellie’s Big Sad Adventure or Jumpy Jumpy Joel. To use my earlier distinction, MDA’s first definition of mechanics sounds like mechanisms, but the second definition sounds like rules.
The article’s odd double-definition becomes obvious in their examples: they describe the mechanics of shooters as “weapons, ammunition, and spawn points” (which are mechanisms set by software), but the mechanics of card games as including “shuffling, trick-taking and betting” (which are rules agreed to by players). These are two very different concepts being housed under one umbrella term.
This is a critical error. Mechanisms, the physical properties of an object (be that a beach ball, a chess piece, or Halo 3), are more or less ironclad. You can change them—pop the ball, mod the game—but until you do so, their properties are set. Rules aren’t. Rules are always murky, always mutable. As Stephen Sniderman writes, “regardless of what game you’re playing, you cannot know all the rules.” There are a thousand subtle minor implied variations in any ruleset, and trying to nail down all of them is impossible. Players must agree to rules, while mechanisms exist whether you want them to or not. Conflating the rules of the game with the mechanisms of the object ignores essential differences between the two.
But it is very convenient. The article emphasizes iteration; the authors mention over and over again the value of playtesting your game to create its intended aesthetic outcome. If it’s true that the designer creates both mechanisms and rules, and that those now-united mechanics create dynamics which create aesthetics, then you only have three possibilities as a result of a given playtest session: the game working as intended (nice!), the game not working as intended (a problem to fix), or players intentionally playing it wrong (not your problem).
But in real life, there are myriad outcomes from a given play session: a player gets really excited about one part of the game and ignores everything else; two players decide to be rivals and spend the game trying to screw each other over instead of trying to win; all the players deciding to work together instead of competing; a player who gets bored and starts coming up with new games inside the existing one; a player who misinterprets some rule but in a way that’s actually much more exciting than the designer intended. Players constantly pursue subtly different goals while using a given mechanism-object, and assuming that the designers have any real control over that is folly.
(This is why, as a sidebar, my videogame-developer roommates emphasize gamefeel over almost all else—if the object is fun to play with and encourages players to make their own games, the developer’s intentions don’t matter and don’t need to. Make a fun toy, and players will have a great time more or less regardless of what they decide to do with it.)
From here, dynamics and aesthetics mostly fall apart or don’t matter. The article comes up with eight fairly-arbitrary aesthetics and discusses how various designer and player decisions might convey those. “The designers’ decisions impact play” is, I think, such an obvious conclusion that it doesn’t bear much talking about (nor indeed, I might say, writing an article about. But again, if you need to fight your producer, go with god).
Okay, so. MDA makes a bunch of incorrect assumptions about what constitutes a game, and as such allots the designer far more control over the resulting play than they might have otherwise. What does this have to do with tabletop roleplaying games?
The short answer is that RPGs don’t actually have any mechanisms. There are rules, endless rules, but no ironclad physical properties. There’s no toy you need to play RPGs, no required object in the same way that soccer requires a ball or a Glitchless All Bosses run requires Dark Souls. You don’t actually need pencil and paper, or dice, or the rulebook—it’s entirely possible to play an RPG without any of those.
The physical artifacts that RPG designers do make, the rulebooks, are merely books. Those books contain some written-down version of an imagined ruleset, or a map of an imagined world, but they aren’t the games in their own right. I can memorize the rules of D&D and a map of the dungeon and play just fine without the book—or do neither, and play a different RPG, also just fine.
Okay, sure, but what if you take the assumptions of MDA as true (which I don’t) and hold that the rules of the game are also mechanics? Well, then there’s also the fact that most RPGs don’t have goals. Players play RPGs for lots of different reasons, and pursue endless different goals, even at the same table: slay the dragon; reach level 9; romance a hottie; tell the story of a tragic downfall; escape the dungeon; get to know the latest boblin; try to sequence-break the adventure; die in a heroic way; make one million gold pieces; act as your character would; finally learn astral projection; reach the city of dreams; whatever.
Each of these goals forms its own new game, and accordingly the constraints placed upon the player—be those constraints the number of hitpoints you have or the presence of the Imperial Wardens in High Falls—vary significantly in the degree to which they actually impede a player’s pursuit of a goal. We all might be using the rules written in the Player’s Handbook, but the player chasing the heart of the hottie prince is going to have a very different experience from the player trying to unlock fireball as quickly as possible.
(This is, of course, still ignoring Sniderman’s (correct) argument that no written ruleset can contain all of its rules.)
Okay, but what if you do give players a goal, and what if they really do all honestly genuinely try to pursue it? Unfortunately for MDA, you still run into the twin issues of indefinite state space and the GM. That is, RPGs’ state spaces are impossible to completely define: we can’t simulate an entire imaginary world, and thus exactly what is and isn’t allowed is quite flexible. I can pick up a flower in lots of games, but only in an RPG can I pick off a petal, rip that petal in half, feed one half to a dog and take the other to a lab, then examine the molecular structure of that flower petal. Basically none of those actions are “in the rules,” but all are allowed because it’s possible within the imaginary world. Defining exactly where the state space of an RPG ends is basically impossible because of this flexibility; accordingly, designers lose a lot of control over what is and isn’t possible, what is and isn’t in the game.
In both of MDA’s definitions of “mechanics” and the eponymous dynamism of dynamics, there is an assumption of relative fixedness. The designer may not be able to control exactly what the player does, but they provide the playing field. In an RPG, this just isn’t true: an imaginary world is too big, too complicated, and too easily zoomed-in and -out of to be constrained by any one designer (assuming the designer even creates an imaginary world, which many don’t). Because a GM issues rulings, the game is played by an ever-changing ad-hoc ruleset, one determined perhaps partially by the designer but also by the imaginary world—a world which, again, cannot be determined in its entirety. Even if we take MDA’s umbrella definition of rules and mechanisms together, those rules aren’t actually fixed. While you could probably make the argument that a specific table’s specific GM’s specific ruling functions as a mechanic which informs dynamics and aesthetics, now we’re back to “the designer’s decisions impact play”—a conclusion I don’t think we had jump through all of these hoops to reach.
To summarize, MDA mistakenly conflates the rules of the game being played with the mechanisms of the object used in that play. Because of this, it assumes that designers have more control over players’ behavior and play in general, which is false. Rather, players constantly determine their own games, both implicit and explicit, while using the same toy-object. In tabletop roleplaying games, this only becomes more true: RPGs do not have toy-objects or mechanisms, they lack goals and thus complete rulesets, and those rulesets are endlessly flexible due to the indefinite nature of the imaginary world. Thus, while MDA is perhaps occasionally applicable to videogames with multiple qualifiers and adjustments (though it usually isn’t), it is not applicable to tabletop RPGs, and we should look elsewhere to explain the aesthetics and ontology of the games we play.
Thank you. And thanks for sticking with me through this long-ass post.