MDA
Lana Polansky recently wrote a very interesting piece about how we categorize games which includes an examination of the popular MDA game design framework. MDA stands for “Mechanics, Dynamics, Aesthetics”, it’s the organizing principle of Marc LeBlanc’s GDC game design workshop which I’ve been a part of for many years and was written up in 2004 as a white paper by Robin Hunicke, LeBlanc, and Robert Zubek.
In general I’m a fan of the MDA approach but I think Polansky’s essay highlights some of the most problematic aspects of it, especially around the terms themselves. I’ve been thinking about these problems for a while and reading Polansky’s piece has prompted me to try to organize my thoughts on the subject.
For me, the greatest strength of MDA is that it emphasizes the “second order” nature of game design. Mechanics is used to refer to the parts of the game that the designer has direct control over, aesthetics refers to the qualities of player experience that the game ultimately generates, and in between, linking the two, are the dynamics of the game in action – the behavior of the game’s different parts interacting with each other and the player while the game is being played.
Emphasizing this indirectness between what the designer puts into the game and the final result of the player’s experience can be very useful because one of the most challenging things about game design is how complex and surprising a game’s behavior can be. It’s easy to add some element to a game expecting one result and then watch something totally different emerge once the game is set in motion and begins to unfold unpredictably through time and space. MDA offers a way of thinking about this challenge – it develops models that help illustrate all the different kinds of qualities of player experience you might want to generate, the different kinds of dynamics that might produce those experiential qualities, and the types of mechanics that are likely to lead to those dynamics.
So what are the problems?
As Polansky suggests, I think the major problems have to do with the lack of clarity around the terms on either end of the equation – “aesthetics” and “mechanics”.
Let’s start with “aesthetics”. MDA wants to use this word broadly, to describe all the different dimensions along which a game can be beautiful, meaningful, interesting, moving, expressive, etc.
Unfortunately, this word has a widespread and unshakable association with the visual qualities of a thing. Most of the time, when someone talks about the “aesthetics” of a game they intend to refer specifically to the graphics, art direction, or visual style.
No matter how strictly you attempt to clarify that you aren’t talking about visual aesthetics, that you are talking about the broader set of qualities that make an experience beautiful, meaningful, interesting, valuable, etc., people will continue to naturally, instinctively think of “aesthetics” as “visual aesthetics”. You can say aesthetics means any emotional/psychological/expressive component of the experience that the game is attempting to achieve – whether it’s competition, exploration, storytelling, humor, terror, camaraderie – it doesn’t mean art style, it doesn’t mean graphics, and people will nod and say they understand. But then two seconds later they will turn around and say “the gameplay vs. the aesthetics”.
As someone who has tried for a long time to get people to adopt this broader use of the term “aesthetics”, I am reluctantly coming to the conclusion that it just ain’t gonna happen. Polansky suggests that “affect” might be a better way to express what MDA is really trying to get at here and I agree.
But even more problematic is the term “mechanics”. Again, MDA wants to use this word broadly to refer to all of the stuff that the designer has control over – not just the rules of the game but the materials as well, the recipe and the ingredients. Marc sometimes uses the example of a boardgame: the mechanics are all the contents of the box – the rule book, board, and pieces; the dynamics are all the actions of the game and players as it’s being played; and the aesthetics are the emotional and psychological qualities of the players’ experience that cause them to want to play the game again, or not.
Here we have a word-association problem that’s similar to aesthetics/visuals but a million times worse. Because people, especially game designers, have a very specific thing they use “mechanics” to refer to – namely the “chunkable” units of gameplay that are often shared between games, little combinatory tropes or conventions, what Polansky calls “ludic devices” eg. the 52-card deck, roll-and-move, jumping and falling, key-and-lock, hit points, etc… And it especially is used to refer to the units of interaction, the rules for how things are connected. It is, in fact, mostly used to distinguish interaction from sensation, to isolate the choices and actions in the game from the visuals, text, and sound in the game. Even though all of those things are “mechanics” in the sense that MDA wants to communicate.
This is so deeply confusing even the original paper doesn’t know how to sort it out. At first it defines mechanics as “the particular components of the game, at the level of data representation and algorithms.” ie. all the things in the game and the rules that determine how they behave and how the player interacts with them. This is the broad definition.
Later the paper refers to mechanics as “…the various actions, behaviors and control mechanisms afforded to the player within a game context” and then goes on to say that the mechanics work alongside (and are therefore presumably distinct from) the game’s “content (levels, assets and so on.)” This is the narrow (and common) definition.
Why does this matter?
The whole point of MDA is to help guide designers through game design’s highly second-order creative process. The designer has her hands on the stuff over here, all the things that can be directly manipulated in the design process (including all the materials and the instructions for how they are hooked together and their first-order interactions with the player), and she cares about the psycho/emotional/expressive effects that are going to emerge out the other end, and in-between there are players playing and all the surprising and hard-to-predict behavior of dynamic systems.
But instead of communicating this idea clearly the phrase “MDA” reinforces a lot of pre-existing concepts like “gameplay vs. graphics” or “underlying system vs. surface qualities” or “abstract rules vs. images and story”. Your brain has to work very hard to avoid seeing these standard dichotomies in the phrase MDA when, in fact, the version of MDA that is most useful (in my opinion) puts the rules and the graphics together along with the language and the sounds and everything else that constitutes the material “stuff” of the game.
I think maybe the source of this confusion is that MDA comes out of a time, and a scene, which really did emphasize the more narrow, system-focused, abstract elements of game design. It suggests a point of view that considers a game’s assets to be of secondary importance. I suspect they weren’t thinking of how confusing it was to include the graphics in the term “mechanics” because they weren’t really thinking of the graphics much at all.
I still think the MDA framework has a lot to offer when understood in its broader and more comprehensive sense. Like any design framework its usefulness is always going to be limited, it’s not a grand unified process for creating games, but it can be extremely powerful as a conceptual tool for approaching many game design problems.
Maybe we could keep the initials and replace (or add) terms? Like: Materials/Dynamics/Affect? Or Mechanics&Materials/Dynamics/Affect? The important thing is for people who use MDA in their practice and/or teaching to be aware of these issues and think them through for themselves.
Great post. I think a better triplet would be:
1) Design (given that we are thinking about all of what we already call design)
2) Play (given that we are talking about the game as played, not just its emergence properties)
3) Experience (given that this also ties into to User Experience etc..)
So Design – Play – Experience, DPE.
On a side note, Ion Storm’s list of types of fun is a better starting point for students in my experience:
http://www.jesperjuul.net/ludologist/the-words-of-game-design-the-terminology-of-ion-storm
@Jespar Juul
I think those are a bit too loose and indistinct, especially as categorizing terms. Play and Experience overlap each other a lot.
I think Mechanics and dynamics from this framework largely hold up, or can be reworked to hold up. It’s only aesthetics that needs replacement, or frankly dynamics can encompass what it once included.
I agree with Jesper – good post. I have never found the MDA system useful for game design, and further, I think it has actually garbled up people’s ability to understand and build rulesets.
Firstly, yeah, what you said about aesthetics is 100% right. I don’t even have anything more to add about that, other than to say that this element of MDA is so bizarre that it’s just plain useless.
This whole idea of there being a “separate” Dynamics layer, that’s like this distinct thing you can work on instead of the mechanics is also really problematic. Let’s be clear: all you can do to impact the player’s “dynamics” or “Play” or “experience” or anything else, is by changing rules or their representations.
I remember someone asked me at Practice 2013 after I did my talk, something like “Well what you’re saying about building systems is all well and good, but what about the player’s EXPERIENCE?” My answer was, “yes, this is how we influence their experience.” I find that this kind of weird sentiment pops up all of the time whenever anyone tries to make progress in the field.
I would say something like, “the widespread popularity of MDA is responsible for a great deal of miscommunication and has held us back in our exploration of game design”, but I’m actually not sure if we’re so lost because of MDA or we adopted MDA because we’re so lost.
I’d mostly side with Jesper here, though i’d prefer to keep “Dynamics”.
“Design” is a clear term, because it encompasses everything a designer can lay her hand on: mechanics, assets, style, narratives, etc.
“Dynamics” always has been the term most clearly cut in the MDA model.
“Experience” then would be sufficiently seperated from the other two categories.
Great article. I found this paragraph mostly relevant: “But instead of communicating this idea clearly the phrase “MDA” reinforces a lot of pre-existing concepts like “gameplay vs. graphics” or “underlying system vs. surface qualities” or “abstract rules vs. images and story”. Your brain has to work very hard to avoid seeing these standard dichotomies in the phrase MDA when, in fact, the version of MDA that is most useful (in my opinion) puts the rules and the graphics together along with the language and the sounds and everything else that constitutes the material “stuff” of the game.”
I think I see Keith’s point about dynamics. One key to design is understanding how rules generate dynamics and how you can affect dynamics by changing rules. Rule and dynamics are inextricably linked. However, I think it’s clear that the link between rules and dynamics is not always obvious, and iteration is usually necessary for a designer to gain their desired outcome. That is direct observation of the dynamics of the system is often necessary to understand the system even when the mechanics and materials of the system are known.
I guess this means often not obvious how rules generate both the potential actions and interactions of a game and the paths players take through those interactions. Perhaps the issue is that we as designers are not great at explaining these links. Maybe its something we should emphasize and make explicit rather than leaving implicit. If a designer knows how a mechanic shapes the possibility space of a game, they can share it. If they know how the mechanic interacts with psychology to shape player behaviour they can share that as well. So while I’m happy to acknowledge that mechanics are our gateway into affecting dynamics, I think we should still recognise that these links are not obvious and warrant investigation and explanation.
Great write up. As someone “raised” in the era of system centricity, I struggled a lot with reconciling mechanics with visuals/sound/touch, etc. In my stuff I use ‘theme’ but that isn’t quite right. Material rather than mechanics is really the right thing, but that lumping together may be a mistake.
Another area that isn’t captured well in MDA is the socio-cultural context in which the game is played in.
Keith,
I think if we lose the middle layer that we might be missing some of the nuance of the game design process.
You say “This whole idea of there being a “separate” Dynamics layer, that’s like this distinct thing you can work on instead of the mechanics is also really problematic”
MDA doesn’t suggest you can *work on* anything other than the Mechanics layer. It is rather that MDA acknowledges that these mechanics don’t directly map onto experiences without interacting with each other in a complicated way. That’s *why* I like MDA.
You say: “Let’s be clear: all you can do to impact the player’s “dynamics” or “Play” or “experience” or anything else, is by changing rules or their representations.”
Sure. That’s all you can do. But those rules don’t map directly, 1-to-1 to player experience. It’s not that simple.
When you press “play” the rules interact in a way you can’t predict as a designer (past a certain level of complexity).
If I add an extra food per tile in a Civ game, how quickly does the player get to a size 5 city? The answer to that question is different from the answer to “how does that make the player feel”. We have to “press play” to understand the thing we create – even if we create it in these static ones and zeros. And that ‘thing’ we create, the way it makes the player feel and think – is another level of complexity.
In the original X-Com game, the developers have spoke about how the aliens would make “random” moves. The players perceived real intent behind these moves and had a level of paranoia and concern about clevel plans and whatnot. The experience of that (paranoia) was created by the interplay of the line-of-sight / fog of war stuff and the ‘make a random move’ stuff. And that interplay was created by having lots of independant mechanics. We could have created almost the same ‘dynamic’ by having real AI making real plans – the rules would have changed but the dynamic wouldn’t have.
I find it a bit hard to articulate I suppose, but if we remove that “Dynamic” layer, we are almost suggesting that the *interplay* of the rules, of the ‘stuff’ of the game is not as important.
good article tnx
Great article