A new model for game design: Moving beyond the “Mechanics, Dynamics, Aesthetics” framework

The MDA framework is now well known in design circles. Here I take it a step further putting forward my own riff on the model for tabletop games specifically; incorporating the notion of access and mapping out some critical detail.

Why build a model?

I have always had a penchant for systems and frameworks. Huge geek that I am, I’ve always enjoyed a good railway network diagram or process map. In my professional life I’m the person who took on the job of mapping out my company’s technology stack’s to give us a comprehensive picture of how it’s 38 distinct components interacted (or over-interacted in many cases!). Such frameworks or models aren’t just fun for people like me though. They are a very useful abstractions to help us map out what’s going on and prompt us to do our work better.

It was probably only a matter of time that I did this for tabletop games. But just recently I’d been reading a lot more about design in general, absorbing an eclectic set of materials from the rapidly emerging academic study of games: from Joey Schouten’s study of roll & write games, to the accessibility explorations of Dr. Michael Heron (Meeple Like Us) us to classics like “Rules of Play” (which I am still working my way through). Several strands of thought came together and I was compelled to map out (in broad terms) how I thought games create player experience for my own purposes. With any luck, I thought, it might be useful to other people.

We can do better than what I’ve seen so far

What it turned out I was coming-up with on my own was something that initially resembled the now well known Mechanics, Dynamics, Aesthetics framework (with thanks to Yogidesigner Bez Shahriari for the spot). So I turned my attention to what had already been created on MDA to see what I could pick-up.

In the end though I found what I was able to get my hands on so far a little deficient and continuing to reinforce the distinct feeling I’d already had: that we are still really early in the development of useful theoretical models in this sphere. For Tabletop games in particular, everything I was able to find seemed very high-level to me and much of it was originally developed for video games. There was no special mention of the critical role access plays in shaping experience and often the aesthetics were characterised or glossed over as merely the paint job on the game machine. Outside the classification of types of play (which is really useful), I’ve found little deep examination much about the subjective world of the player; all the things they are influenced by and what they are doing when they play a game. They also tended to be overly focused on the game as an abstract entity unto itself, rather than something that comes into being as something with physical, as well as conceptual, properties.

A new model

So there was nothing else to than to have a go at doing my own model. It’s just a first pass and it’s just an outline focusing on what seem to be the most critical relationships involved. Ultimately, my goal was to create a tool to interrogate games to understand the engine of tabletop better, not provide a comprehensive treatment of play. This is why “experience” is left very broad.

Much as in the MDA framework it assumes that the designer and player are separated by the game. Just like MDA, it recognises that the designer/developer (designer was is too limited for the practical business of making great games) can only effect the player through the game as an intermediary.

But unlike the MDA I have formed these into three “worlds” that are not mapped to the Mechanics, Dynamics and Aesthetic layers. That’s because, I think the stack model, while a conceptually neat and reassuring analogy, doesn’t actually represent what I see going on in Tabletop games.

Firstly, it represents poorly that that the real-world objects or properties of tabletop games, like art and graphic design (the sensory presentation), theme or even rulebooks have nothing directly to do with mechanics or dynamics of the game. It’s not only that there are players for whom, and games where, such materials are more important than mechanics or dynamics. It’s that these other sensory or conceptual elements can be generative of experience regardless of mechanics or dynamics; in diagrammatic terms, they bypass those components completely. Depending how they are designed, they can lead players towards or away from access and shape experiences when the real mechanics or dynamics remain the same. Rather than being determined by lower layers, it’s actually up to the designers/developers of the game to synchronise or harmonise these other materials with the mechanics or properties in such a way that they contribute to the overall game experience. How effectively they do this has a huge bearing on the success of a game as a whole.

