Using the MDA Framework as an Approach to Game Design

Recently I found myself faced with a new design challenge: to create a digital game interface that uses differentiating hardware and software components to facilitate a fun and social game play experience.

design-critique

I looked for a framework to help me deconstruct the various aspects of the game into collaborative conversations I can have with client-side engineers, product managers, and marketers. I found the engineers were deeply involved in leveraging the hardware mechanics to design differentiating aspects of the game, while the marketing team was focused on product branding and visual design.

MDA Game Design Framework

I started as many designers do, weeding through the web to withdraw inspiration and artifacts to leverage something that might be pre-existing. That’s when I stumbled on the white paper “MDA: A Formal Approach to Game Design and Game Research” by Robin Hunicke, Marc LeBlanc, and Robert Zubek.

The MDA (Mechanics, Dynamics and Aesthetics) framework was developed and taught as part of the Game Design and Tuning Workshop at the Game Developers Conference, San Jose 2001-2004.

MDA supports a formal, iterative approach to design and tuning. It allows us to reason explicitly about particular design goals, and to anticipate how changes will impact each aspect of the framework and the resulting designs/implementations. By moving between MDA’s three levels of abstraction, we can conceptualize the dynamic behavior of game systems.

MDA-components

I also found that each of these ‘lenses’ mapped neatly to a key design exercise or deliverable (i.e. storyboards, wireframes and visual concepts). With these artifacts I was able to have focused design review meetings with key stakeholders, making decisions that informed the other lenses of the framework.

Mechanics

Mechanics describes the particular components of the game, at the level of data representation and algorithms.

storyboards

A key project requirement was to leverage the unique capabilities of the hardware product, which provide the client with a distinct competitive advantage. I used storyboards to brainstorm different ways the hardware mechanics could improve the overall “fun factor” of the game. If a client can provide differentiation there, it adds a multi-dimensional aspect to the overall product experience.

The decisions reached around the game mechanics defined the product concept. It was my job to explore creative ways to design the dynamics and aesthetics to leverage this key feature. I found that these kinds of foundational decisions provide nice constraint, guiding us down a path of convergence as the team moved forward in the design process. This lense of the framework supports the highest level of strategic thinking.

Dynamics

Dynamics describes the run-time behavior of the mechanics acting on the player inputs and each others’ outputs over time.

Here we focused on identifying the key activities within the user’s workflow as they interacted with the hardware and software components of this product. Now is a time to get more tactical with the design solution, thinking critically to provide something that was feasible and viable to meeting the business goals. We explored conceptual ways to incorporate dynamics to create excitement.

workflow-wireframe

I then used workflow diagrams and wireframes to illustrate these gameplay interactions. By incorporating low-fidelity wireframes into the workflow diagram, I saved time and it gave the developers all the connective information to start implementing in the prototype. I covered three significant workflows that covered the broad range of key game events, transitions and effects. I indicated roadblock screens (which require user interaction) vs. transitional screens, both of which informed me of the remaining detailed artifacts I needed to produce.

While working through this phase, my dev partner was getting a prototype environment staged. I had some interesting schedule complexities, so I addressed that by overlapping the design activities sorting through the dynamics and aesthetics of the game in parallel. This allowed us to agree on a visual direction fairly quick and start implementing high-fidelity screens into the prototype, which we used to simulate the game during usability testing a few weeks later.

Aesthetics

Aesthetics describes the desirable emotional responses evoked in the player, when she interacts with the game system.

MDA-2

When discussing aesthetics, I focused the conversation around visual design and product branding. How could I use tangible design elements to enhance desirability? The game I was designing required a unique style that mapped back to targeted age demographics. We talked about how specific aesthetics characteristics could ramp up complexity, and introduce constraints on system processing or load. If the client required a specific type of illustration, that could affect budget and team capacity. These are important conversations to have with your client if you project involves heavy visual aesthetics and style definition.

I leveraged the list provided in the white paper and added a couple more qualities more narrowly mapped to my client’s industry and brand values. I created this diagram to help aid discussion when making decisions around visual design complexity. The direction for this client project is indicated in red.

MDA-3

From here, we recommended three specific style directions, all representing ways the aesthetics could enhance the fun factor. I used a key game screens along with several logos to communicate the concept of each style. The client chose a route of minimal complexity, while maintaining some flexibility to explore effects or simple animations as a way to add more visual excitement. We settled on one direction and worked out all the details reflected in our workflows and storyboards, including animation, transitions, and additional states that needed additional design attention.

Concluding Thoughts

In addition, by understanding how formal decisions about gameplay impact the end user experience, we are able to better decompose that experience, and use it to fuel new designs, research and criticism respectively.

Using the prototype as our test platform allowed us to focus on getting the design 90% complete in order to validate the design during user testing. This is a way to test the full spectrum of design decisions, assumptions about gameplay experience, and user’s perception. I was able to extract feedback and isolate issues to one of the three levels of the MDA framework. We discovered some insight that led us to introduce two feature ideas that had been recommended early on. We were delighted to see the idea hold merit and reveal it contributed to the end product experience.

Not only does the MDA framework serve as a strong approach to game design, it also leaves the team confident they know why decisions were made, user’s validated the game was fun, and that they have a way to evolve and think about future enhancements to their product.