How to Design and Playtest Your Game Concepts

Notice: I’ve written the next iteration of this blog post: How to Design and Playtest Your Games (version 2.0). Please read that one for an up-to-date view of my thinking about empirical game design.

An overview of the Iterative Game Design Process as we used in the game design workshop at Play4Agile 2011.

Game design is unique as a design task. 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. (see the mechanics – dynamics – aesthetic model (pdf), which worth it’s own blog post)

That is why it is recommended to design games in an iterative fashion — to make a prototype of the design and to playtest it. Here’s an overview of how such an iterative game design process could be structured. The structure is based on Eric Zimmerman’s article Play as research: The Iterative Game Design Process.

The Puzzle Machine by Profound Whatever, on Flickr (CC non-commercial, attribution, share-alike)

The Iterative Game Design Process

1. Decide on Game Values

The first step is to decide what are you going to design the game for. Game values articulate the design problem you are trying to solve with the game design. You need to decide on the game’s:

• Objectives and
• Constraints.

Objectives are statements about what the game should do. 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. 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.

Gate 1: Game Values

Before proceeding, you need to have positive answers for the next questions. If you find yourself answering no to either of these, go back and re-formulate the game values.

Question 1: Are the objectives of the game valuable? Are they worth achieving?

This is pretty self-explanatory. Every objective should be important and provide value. If you find that you’ve listed some stuff that is not needed, you can cross them out. On the other hand, if you haven’t got any objctives that you consider valuable, maybe you have to dig a bit deeper before continuing.

Question 2: How will you know if the objectives have been met with a particular game?

As game design and its effects on the gameplay experience is not straightforward, you may have to think about this a bit. There may not be clearcut answers for all your objectives, but you should have some idea of how to measure the progress of your design towards the objectives.

1.5. Brainstorm

After deciding on the game values, it’s head-to-the-clouds time. Set your reservations aside and start to brainstorm any ideas on what the game design could include. Make a wall of post-its, a long (unordered) list, a mind-map, some drawings, a list of links and references. Anything to get the creative juices flowing. It’s good to have a number of people involved together at this phase as bouncing ideas of one another is often a good way to come up even more ideas.

2. Create a Game Concept

In this phase it is time to formulate a high-level view of a solution proposal for the design problem articulated in phase 1.

A game concept expresses the core idea of the game. The 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 mainfeatures of the game?
• When does the game end?
• What are the most important game elements?

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.

You can end the brainstorming phase by creating a number of concepts and select one in this phase. Or a some combination of the most promising ones, whichever method seems to produce the most promising concept.

Gate 2: Game Concept

Question 3: Does the concept fit in with the game values?

If not, you need to go back to the concept creation step or if the game values need re-thinking, to phase 1.

Tough Question by Terry John (CC non-commercial attribution)

3. Test Question

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.

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?

Gate 3: Test Question

Question 4: Is the test question important for your design?

Basically the same question as question 1, but on a smaller scale. If you can trace the test question back to one of your objectives or constraints, you are probably all right. If not, maybe you need to re-think your question or your game values?

Question 5: Can you measure the success of your prototype in regards to the test question with a playtest?

In other words, is the test question measurable and how can you measure it in the playtest?

prototype by YAPixel (CC attribution share-alike)

4. Design the Prototype

Now you need to produce a prototype to use in the playtest. 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.

5. Playtest

After you have your prototype it is time to test it. With your test question in mind, organize a playtest 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.

LEGO Mini construction site by bucklava (CC attribution)

6. Analyze

After the 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.

7. Iteration done, onto the next one!

If you got a positive answer to your test question, kudos to you. If not or the answer was inconclusive, also kudos to you. Both ways you now know more about your design.

If the answer to the test question came out positive, you’ll also need to consider all the previous test questions you had. Game design is not an incremental activity and so you cannot possibly know if the design decisions you made this iteration broke something that was working before. So test the previous questions if you intend to use the current design as a basis for the next iteration.

If you did not get a conclusive answer to your test question, figure out why. Was the question too vague? Maybe you need to figure out how to measure out your question better or even formulate it in another way. Or maybe you need to change some of your playtest practices.

If you get a negative answer, it is probably time to hit the design board again.

Either way it goes, the minimum for each iteration on each phase is to return to the gate questions of each phase. This way you can be sure in each iteration that you are working with something valuable and can make progress.

If you are in the enviable position that, after multiple iterations, your game design fulfills the game values you set for it and you are happy with it then congratulations! You are done for the design part (for now). Now go throw the prototypes away — I mean keep them as a document of the design, but I would suggest you start to implement the actual game from scratch. And feel free to return to the prototyping whenever you feel the need to do so.

Final words

So that was the short of it. I hope this is of some use. I’m happy to answer any questions or comments you have on iterative game design.

The are much more to be said about each phase of this process and in fact there are many resources out there to help you laying around in different corners of the web. Next thing for me to do is to compile a list of resources, but that will be a topic of another blog post.