Second, it misses that access itself has a more complex relationship with experience. Access shapes experience because as Dr Michael Heron has very astutely observed games must be intentionally inaccessible in some way to be a game. While we want to eliminate inaccessibilities that do not contribute to the game (or can’t be removed without affecting experience unacceptably), all games involve some obstacle to achieve an objective or they aren’t games. And access itself is not a passive process in which players merely have another perspective. Rather, players are engaged in an active process of discovery that contributes to a circular development of further experience. This is why, my model is ultimately cyclical.

How to read the diagram

Where possible, I’ve tried to use standard flowchart practice. But for those not familiar with such conventions (and to cover any disparities) this is what each component means. I have also included some explanatory notes on definitions:

The borders of three worlds have dotted lines around to show where specific components sit

The ‘components’ themselves are shown as two types:

the starting/ending points of design and player outcomes (as per process chart convention) as rounded ‘terminator’ boxes

The intermediate components through which the designer can reach the player (and vice-versa) as square ‘process’ boxes

Black lines which show how components contribute to experience from the designer’s world

Bluelines which show how components are reached from the world of the player as they discover the game

Verbs on each line describe the primary effect a component is having / should theoretically have on the next component

An extra path (dotted line) shows the way in which player world reaches back into the design process. I included this because I think it’s good to acknowledge how this loop works if the model is to be used as a tool for designers/developers

“Strategy” is used in the broadest sense of the term to mean the formulation of practical approaches by the players to consciously fulfil the game’s objective

Designer/Developer wouldn’t necessarily (or even mostly) be the same person, but is trying to capture the idea of the whole production team, not just the the abstract elements often considered as “game design”.

Limitations and final thoughts

The model I’ve presented here is, no doubt, absolutely full of holes. It still represents a massive simplification of what is going on under-the-hood of a tabletop game.

We can take rulebooks themselves (the most common type of rules documentation) as a clear example of this. In the model, experience flows one way from the game’s documentation. But when reading a rulebook, you often have to return to it a few times to understand crucial mechanics as it develops. That itself is another cycle of learning which I could have illustrated more directly in the diagram.

What I have tried to do though is, for the benefit of abstraction, keep it to the most important connections. The example of the rulebook also serves to illustrate why I haven’t included several other clearly relevant component relationships. I would argue that, given the rulebook is generally less useful after the first game, it’s main value is as an input to access that, which in turn contributes to a discovery of rules as intended (the mechanics). After all, the rulebook isn’t really interesting for itself. And what a rulebook actually is, is just designer’s description of their own mechanics, rather than the mechanics themselves. The distance between those things is very well illustrated by bad rulebooks.

I would also have liked to include a lot more in the way of a formal treatment on how players learn. Learning in general is a subject area where there is a vast amount more material that can be mined for insights.

Across the board, there’s doubtless a lot that can be improved. What would you change?

6 Comments

That’s a tough one that I find difficult to decompose, but I’ll have ago. Modifying a dictionary definition the access here would be “the means or opportunity to approach or enter the game”. So a rulebook helps you access the game because it helps you understand mechanics. Equally colour helps you access a game because it makes it clear which elements belong to which categories. Colour can also be a point of *inaccessibility* though if you are colour blind, for instance. So these are some of the things that shape access.

Your experience comes partly from the access. So if there was a game which had beautiful mechanics, but every piece looked incredibly similar, the access would diminish the experience, because you would have more trouble getting “inside” the game so-to-speak to enjoy it.

