MDA stands for Mechanics-Dynamic-Aesthetics. You can read a short paper that introduced MDA as a framework term here: http://www.cs.northwestern.edu/~hunicke/pubs/MDA.pdf.
It has been a year since I was first shown this picture and told about MDA.
And only during my summer of the reflecting bonanza have I started to come to some terms with it. Still, I have my own interpretation of MDA. And I can say that during the year of development I have never thought of MDA actively while developing. Whenever I was faced with the requirement to discuss MDA in my final reports after any project I felt like this:
What was the issue to me? As of right now, I have two ways to see MDA. In a way, I believe that this confusion is caused, yet again, by the fact that this is a practical rather than theoretical education. Understanding of MDA requires a philosophical discussion which is mostly skipped here in the favor of making games. So, it took me a year to waddle over to this point and I am supposed to be a more theoretically inclined member of the team (as I claimed in part 3.1 and 3.2 about who the Game Designers are)! This leaves me to wonder how much understanding did those of us get who spend their time in lectures about practical skills only, like drawing and coding and managing? At least the Game Designers had some time to discuss this in our smaller class.
My first interpretation was based on the picture that is taken from the original MDA paper and was showed in our faces several times (top picture in this post).
Examining it without an extensive discussion left my understanding of MDA impaired. I could only see it as an isolated system that exists by itself. A system that can be summarized like this:
- Create something that is something or does something.
- Create a series of somethings that interact with each other in some discernible pattern.
- Feed the pattern into the mind of a player via sensory inputs.
If this is a player’s perspective, it’s going to be turned around obviously. The player will consume the pattern, break it into its elements and digest it.
Kind of a crude way to describe the process of creating a game, won’t you agree? For that reason, I was mostly in denial about using such a system when crafting games. It would confuse and infuriate me when a hand-in required us to mention how we considered MDA in our work process.
But now I can see that I considered MDA after all. I didn’t call it MDA, and I still wouldn’t call it this way. The truth is that the original paper tries to reference this in a very… clumsy way, in my opinion. I’d say that to the authors it was more important to create a point of common reference for the scholars and developers. So, it’s not strange that a student glancing over the paper about the MDA framework would pay more attention to the visual presentation of MDA rather than the actual message. Especially so, when that image itself is being shown to us in the lectures. Please, understand that this is my way to see things.
What do I mean now by saying MDA now? To me, it is a core of the creative process. The three main spheres of any game. But it isn’t about a straight line. Rather, it is about the understanding of the how elements influence each other. The understanding that anything you add to the game influences your product in all direction. One must think forward and backward at the same time. One must remember all the crafted assets, all the planned assets and all the assets that might be considered in the future. And one must see the ripples that are sent through the dimensions of the mechanics, the dynamics and the aesthetics by any discussed idea. A synergy of the highest order.
So, was I considering MDA when I was working on my projects? Yes, if the complexity I just described is the MDA. Otherwise, I considered something that is much bigger than a picture with three words and 2 arrows.