We have various frameworks and processes that deal with the problem of designing interactive products and services in a customer-centric way: design thinking, user experience design, user-centric design, customer development etc.
However, games are unique in terms of design: they pose a second-order design problem. On one hand the properties of a game that makes it great can only be assessed by playing the game. On the other hand the designer cannot directly influence the gameplay experience — she only has access to the mechanics and the interface of the game.
That is why we need a unique design framework for game design for designing games effectively. The empirical game design framework is my proposal for such a framework. It is heavily influenced by the work of Eric Zimmerman in his Iterative Game Design Process but also borrows from Lean startup by Eric Ries, design thinking , the Mechanics Dynamics Aesthetics framework of games by Robin Hunicke et al. and the game design workshops of Katie Salen.
The empirical game design framework is based on validating the design in practice. We define clear goals for the game and the solution to reach that goal emerges during the process. The practical work involves making and playtesting game prototypes based on the current vision of the game, called the game concept. Each play test attempts to validate the prototype against one facet of the goals we have set.
The goals specify the gameplay experience we strive for – in playtests we validate whether the current concept reaches those goals. This goal-oriented empiric validation process ensures that we have more knowledge to refine the game concept to better reach our goals after each iteration. This makes the framework empirical and well-suited for game design.
Why Is Game Design Complex?
I have argued that game design is a second-order design problem. Let’s use the Mechanics Dynamics Aesthetics framework of games to illustrate this argument.
Games are created by designers and consumed by players. The difference between games and other entertainment products is that the consumption of games is unpredictable. The difference between games and most other forms of interactive products and services is that games have systems of mechanics and procedures that make the interaction between games and their players unpredictable.
The MDA framework conceptualizes this by breaking games down to three distinct components (quoting directly from the MDA article):
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.
The designer approaches games from the viewpoint of mechanics and the player approaches from the viewpoint of aesthetics. However, the objective of the game designer is to support certain kind of aesthetics in the game for the players.
The dynamics in the middle make the relationship between mechanics and the aesthetics of the game unpredictable. The aesthetics of a game are dependent on the mechanics of the game interacting with each other and with the players in motion, i.e. the dynamics of the game.
In conclusion, the dynamics of the game make the effect a change in game design (i.e. a change in mechanics) will have unpredictable in terms of game aesthetics. This makes the act of game design unpredictable. Other way to describe this is to say that when played by players, games are complex adaptive systems. And we need an empirical approach to tackle all that complexity.
Elements of the Framework
Elements are the game pieces of the framework for the designers to play with. They describe how to specify goals for the game, how to describe the game concept, how to structure playtests with test questions, how to make game prototypes and so on.
Goals of the Game
Goals of the game describe the design problem we want to solve by a new game design. An example problem for designing agile games is “I want to illustrate the importance of face-to-face communication with a game that can be played in fifteen minutes in a team coaching situation with minimal props.”
Game’s goals describe the aesthetics or the game experience desired from the game and the context for playing the game.
Note: Goals are essentially the same thing that Eric Zimmermann calls game values in his game design process.
Goals are divided in to two categories: objectives and constraints.
Objectives are statements about what the game should do in terms of game experience or game asthetics. A couple of example objectives: “A light party game for groups of people to get them to know each other quickly“, “web-based game of conquest for people that are active in social networks that keeps the players coming back again and again” and “a browser-based game that helps player in getting the basics of agile software development principles and practices“.
Constraints are limitations on the implementation of the game. Constraints describe the context the game is to be played in. For example “can be played in less than 30 minutes“, “works on any browser without plugins“, “can be learned by a non-gamer in less than a minute” are possible constraints.
A game concept expresses the core idea of the game. It is the proposed solution for the problem expressed by the goals of the game. The game concept starts with a more high-level description and emerges into a full-fledged design during the design process. The content of the game concept correspond with the mechanics component of games in the MDA framework.
The high-level description of a game concept usually answers the following questions:
- What does the player(s) do?
- What genre / format / type of game is this?
- What is the goal of the game?
- What are the main features of the game?
- When does the game end?
- What are the most important game elements?
At the earlier stages of game design the game concept description should be concise. A couple of sentences will do. What it needs to communicate is what type of game you are proposing to design.
During the design process the game concept evolves into a more detailed description of game’s mechanics through prototyping and finding out what works.
A game prototype is a subset of a game design, that is, one or more mechanics implemented into a playtestable artifact.
At the earlier stages of game design the game prototype can be only a small subset of the game’s main mechanics, but typically later in the design process a more complete collection of game’s mechanics are tested together to make sure that the dynamics (i.e. the emergent properties) of the game lead to the desired aesthetics.
Use as low-tech and low fidelity prototype as you can to be able to test.
You can use paper prototypes (even for videogames), use one designer as a facilitator to help with the operations, anything to keep the production costs as low as they can.
Test Questions and Playtests
We need to think how to validate the game prototype against each goal of the game. Test questions is our way of describing how we will test the game concept in terms of the goals.
The test questions should be ordered by priority so that we design for and validate the most important factors in the game first.
Some example test questions to help you on your way:
- Is this game playable at all? (mechanics question)
- Are there interesting decisions for the players? (aesthetics / mechanics question)
- Is this particular strategy too dominant? (mechanics question)
- Are the interesting decisions in the game related to the learning objective? (objective question)
- Can this be played in 15 minutes? (constraint question)
- Do new players get what the game is about? (learning question)
Playtests are the instances of validation. You select a set of test questions and develop the prototype to test and arrange a playtest session to validate your prototype against the test question (and thus some set of goals for the game).
The Framework in Action
Now that we are familiar with the pieces we can begin to play.
The design endeavor starts with setting the goals for the game. After that it is time to explore the possible game concepts and pick one (or a couple, or a combination of a few) as a starting point. After that a cyclic process of building game prototypes, performing playtests and learning from the results of playtests is utilized to refine the game concept until the game concept is deemed satisfying enough solution to the goals of the game.
During the refining of the game concept it is also possible to make a pivot: a change of direction for the whole design endeavor. As in Lean startup, this move is a larger shift in the process in which the goal setting is re-visited.
Setting a clear goal is the most important prerequisite for a goal-oriented game design endeavor. A strong goal informs the whole design team where the focus in the work should be.
Sometimes it is interesting to start with a more ambiguous goal to enable experimentation. In that case it makes sense to set conditions or a time line on when the goals should be defined clearly.
Exploring possible game concepts
Before zooming in towards a specific solution it is useful to explore the whole possibility space. As in the research and ideation phases of design thinking, it is useful to both study existing games for ideas and to open up your mind to new possibilities with brainstorming exercises.
Choosing or Composing the Candidate Game Concept
After exploring the possibility space it is important to make the first informed guess about the most promising solution to the design process. That means picking the most attractive game concept or merging a number of game concepts into the candidate game concept. The other game concepts should also be left on the table to inform about different options later in the design process.
To quickly come up with a game concept candidate it is sometimes useful to take a suitable existing game as a starting point, pare it down to a high concept description and adapt it to the goals at hand. This can be a time-efficient shortcut especially when you are more interested in experimenting with the game design process than the quality and originality of the resulting game. (I adopted this approach from Katie Salen. She used it in the Games and Storytelling game design workshop in Tampere in 2003.)
The Build – Measure – Learn Cycle of Playtesting
After the initial game concept has been fleshed out it is time to start the cycle of refining the concept.
The cycle consists of three actions: Building the game prototype, measuring it by playtesting it and learning from the results and refining the concept.
In each iteration, you need to select a test question for the iteration. That is the question you explore with playtests to see how you current design fares.
It is essential to select the most crucial questions first. If you have one objective that you value more than others you should formulate a question to test that first. Or, if you have some mechanics problem that you deem of high-risk, start with that. That way you won’t waste multiple iterations with a weak game concept.
After that you produce the prototype. You choose the mechanics of the concept that correspond with the test questions for this iteration and build the prototype based on them.
After you have your prototype it is time to test it. With your test question in mind, organize a play test session
At first it will be enough to have the designers themselves test the game. At this point the design is still in very early stages and you are likely to make many tweaks to it. The questions will also be on a very high level so you can probably get away with the designer bias (if you are honest with yourselves).
At the later stages you need to draft more people, starting of course with potential stakeholders, partners, friends, relatives and the like. At the final stages it is probably a good idea to have some people unrelated to the design endeavor to test the game.
An important point in playtesting is that if you tweak the rules in the middle of the playtest you are basically screwed. The observations you have from the session before the tweak are from the non-tweaked version of the game and the rest are from the tweaked version. There are usually very low probability of coming up with conclusive readings of how the game plays with that kind of data.
Of course if you have to fix something to be able to continue the session, do it, but take a moment to think about what the tweak means in terms of your test question.
Naturally it is important to observe how the game plays during the session. What happens, are there any notable moments, glitches etc. You can also interview the participants afterwards, but formulate the questions carefully.
The testers usually have a very different view of the game session than the designers have, so you probably need to do ask for concrete data and do the interpretations related to game mechanics and their effects yourself.
Learning and Refining the Concept
After the playtest session, it is results time. Take a look at the data you got from observing the game session and the tester interviews (if you did them) and find out if you can interpret that data into an answer for your test question.
Based on the answer, it is time either to focus on new test questions (if the result was positive) or to form another solution for the problem at hand (if the prototype did not satisfy the goals tested against).
It is also possible to do a pivot, if that seems the most viable option.
Pivoting: Moving the Goal During the Game
In lean startup, a pivot is a “structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth” (to quote Eric Ries). It is important that the course is changed only when the current direction is deemed as not that enticing any more.
In the empirical game design framework, the idea is same. Pivot is when you decide to change some of the goals of your game design endeavor. The triggers for this can vary: You can feel you have reached a dead end, or at least that you have set goals that you cannot reach easily with the resources you have.
On the other hand, you can also come up with a game concept that would hit a lot of the goals you have specified, but you feel you have to break some of the constraints or even objectives to keep the game working. These kinds of discoveries are pretty common in empirical design processes like this so you should not be too stubborn on not making the pivot when a low-hanging fruit like that invites you to grab it.
Designing a game can seem like a chaotic endeavor. The empirical game design framework has been developed to provide structure and vocabulary for this endeavor to enable goal-oriented work that is not bound by too limiting a structure.
This framework is still a work in progress and has been so for a number of years. My way of developing it even further is also empiric: I offer game design workshops based on this framework and also offer support and critique to people designing their games, whether it is using this kind of framework or some other kind of way of working.
I hope that you will find this blog post valuable! If you decide to to test it or would like me to come and facilitate a game design workshop, please comment here or contact me through Twitter (@anttiki).
Picture credits: All the nice illustrations in this blog post are the work of Meike Mertsch (@meikemertsch) at Play4Agile 2012, photographed by Olaf Lewitz (@OlafLewitz). A big thank you for that. The rest of the pictures are my own work (those featuring post-its with hopefully readable scribbles 🙂 ).