Drafted in here to reply, so I will!
I think a useful way to think about access is in exactly the meaning of the work – how does it let people into the game. ‘Inaccessibility’ is something that stops people getting access, but you can also design *for* access through things like affordances and utilising common metaphors. Thematic games tend to be quite good for this because they have affordances built in – we can extrapolate from real world knowledge to get an idea as to *why* we might do things. That’s a kind of game design access that comes with a good theme that merges well with clear mechanisms. If you’re just trading ‘six blues for a red’ or the like you need people to build those connections themselves. Access in theme would mean ‘a theme that lets people understand what they’re doing quickly’
But the level at which we look at it on Meeple Like Us is a step up from that – the accessibility of the ‘interface’ to a game – so, how do all the elements and mechanisms come together in a way that permits people to interact with the game. As James said, with very similar pieces people have difficulty in actually getting access to the *game* because the interface gets in the way. A good interface in any circumstances should be as invisible as possible and the more people need to concentrate on an element of the game the more inaccessible that element tends to be. It’s possible for people to be entirely blocked out of playing the game just because an inaccessibility (even in an unexpected place) got in the way. Basically you never get to enjoy the mechanisms because you’re stuck at the metaphorical loading screen. An inaccessible board game interface is a bit like trying to quit out of Vim. ;-P

First, in the diagram there is no overlap between the “Player world” and the “Game” which I find strange. I understand that these -influence- each other, but should the game at least partially be part of the player world? Or is this player world the abstract thing that sits completely in the player’s head?

Second, Meeple Like Us is talking about an “interface”. For a computer game I understand this: There is really a lot of stuff going on beneath the surface: The computer doing calculations (simulations) that you will never know about. But for a board game this isn’t the case, the game -is- the interface? Any manipulation of the game is done by a player, so players have to “interface” to change the “internal state” of the game. And that internal state is directly observable by players (even if the rules disallow you from manipulating it directly).

There can be hidden information but as far as “the game” concerns, that information doesn’t exist (there is no way it can influence what players need to do, until that information is revealed to at least 1 player)

Coming back to the original “access”, do I understand correctly that this is something like “ease of getting into the world of the game as a player”? Which is made up of “good manual”, “intuitive rules”, “clear components”, etc.?

Hi Baastian – first-up thank you persevering with my somewhat opaque model! 😀 Clearly if you are left a bit confused there’s *a lot* of work for me to do.

Ok so here goes an attempt at answering your questions:

1) I think the game world and the player world are best thought of as conceptually separate. The player and the game absolutely interact constantly (which is what the arrows are trying to show) but in my model the game is just a set of concepts and some physical bits created by a designer/developer/publisher until we have a player. The player world isn’t necessarily just what we narrowly think of as the mind, it’s also in their body and senses (bits can be touched, felt etc.) However this world, is the world of the ‘subject’ not the game which is an ‘object’. They can react to a game and participate it but I don’t think they ever become the game, if that makes sense? And for that reason I don’t think they do conceptually overlap?

2) So I think boardgames are fascinating because they are more purely an exercise in product than software. In general, there is no code or hidden moving parts (clockwork physical mechanics aside). Every component (as I would think of it in software) can be touched or held by the player. And the rules are only enforced by people. However I don’t think that means the interface and the game are the same.

Imagine two physically separate game products with identical same mechanics and rules: e.g. there are x pieces, a player can do y specified things with the pieces to secure objective z in both cases. One of those games has a lively medieval theme, the other has no theme at all, and all the pieces are in the same colour and can barely be distinguished.

The play experiences of both are likely to be quite different. The medieval one might be easier to pick-up and for many people more inviting, depending on how well the theme is executed. The other one might be more daunting and hard to see what is going on. But in an important technical, classical sense – they are actually the *same* game. The mechanics are identical, the resulting dynamics are therefore identical (assuming rational players) and the strategy required to win will all be the same. The main difference with software is that whereas code specifies what happens behind the interface, in analog games it’s rules that do that. Unlike code though, they only exist conceptually (they get described in rulebooks) and have to be enforced by players. Whether these concepts exist outside of our minds is a much bigger philosophical question. But for our purposes, I think we can say they exist as part of the game beyond what can be tocuhed/seen/felt etc. because its possible for rulebooks to be wrong or players to be mistaken.

3) I think those are all access related issues – manual, intuitive rules, but I was meaning it in a more general sense: good and bad access. Just the business of players grasping the game (long before you get to any meta-thinking like strategy).