Six different players negotiate the distribution of 11 jewels of nine different colorsin 60 seconds . Teams of children are competing to get the right set of keys to open a treasure chest; is it morally right to encourage violent robbery of a wanted key? An old-fashioned dogfight game requires programmers to implement deathhow does that feel? Designing a Myst-like adventure game in real life encourages the use of... grass. What is going on?
The examples above all come from my life as an interaction/ gameplay designer or teacher of these subjects, and to me it just proves that gameplay design is in fact interaction design. Why? Because gameplay design is design of the core game, i.e., the rules of the game. And the rules in turn affect not only how the game is played, but also how players interact with each other via the game and thus in turn how they experience it. For instance a game like Yahtzee, with its luck-based and non-interactive gameplay, will result in a totally different game experience than a negotiation-intense game, where you have to actively interact with others in order to succeed. Hence, every single design decision matters when writing the rules. Imagine for instance a poker game where all cards are open; this simple decision reduces the game to an exercise in counting the odds. This, the immediate impact of a design change, is what makes gameplay design so interesting and so instructive.
In addition, the freer realm of games opens up for interesting challenges when it comes to interaction design. Let's take the first example above, with negotiation: How often do you get to design that in a normal GUI? How would you go about transforming such an immediate, body-language-dependent process to an online environment? I've given this task to 180 students in 39 groups, and there seems to be at least three and a half solutionscan you figure them out?
Games are full of these unusual interaction issues, never before solved. In addition, they often provide moral or ethical issues, as in the examples above. In the children's game, the solution was to introduce stun guns into the game; the children could shoot and stun each other, and whoever was stunned had to give up his or her key and stand still for a minute. As for the dogfight game, the students programming it wrote this in their report: "On the other hand it was interesting to face one's feelings when one implements status = STATUS DEAD. It is not uncomplicated at all, and maybe it does not just numb but also starts thoughts on why?" Another group of students set out to make a live version of an old-fashioned computer game in the adventure genre, but as they couldn't make the entire game, they designed a small room in what should have appeared as a cottage. To create the feeling of a mystery, they worked hard with effects like a filmed face projected upon a dummy, saying mysterious things, secret writings on the wall that appeared only in ultraviolet light, a buzzing radio that was in fact controlling interior sounds, a diary, etc. The room was part of an exhibition, and despite the fact that it was dark and the outer sounds were muffled, the room did not really get its own character until the students bravely rolled out a piece of real lawn in what was to be "outside." The musty smell of grass changed the experience completely, and it exemplifies how games open up new aesthetic dimensions and questions. Actually, any non-abstract game is full of aesthetic issues, the most important ones being how the theme should "carry" the rules and make them logical: "No, you can't move across that square, because that's water and you don't have a boat." And so on.
So, that's why you should try gameplay design if you have not done it yet: to explore new problems and possibilities, and to work with a set of aesthetics that is freerand more demanding. This leads us to the next question: How?
Back in 1994, game designer Greg Costikyan stated, "I have no words and I must design " as a response to the upcoming breed of game designers' need for a common terminology on game-related stuff. Since then, an extensive terminology has been created, collected, and discovered, as well as theories on how to run development and test the ongoing design . However, there is still a dearth of idea-generation methods for games and gameplay; typically, "normal" idea-generation tools, for instance brainstorming, are described in the game design literature, whereas more direct game design methods are lacking or only briefly described.
For the professional game designer, constantly looking for inspiration and playing what-if, this may not be a problem, but the rest of us may need a hint. Therefore, I take the opportunity to present a set of methods for quick idea generation. All of them have been tested numerous times with gamers, students, and people interested but inexperienced in game design. Since most of them were developed as parts of workshops, they are between three and eight hours long. You can use them to come up with game ideas or to explore (perhaps when teaching) the close connection between a changed rule and a change in gameplay, i.e., how one design decision can affect the entire outcome. These methods are intended for groups of at least two but preferably four people. And most important, all of the methods can be used to design any type of game. A board game. A card game. A computer game. An outdoors game. A game played with mobile phones, indoors or outdoors, or perhaps over time. A game played with a Wii control or a dance mat. A game played with nothing more than a set of dice and an ability to bluff . Any kind of game.
The participants start out by playing a dysfunctional game of some sort, like a game based entirely on luck or one that is "broken" in some aspect (it may never end, it may be boring, it may be frustrating...). The game's rules should be fairly simple; public-domain games for children (like Memory, or simple card games) can be good candidates. The game is played and analyzed in terms of what mechanics or patterns it contains and how these affect not only gameplay but also which kinds of feelings they evoke (e.g., lack of control may result in either boredom or stress). Sometimes it helps to draw a kind of pattern map to see interconnections. Then, possible rule changes are suggested, discussed, and tested. A new analysis is made and so on.
There are two benefits with this method. First, one does not have to come up with anything from scratch. Second, being a game design newbie is fine; anyone can improve a broken game, which can be good for one's self esteem. However, some may feel that it is "cheating" to take someone else's idea (even if it is a public-domain idea, like card games). Whether this is a problem or not depends on the aim of the exercise; if it is to come up with an original game to publish, this may not be the way to go. If, on the other hand, it is the first in a series of exercises aiming to teach game design, this is not a problem at all.
This is a variant of "redo it right," wherein the participants make the initial analysis the same way but then decide to design for one of the emotions that the game evokes. Trying to design for a feeling, rather than a theme, will result in rather different design choices! One can stretch the design process in absurdum toward the chosen emotion and then "bounce back," using this extreme variant of the game as a new "broken" game that one has to fix and make more playable by changing or removing parts of it.
By designing for an emotion (especially a not-so-pleasant one!) one opens up the design space for unusual ideas. This is very useful, but one must be aware that the most extreme variants are seldom "playable" in a wider context. They may not even be possible to redesign, but one may still find useful ideas in them that may otherwise not have been found. It's a bit like using extreme characters  instead of personas as a design tool.
Originally, this was an exercise for designing board games (hence the name; a D6 is a six-sided dice), but it can just as well be used to come up with ideas for any kind of game (if so, the time may have to be extended). The idea is that each group of participants starts with one game component (a six-sided dice, or a card, or a score track, an item or a graphic image). A participant may add a rule to the game, and thereafter the next participant may add or remove rules or components. Every once in a while the game is play tested. This carries on for about an hour, and the aim is explicitly to not "finish" the game but to deliver a "baby" game in need of further development. Then two groups meet and present their respective games to each other, after which point they spend another two hours refining the design of the other group's game. They meet again, demonstrate what they have done, and get their own game back with a final hour to refine it.
This method is very effective, since the ideas undergo a constant testing and questioning due to the rotation of design ideas. Interestingly, the fact that the games will not be fully described during demonstration (and there is rarely a comprehensive written description) often leads to new ideas or other manners of play based on misinterpretations of the rules, widening the design space. Also, the games benefit from being played by different groups of players since different groups may have very different player styles (aggressive, helpful etc.), which also highlights different strengths and weaknesses of gameplay. These two effects may result in some groups being astonished or disappointed when their "baby games" are developed further in a way that they had not expected!
This method can also help if you want to design a game for a certain device (i.e., a cell phone); the device, with all of its functionality, is the start item instead of the dice.
In this exercise, participants list a set of opposites, e.g., rich-poor, introvert-extrovert, nomadic-stable, hot-cold, science-New Age . Thereafter, each group chooses two sets and uses them to create a diagram with four quadrants combining the two opposites. They then try to imagine four future worlds (one for each quadrant) strongly characterized by these properties.
These future worlds are then used for inspiration. Either the worlds themselves become the environment of the games (e.g., a first-person shooter game set in a post-holocaust world), or one can take imagination a step further by trying to come up with what kind of games would be played in this particular future. Both approaches can result in very odd game ideas, but the latter may be more demanding. However, it can also be more rewarding; during a workshop in 2001 , this approach led to the idea of MultiMonsterMania a collectible card game system in which some cards had programmable content and others had DNAthe patient could breed monsters The background was a world with lots of self-expression and large gaps between the rich and the poor, and MultiMonsterMania was a cross-society game that street kids could use to get money, either by programming cool stuff or breeding cool monsters.
This method can be used to widen the design space, especially if creating games for that world, but unlike the other methods, it sets the conditions for the game, rather than stating anything about the game itselfa potential downside. Also, there is a risk that all the creative effort goes into imagining the worlds, leaving nothing for the games. This is of course easily solved by letting the exercise run over two occasions. Also, if more than one group is doing this, they can benefit from describing their worlds to each other; any group may then pick any world that inspires them.
Gameplay design patterns are a way to describe the patterns, or parts, of gameplay and the interrelations between them. Patterns can be high level and deal with emotional outcomes (e.g., tension or immersion). They can be very low level and deal with components (e.g., dice, cards, or avatars). They can also fall somewhere in between, dealing with interaction (e.g., bluffing, betting, movement, and so on), information (e.g., symmetric information, public information etc.), or game conditions (e.g., safe havens, race, rewards, etc.). There is a collection, by Holopainen and Björk , but even without this you can find and name the patterns you would like to use.
Gameplay design patterns can be used as a starting point for game design. Pick two or three and set them as a requirement; the game must include these in some way. Interestingly several groups using the same patterns will still come up with very different games. For instance, I ran a workshop in which three groups designed games using the pattern Real-Time Game and either cooperation, espionage, or a team or outdoor game . The result was one mobile phone game about a race across the polar regions, another mobile phone game played in the city that was now populated by monsters and treasures, and one Pictionary-like camera game.
In this exercise the participants receive constraints in forms of components (if they are going to design a board game) or graphics (for a computer game). They must use only some, not all of the components. Again different groups will come up with very different ideas.
Here the choice of components will affect design more than you can believe. Small things like color (coding) may matter a lot as may things like different shapes so it is worth designing or choosing these with care
The methods I describe have their own pros and cons "Redo it right" is by far the easiest for non-experienced gamers because there is an existing set of rules "Gameplay design patterns" is the most complex tool; it takes time to get to know, but as any other comprehensive tool (the collection contains more than 200 patters), it is very useful once mastered.
"D6" and "creative constraints" are much each other's opposites, D6 being very free, while creative constraints can be very limited, depending on how many components you provide and how many have to be used. Having tried out both in several cases, I would say D6 works slightly betterwhen trying it on a class of interaction designers and game designers, some four games out of 14 were promising. I've tried creative constraints only as a game design competition with time pressure added, which does not work well; this task may work better if the participants can review the material beforehand. On the other hand, most of the material is already designed, so the focus is much more on actually designing the gameplay than making the perfect components, as in D6.
Actually, there is an imminent risk that prototyping or programming issues may interfere with gameplay design. This can be countered either by sticking to lo-fi prototypes and/ or bodystorming if necessary, or by involving experienced programmers, or by limiting the scope to designing board or card games only. Also, you must be a bit cautious in what materials you choose to display; D6 and creative constraints are highly dependent on what prototyping material you provide as inspiration. The others, not so much. It all comes down to what type of game you wantfor instance, if you provide dice markers, etc., you will most likely get a board game. In order to skew the ideas toward, say, a live action game, you will have to provide more everyday-life thingsprops like bags or bizarre hats or water gunsperhaps some maps, and last but not least, a means of communication like PDAs or mobile phones. In order to get computer-game prototypes, you really need to have skilled programmers in the group, and preferably someone good at graphics as well. Then you must provide hardware, software, an image-, texture-, and sound library and anything else that may get them going. If you want more unpredictable outcomes, you can provide things like cameras (always tempting), LEGO Mindstorm, perhaps an AIBO robot dog, and other intriguing things... like whatever is in your bottom kitchen drawer right now. And always provide paper of different sizes (and cardboard if you have some) and pencils of different colors!
"But," you may be wondering, "doesn't it require a certain amount of game knowledge to do all this?" Well, as with anything else, experience helps when designing a game. However, this experience can come from different sourcesfor example, from playing games of any kind. Or it can come from that instinct we designers work so hard to achieve, the gut feeling telling us when something actually is interesting, entertaining, or "working," and why. As a matter of fact, if everyone is inexperienced in game design, it's often the interaction designer who carries forth the strongest ideas, simply because of this valuable and carefully trained ability. This may come from having user tested one's designs every so often, which may not be the case for everyone. Actually, designing a game (or the embryo of a game) and then letting others test it is not at all different from running some other kind of user test, like, for instance, thinking aloud. And we all know how to do that!
Still, the methods mentioned above will not work for everyone, every time. But if a method doesn't work for you, try another. Or, if you like the method, try it out with others. Since a method takes a maximum of eight hours (but typically four) to carry through (although, admittedly it may take longer if prototyping requires a lot of time), it is not time-consuming to try out two or three.
If you use any of these methods to teach, make sure to divide any gamers among the rest so that each group can benefit from having an experienced gamer. Also, make sure to point out to your students how much a small change of a rule can change the entire experience of a game; imagine, for instance, a game of chess where the goal is not to strike the opponent's king but all of her or his pawns. This small change has a huge effect on how the game is played. (Try if you don't believe me!)
Wishing all of you the best in your gameplay design endeavors, I'd like to end with a tip I've gotten more than once when interviewing game designers of different kinds: Start with only a few components and rules, make a very simple game, and add complexity with care. And, as they always say on the telly: Have fun with it!
Oh, about the three and a half solutions to the negotiation problem (and note that using voice-based interaction is not allowed), here goes: (1a) You can assign each of the negotiating players an area and let everyone drag and drop the jewels to and from these areas, (1b) and you can also turn this into a kind of turn-based distribution. (2) Or, you can let all the jewels lie still and let each player mark their interest in a particular jewel instead. Each of these three solutions requires ways for the players to agree or disagree with what is going on. (3) Or, you can let all players get their own subset of the jewels, each suggesting how they think the entire division should turn out. Here, players need to be able to agree with one or several of the other's suggestion.
Regardless of the solution, players also need a means of showing that they want a particular jewel particularly, or if there is someone to whom they won't give a certain jewel. Also, regarding color-blindness issues, it is not a good idea to keep all the nine colors as is; working with shapes is necessary to facilitate jewel recognition for everyone . Oh, and by the way, that's another method of exploring unusual interaction design problems: Take a board game and make an online version of it.
2. "I have no words and I must design" was originally published in a British roleplaying journal, and features Greg's definition of a game as well as a list of different game-related things. It's still available online at: http://www.costik.com/nowords.html
3. See for instance Salen and Zimmerman's Rules of Play: Game Design Fundamentals, MIT Press, 2003; or Fullerton et al Game Design Workshop: Designing, Prototyping, and Playtesting Games, CMP Books, 2004; or C. Crawford's Chris Crawford on Game Design, New Riders Games, 2003. Even I myself have proposed a method for multidisciplinary game design: S. Lundgren, "Facets of Fun: The design of Computer Augmented Entertainment Artifacts," Master's thesis, Chalmers University of Technology and Göteborg University, 2006, 159186. <http://www.cs.chalmers.se/~lundsus/publications.html>
5. Extreme characters is a design method where one creates very odd characters to design for, i.e. red-haired, shy, left-handed terrorists. The aim is to let darker emotions and desires influence the design for once. See Djajadiningrat et al "Interaction Relabelling and Extreme Characters: Methods for exploring aesthetic interactions," working paper, DIS 2000, New York, N.Y., 2000.
7. See special issue on ubiquitous gaming: S. Björk, J. Holopainen, P. Ljungstrand, and K.P. Åkesson, "Designing Ubiquitous Computing Games - A Report from a Workshop Exploring Ubiquitous Computing Entertainment," Journal of Personal and Ubiquitous Computing 6. no. 5 and 6 (December 2002).
9. See S. Lundgren, "Facets of Fun: The design of Computer Augmented Entertainment Artifacts," Master's thesis, Chalmers University of Technology and Göteborg University, 2006, 145153. <http://www.cs.chalmers.se/~lundsus/publications.html>
Sus Lundgren is currently pursuing a Ph.D. in interaction design at Chalmers University of Technology, Gothenburg, Sweden. She has a background in game design research and has worked with Web design and GUI design for several years. She also owns some 400 games.
Figure. These (plus some dice) were the components I provided for the first creative constraints workshop I organized. When designing the components, I thought the coupling between the colors on the cards and the colors on the boards was too obvious, but not all groups used this connection. In addition, all groups but one got typical player pieces (like the ones to the right), but I did not have enough, so one group got small sturdy cylinders instead. Sure enough, they used the fact that these could be stacked!
©2008 ACM 1072-5220/08/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.