Archive for the ‘Uncategorized’ Category

“I just found this blog, what do I do?”

September 9, 2009

This course was originally offered in real-time from June 29 – September 6, 2009. If you are just finding this now, does that mean you missed out on everything? Not at all. The course content is still here and available for you. Going through the course just requires some minor modifications. Consider the following as your guide to the course if you are just starting out.

Follow the posts in order.

Start with the schedule and syllabus to get an idea of what this course has to offer (ignore the dates, of course). If it sounds intriguing, you’ll also want to order Challenges for Game Designers as it is a required text, and the recommended A Theory of Fun and Understanding Comics. The purpose of these books is explained in the syllabus.

Then, when you are ready, move forward to June’s Level 1 post. This is the official start of the course. From there, move forward to the next post, and the next, and so on all the way up to Level 20 when the course is finished.

Suggested Schedule

This summer, we went at a fast pace: one blog post every Monday and every Thursday (so, two per week), which let the entire course fit into 10 weeks. If you have plenty of free time, you may be able to go at this pace on your own, but if you are in school (or have a full-time job) then I would suggest a slower rate.

To extend this to a 30-week course, go through the first half (Levels 1 through 10) at a rate of one post per week. Go through the second half of the course (Levels 11 through 20) at a rate of one post every two weeks. This will give you a lot more time to spend on your Design Project, and you will be grateful for it. Allow yourself “vacations” from the course at 10-week intervals, to give yourself a break and to let the material really sink in.

Participation

Naturally, since you are not going through this course at the same time as everyone else, you will not have access to the discussion forums or write access to the wiki, and posting on Twitter will not be as meaningful. Whenever the course asks you to use the forums, wiki or Twitter, simply put this in a document of your own and keep it for yourself. You do not need to post it anywhere.

If you have any questions or comments on the course content of this blog, please leave comments! I do get an email whenever someone leaves a comment, and I can still respond to posts here. As time goes on and more people leave comments, the course material just gets stronger and stronger.

This course works better if you take it with friends. If you have a group of friends or colleagues who are willing to go through this with you, instead of keeping your work to yourself, share it with your friends. Meet on a regular basis to discuss the course topics and share your projects.

When you’re done… There’s another course on the topic of game balance, if you’re interested in that! Go to http://gamebalanceconcepts.wordpress.com and continue.

Level 20: Course Summary and Next Steps

September 3, 2009

Here we are, at the end of the course. I appreciate the time that you have put in, if you have read this far and stayed with me from beginning to end. I hope that you got out of this course something of more value than what you put in.

We’ve covered a lot of topics in this course. We started by building the beginnings of a critical vocabulary to allow us to talk about games and game design. We looked at the process of designing games, particularly the advantages of rapid prototyping and iteration. We broke down the concept of “game” into its formal elements, and learned to analyze each element individually. We talked about common concepts that come up in game design: the MDA framework, feedback loops, emergence and intentionality, flow theory, kinds of decisions, kinds of fun and player types. We looked at narrative and the various roles it can play in a nonlinear game experience. We looked at games not only as entertainment, but also as an art form and an educational medium.

And, of course, we made games. Lots of games. Some little ones, and one longer project (which I’m sure you all feel now was way too short, even though you worked on this for a full month). We dove right in, applying the theory in order to make a game. Along the way, we discussed techniques for playtesting (in all its incarnations), balancing, and designing the UI for the game.

At this point, you might be wondering… what next? If this course is over, what are the next steps on this journey towards becoming a better game designer? And when does it end?

Lifelong Journeys

Since none of us are perfect or will ever be, there is always a way for us to improve. If game design is your passion and you want to design better games, you’ll continue to improve over time, and this is a process that continues for as long as you make games.

No, the journey of a game designer does not end. But it does get more interesting, because you can put higher-level concepts together much easier. The kind of thing that used to take you a month eventually takes you a week, and the rest of that time can be spent doing even more for your games.

You might wonder, then, what is the next step on this journey? I have created a page on the course wiki with my thoughts, so visit over there (and leave your own thoughts) if you are done with this course and you want to get to the next level.

Some Other Questions You Might Have

There are some questions I’ve been asked a bit during this course, about what happens when it all ends. Here are my answers.

I want to pass some of this material along to other students/friends/colleagues. Can I get the rights to use it? Can I link to it from my own blog/course/whatever?

I’ve received a number of emails asking about permissions, and I have just upgraded the blog with a fresh new Creative Commons license that should make it clear. Bottom line: feel free to use any or all of the content that I’ve posted here. I created this class to share information, after all. However, please do credit me as the original source if you use my content. My name is Ian Schreiber, and the title of this course/blog is Game Design Concepts.

I came to this class late / I fell behind, so now I’m on my own. What happens to this course now that it’s technically “over”?

I plan to leave this blog right where it is for posterity. Anyone who finds it later can feel free to drop by, going through the course on their own time and at their own pace. They won’t be able to participate with other students as the course is happening, of course, but the material is still all here.

The course wiki will remain exactly as it is, readable to the public. By popular demand, the course forums will remain as they are, allowing those of you who signed up to maintain a community.

Are you teaching this class again?

At present, I have no plans to do an exact repeat of this summer. However, all of the information is here, so anyone wishing to go through Game Design Concepts can do so at their own pace at any time.

Are you going to teach any other classes like this?

Update: YES. Summer 2010, I will do something similar to this one, but with new material.

The topic for next summer is game balance. I want to go into greater detail on ways to take an existing design and get it feeling right: identifying feedback loops and other relationships in a game, cost curves, metrics, randomness, payoff matrices, and similar topics. It’s an area of fascination for me, and I would love the opportunity to share what I have learned among a community of like-minded game designers and hobbyists. Since Game Design Concepts is experimental in nature, I’d like to take the opportunity to go into an experimental topic, the kind of thing that I would probably not be allowed to teach at most schools because it is too specialized. No textbook for it exists (yet). I’d like to write one, some day, but I’ve learned to not write a textbook unless you’ve taught a class in it first. In Summer 2010, I’ll teach that class, and I am already looking forward to it.

The course blog for Game Balance Concepts is at gamebalanceconcepts.wordpress.com. Details for signing up are on that site.

And Now, Some Shameless Plugs…

Game Design Concepts reached a lot of people. As you see in the sidebar, there were over 1400 people who sent an email to formally sign up for the course ahead of time, covering nearly every state in the US and an additional 47 countries. Here are some other stats for the interested:

  • 400+ game industry professionals (including 160+ professional game designers)
  • 200+ teachers and educators (including 60+ who teach game design)
  • 400+ students, ranging from middle school to graduate school
  • 350+ people who signed up in a group (that is, not alone), forming 120+ groups
  • All of the above is just for people who signed up in advance. There are, of course, many more who visited the blog but did not formally sign up ahead of time.
  • Starting out, the blog had 6,000+ unique visitors for both if the first two lessons, with 13,271 hits in the first week total.
  • More recently, we get about 1,000 hits when there’s a new blog post, and about 400 on days in between posts.

So, if you’re reading this, you are in good company.

As a result, I ask the following:

  • Do you work for a school or company that would be interested in sponsoring next year’s course? I can offer your logo and link on the main blog page, and mentions at the end of each blog post with your message. Your message could be seen by thousands of repeat visitors. Contact me by email to receive sponsorship info.
  • If you are a professional educator (teacher, professor, etc.) at an institution that offers online classes: would you be interested in an adaptation of Game Design Concepts for your institution? I can do that for you. Are you looking for game design professors to teach an existing online class? I can do that, too. Contact me by email, and let’s talk.
  • Do you work at a game company that may eventually look for a freelance game designer on a short-term contractual basis? Ask me for my full contact details by email. Résumé and references available on request.

Also, if you liked the textbook, my co-author and I would appreciate if you’d leave a review on Amazon. For as many people as have bought the book, there are currently very few reviews, and it would be nice to see that change.

Course Evaluation

Update: This survey is now closed, but you can still send email to me directly if you want to comment on the course.

At the end of most college courses, students are given an evaluation to fill out. It asks all kinds of questions about the strong and weak points of the class and the professor. The answers are collected, compiled, and given back to the professor. I continue this tradition here.

I want to know what I did right, and more importantly, what I did wrong.

I have set up a survey here: http://survey.constantcontact.com/survey/a07e2kh03mmfz3laohv/start

If you are reading this at all, I would like to hear from you. This is true whether you originally signed up for the course, or came in late; whether you kept up with the coursework, or not; whether you enjoyed yourself or whether you thought this was a complete waste of time.

Go there and fill out the survey. I’m asking you to do this as a personal favor to me, in exchange for the time I have given you in putting together the content for this course. Your responses help me to make things even better next year. Thank you.

Final Words

I would like to thank you for your interest, your participation, and your time. I wish you well, in games and in life. Keep playing, keep designing, and keep learning.

– Ian Schreiber

Level 19: Game Criticism and Analysis

August 31, 2009

If you have made it this far and kept up with the course in real time… then you have a strong will, and a lot of free time.

Take a step back and look at what you have done. And realize that this is not the end of your journey, but the beginning.

Today, we switch gears for a bit and turn our attention to game criticism. Why do we care the least about game reviews or critiques or game journalism or any other form of game writing? Because without the ability to analyze a game, we might make games and then be unable to discuss them amongst ourselves, and thus be unable to improve on them.

A game designer does not have to be an expert critic (nor vice versa), but an understanding of how to critically analyze games is a useful skill to have. With this ability, a designer can learn more by playing other people’s games, figuring out what works and what doesn’t (and why), and applying those lessons to their own designs. It’s far cheaper to learn from other people’s mistakes than your own.

Readings / Viewings

Read the following:

Critical Analysis

I have mentioned before that an important game design skill to have is the ability to critically analyze other people’s games. I think about half of the reason why I am as far along as I am in my career, personally, is that I have the ability to play a game and offer direct constructive feedback that is useful to another designer. My usefulness to designers makes me friends in a lot of places, and I want you to have the same opportunity.

Consider your own Design Project to be, if not finished, then at least “handed in” (if this were a normal class). Put it aside, and let us examine some other projects. It’s good practice, and it may even make you some friends that extend beyond this course.

This time, we will follow a process that is a bit different than before. We are going to take off our game designer hats for a moment, and put on our game critic hats.

Review and Critique

We don’t hear the words “game critic” very often. Especially with video games, more often we see “game reviewer.” Review. Critique. Reviewer. Critic. Are these synonyms? What is the difference?

As Costikyan points out, the difference is in the purpose of the writing. In short, a reviewer is aiding the consumer in making a buy-or-don’t-buy decision. A critic is writing about a game and why it is or is not important, or valuable, or what have you. Since we often hear the term “game journalism” as well, I would add that a journalist is writing about news in the field. Thus, a reviewer writing about Settlers of Catan might say that it is an excellent game that you should buy right now; a critic might write of its historical importance in bringing Eurogames to the US, or an analysis of its mechanics and how the game deals with minimizing player downtime, balancing luck and skill to make it accessible to all ages, and so on; and a journalist might write about a new game in the series getting released, or a new publisher getting the rights to the game, or the designer getting married to a famous celebrity, if any of those things ever happened.

For game designers, it is critique that is the most important, because critique can directly inform our present and future designs.

Not all critique falls into this category. A critique of Chess as a patriarchal game that pushes an anti-Feminist agenda would not be particularly useful if you’re just trying to design a compelling strategy game, sans social commentary. But another critique of the same game might speak of the mechanics and dynamics, what is effective and what is not, and how it all fits together to make the kind of game that has persisted for centuries. And that would be quite useful, wouldn’t you say?

Critical Analysis of a Game: the Process

First, go to the course wiki and select any one game (other than yours). Feel free to browse the projects that are posted, looking at the brief descriptions and photos at the beginning, and pick one that looks like it might be interesting. Do this even if you did not complete your own project yet.

Next, download the components. There should be enough there for you to build the game. You can make a quick-and-dirty paper prototype that contains all of the information, or you can print it out on simple paper. You can even follow the included instructions to assemble your own high-quality version, although this may take more time and money than you’re willing to spend right now.

Next, read the rules and then play the game. You can try playing on your own if the mechanics allow it, or play with one or more friends if you get them together for one final playtest session. Play as a designer, paying attention to the mechanics, dynamics and aesthetics (in the MDA sense).

Lastly, reflect on your play experience. What were the game’s apparent design goals? Did it succeed at those goals? Why or why not? What were the mechanics? What was the play experience? What is the relationship between the two? Did you find any strategies that were exploitable, or did the game seem well-balanced? What kinds of interesting decisions (and uninteresting ones) were you making throughout the game? What do you feel was the core of the game?

Write this up. Include the following in your analysis:

  • Name of the game and its designer (partly to get in the habit of giving credit where due, partly so that if you accidentally post in the wrong place it can be rerouted easily).
  • Description of the core mechanics of the game. You do not have to reproduce the rules, but you should describe the basic play of the game and the main decisions players are making, as if the reader had not ever played the game before.
  • Describe the MDA dynamics and aesthetics, and show how they emerge from the mechanics (or guess, if you aren’t sure).
  • State the game’s design goals. What was the designer trying to do? Then, say whether you feel the game met those goals, and why or why not.
  • If there was anything else of note in the game (such as a particular issue with game balance or a unique use of game components), say that.
  • Lastly, if you were the designer, what would you change about the game (if anything)? Make specific recommendations. For example, don’t just say “I would make the game more interactive between players” or “I would fix the problem that I identified earlier” – say how you would fix things. What rules would change, and what would they change to? Would you change any game objects or values?

Remember, your audience is other game designers. Write your analysis so that other designers can learn from the mistakes and successes of the game you chose. Your goal is to educate and inform, and to discover new lessons about what makes games work or not work. Your goal is not to give a review score.

Homeplay

Post your critical analysis as a comment on the wiki. Go to the page of the game you chose, and leave a comment. I highly recommend writing out your analysis in something else like a word processor first, and then copying and pasting when you’re done. Do this on or before the end of the course (Sunday, September 6). You will not have any other homeplay this Thursday, so take your time on this and be thorough.

You only need to do this for one game. If you want to provide feedback for more, feel free, but complete your original analysis first to make sure you’ll have enough time to do this for others.

Level 18: The Final Iteration

August 27, 2009

We are nearing the end of this adventure, so if you are still here, you deserve some congratulations.

At this point you have created a game. You have playtested your game multiple times, with multiple purposes (from fun to balance to usability). You have a list of materials that you need to assemble, and a list of things you must do to assemble them. All that is left in the Design Project is to complete it.

Readings / Viewings

None.

On Craftsmanship

One might wonder, why bother with assembling high-quality components for a game? The game is all about the mechanics, after all, and the game pieces are just a physical manifestation of the mechanics. Therefore, any pieces should be as good as any other. UI issues aside, why not just use the prototype you’ve been using and call that the final project… handwritten cards and all?

I have several responses to this.

First, if the pieces are a physical representation of the rules, you as the designer should give them the same care, so that the outer beauty of the game matches the inner beauty of the mechanics.

Second, you should take pride in your game. The physical pieces are as much a design statement as the rules. What the pieces say to a player is that the game designer felt that their game was high enough quality to deserve high-quality components. To use an analogy, if you are a chef and you’re making a simple peanut-butter sandwich, maybe you don’t mind eating off a flimsy paper plate; but if you’ve put together an elaborate nine-course gourmet dinner, find some better-quality plates to serve it on.

Third, if you plan to eventually commercialize and sell your game, the quality of the components is one of the first things a prospective customer will see. Many Eurogames actually print a nice picture of the game components on the back of the box as a selling point. They are in essence saying, “if you buy this game, you will get these fine components.” Even if you aren’t planning on selling the game you’re making right now, going through that process is good practice for future projects.

Lastly, keep in mind that your game represents you as a designer. If you ignore the one thing that every player is going to see, what does that say about you? Does it suggest that you don’t care about your projects enough to put in some extra effort? Does it mean you don’t take pride in your own work? Does it mean you lack confidence? If you are planning to use this game (or another one) as part of your professional design portfolio, think about how it will appear to prospective schools or employers. For the same reason that you might dress up for a job interview, dress your game up before you release it.

An Anti-Craftsmanship Aesthetic

You might press this even further. Some commercial games were made with intentionally poor production values. The first printing of Kill Doctor Lucky (and the rest of the games from the original publisher) had cards printed in one color on flimsy paper with just simple text and no art. The game didn’t even include common components like pawns or dice, and it was sold in a thin paper envelope with the rules printed right on the bag – there wasn’t even a separate printed manual. In the digital realm, Kingdom of Loathing is an online browser game that uses badly-drawn stick figures for all of the game art. It’s as if these people aren’t even trying, and yet their games see many players. Why not just do that with your own game?

I would argue that these games actually have very high production values. Each offers a consistent visual aesthetic and a strong impact that is consistent with the values of the creator and the game mechanics.

In the case of Kill Doctor Lucky, the whole point of the entire line of games, in fact James Ernest’s mission statement, was that games were getting too expensive because they included all these extraneous components. Why bother paying an extra dollar for two dice when you’ve probably got dozens of dice lying around from other games you own? And sure, the cards are flimsy… but if you accidentally ruin them, oh well, go out and buy the game again. The game cost you less than that mocha latte you had at Starbucks this morning.

With Kingdom of Loathing, the game is a parody of similar games. As a parody, the intentionally low-quality art style is a deliberate choice, standing in contrast to the focus on detailed visuals in other games. And any time that didn’t go into drawing stick figures went into the writing of the game, which is (frankly) of higher quality than many of the visually stunning games out there.

So, if you have a game where “low” production values make sense – maybe you’re making a game about living in a trailer park, or a game about magpies where the object is to build a nest out of the shiniest junk, or something – then by all means, craft your game accordingly. But even in this case (or I should say, especially in this case), make the quality and appearance of each component a deliberate design decision. You’ll find that it may take more skill to pull this off in a way that looks genuine than it would to just make a game with standard high-quality components.

Quick Tips

For printing cards:

  • Print on heavy card stock, not standard printer paper.
  • If you’re not printing in color, consider at least printing on colored card stock, choosing a color that matches the rest of your game.
  • Make sure the cards are readable when printed. Sometimes they don’t print out exactly as they look on a computer screen.
  • Use rounded rectangles to mark your cards in a print program, and then carefully cut them out on your own with scissors. Or, if you have a corner-cutter (available at most craft/hobby stores), use that and save yourself a lot of work. Rounded corners are gentler to hold; square corners can poke you uncomfortably.
  • If you want to get really fancy, get the cards laminated (this means cutting the corners of the lamination instead of the card itself). This will make the card virtually indestructible and waterproof, although it can be expensive. As a less expensive alternative, some hobby stores sell spray-on plastic coating that will give your cards a similar feel to standard plastic-coated playing cards. Take care to apply the spray evenly so that your cards don’t have lumps or irregularities.
  • Print cards double-sided if you can, with a standard card back. Note that the back is a mirror image of the front, so things that print on the left side of the back of the sheet will be printing over the right side of the front. Also, be very careful about double-sided printing, as even a minor offset on one side may make the entire sheet unusable. Try to get the two sides lined up exactly.

For printing a board:

  • Don’t just print on card stock alone. It feels flimsier than most game boards you’re used to. Try mounting it on flat cardboard, poster board, or foam core.
  • If you have to cut cardboard or foam core to a specific size, try a test cut in a corner first. Some tools will not cut cleanly, but instead will leave the entire edge torn and jagged and ugly.
  • Getting a large board printed on a single sheet of paper is expensive. Getting it printed on a vinyl banner is even more expensive. One low-cost alternative is to break up a large board on several standard sheets, then mount them on a firm backing. If you want to get fancier, instead of printing on normal paper, print on a full-sheet adhesive label. Then, you can just peel off the sheet and stick it on somewhere without having to worry about glue… but be careful when sticking it so that there are no creases.
  • To make a foldable board, put two smaller boards near each other and tape them together with clear tape (such as mailing tape). Leave a little bit of space between them where there is just tape (this is where it will fold). Once you mount the actual game board on top, you might not even notice the tape.

For making custom dice:

  • Print on adhesive labels, cut them to size, and stick them over the faces of existing dice.
  • Leave a little room at the end of each die face (in other words, cut the adhesive labels a little smaller than the actual dimensions of the die). This will avoid having little bits of paper sticking out around the edges.
  • For standard dice (white background, black recessed dots), the black dots may show through even after you put a label over them. If this is the case, put an extra layer or two of blank adhesive label over the face first, before applying the final label on the outside. This will reduce or eliminate the visual effect.
  • If you really want to get fancy, there are some game manufacturers that sell blank dice with recessed sides. These are ideal, because you can put adhesive stickers on them and not worry about the stickers rubbing off through repeated use. These can be hard to find, though.

Coloring your pieces:

  • If you have a lot of blank wooden pieces (such as cubes or pawns) that you want to differentiate by color, the easiest way is to fill a bowl with water and a little bit of food dye, then soak the pieces and let them dry. I suggest doing this in two stages. First, do a test on a single piece per color, to see what they’ll look like (some colors may not show up as well as others, or you may find you need to soak them for more or less time; better to find this out before you ruin your entire stock of pieces). Then, once you have something that works, repeat for all of the rest of the pieces at once.
  • You can also paint wooden pieces by hand, but it is far more time-consuming and tedious and the paint is a bit more expensive.
  • If you have plastic pieces, the easiest thing to do is check your supplier to see if they naturally come in different colors already. Doing this by hand is not easy. If you find you must differentiate plastic pieces by hand, consider using small adhesive bands or dots instead of trying to color the plastic itself.
  • If you have metal pieces and need to color them, paint is probably your best option. The same hobby stores that sell metal miniatures will probably also sell paints and other materials for you to paint them. Note that this can get very expensive and time-consuming, but if you’re using metal parts you were probably not concerned about cost in the first place.

For printing your rules:

  • The rules are the game, so don’t neglect these! Print on good-quality paper at the very least.
  • Consider if it is appropriate to “theme” your rules according to your game. For example, a game about trains might have rules laid out like a train schedule. A game about running a restaurant might have rules that are inserted into a plastic-shielded restaurant menu. A game about collecting classical artwork might have some art pieces displayed in the pages of the rules.
  • Make sure the font of the rules is readable. Don’t get too cute with custom fonts – doing this for headings is fine, but for the main text of the rules, remember that your players actually need to read them.
  • And for the love of all that is holy, double- and triple-check your rules for spelling, grammar, and clarity of writing. You did this before, but do it again – this time it counts.
  • Also check your written rules to make sure they are correct. You’ve likely made a lot of changes to the mechanics of the game over the course of the project, and the last thing you’d want is to accidentally print out an old copy of the rules before you made several key changes!

Everything is a Design Decision

If you just throw together a bunch of random components, that is a decision you made. If you hand-carved each component out of the branches of a tree in your backyard, that is also a deliberate decision. In short, everything you do for your game is a decision that you, as the designer, are responsible for.

So, make your decisions… but make them with both eyes open. Consider each component and how it fits into the overall visual and tactile aesthetic of the play experience.

Now, get out there and build the final version of your game.

Homeplay

I generally give my students in my classroom courses a single weekend to build everything. They do it, and they usually come to class on Monday very tired, reporting that they stayed up until 3am or later the night before just finishing everything.

What they don’t say (although they do grudgingly admit to it when pressed) is that the reason they stayed up so late was that they procrastinated. Looking at what has to be done to build your game, it probably seems like a pretty small task. Be warned that it will probably take a lot longer than you think to craft the final version.

But you can still finish it in a weekend.

You have but one goal this weekend: finish your Design Project. Create a final version, using the best-quality components you can find.

On Monday, if you have the means, post your game to the course wiki. I advise use of the wiki and not the forums, because the forums do not support images or file attachments. Here is what you should post:

  • A brief introduction: who you are, title of your game, what your game is about (briefly).
  • A short creator statement: why did you choose to make this game, what was your inspiration, where did you get your ideas?
  • A file with the final rule set, including a list of all required components.
  • If some of the components are custom-made (such as custom cards, dice or a board), include the computer files you used to print them (if any), and include printing instructions for any who wish to print their own copy of your game.
  • If you have the means, take a picture of your final game components (perhaps set up as a game in progress, or perhaps just all lined up on a table together) and post the photo.

Remember, you’re almost to the end! One final push of effort and you can stand back and examine something glorious that you made yourself.

Level 17: User Interfaces

August 24, 2009

If you have made it to this point, your game is hopefully coming along nicely and you are approaching the final stages of design. You may still have temptations to mess around with the mechanics, especially given the short time period allotted for the Design Project, but at this point I want you to settle on something that is at least “good enough” so that you can experience the later stages of design.

Once your mechanics are complete and the game is playable, balanced, and meets your design goals, the last thing to do is figure out how to construct the final version. This is not simply a matter of drawing up some art for your cards and board and sending it off to the printer. There are some considerations to be made concerning the user interface of your game, and those considerations are what we will talk about today.

Readings / Viewings

Read the following:

  • Challenges for Game Designers, Chapter 16 (Creating a User Interface)
  • Cooperation and Engagement, a Google tech talk by game designer Matt Leacock. This video actually ties together a lot of the concepts we’ve talked about in this course, from difficulty levels and flow states to the iterative process to game narrative, and it should serve to solidify those concepts using the concrete example of Pandemic, one of the best-selling hobby games of last year. But what I really want you to pay attention to is how Matt presents his iterative work on the design of the game components themselves, such as how he determined the shape, orientation and color of the cards. The actual talk is only 30 minutes long, although there are an extra 20 minutes at the end from audience Q&A.

What is a User Interface?

Normally, we think of the term user interface (or UI) as it applies to software applications. This term refers to the parts of the software that interact directly with a human. It covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). In general, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).

What if you’re making a non-digital game? Is there a UI? Of course there is – and if anything, it is more important to get it right, since you don’t have a computer automatically enforcing the game rules. If the players don’t understand the rules of a non-digital game, the only recourse is often to stop playing. As the game’s designer, the last thing you want is for your brilliant mechanics and carefully-crafted play experience to be ruined because of an interface issue.

In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.

User Interface Design

What makes one UI better than another? We generally talk of two things:

  • Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?
  • Ease-of-learning. If you are new to the game, how easy is it to figure out what you are allowed to do and what information is available to you?

In practice, there is often a tradeoff between these two. For example, on computers, the presence of special “hotkeys” (Shift/Alt/Ctrl/Cmd key combinations and the like) saves time by making it fast and easy to perform common tasks like saving a file or switching between applications. But if these are the only way to perform that task (as is the case with some older word processors that lacked menus), it makes the applications difficult to learn for the first time.

In board games, you often see this tradeoff with how information is presented. Charts, tables, keywords, special symbols and icons – all of these make it much easier for an experienced player to get a quick summary of the game state, but they can be confusing and intimidating to the novice player who does not know what these things mean. The alternative, writing everything out in longhand, makes it much easier for a new player to see immediately what everything does… but it also makes the game take longer for players who already know the rules and do not need them repeated in full on every card.

Sometimes you can include both. Modern software applications include hotkeys and menu items, and some even have a “beginner” mode that hides advanced functionality to keep the menus simple, making the software much easier to learn. Card games like Magic: the Gathering include keywords, but then explain those keywords in parentheses for players who do not know what the keyword means.

MagicCards

Look at all the mechanics in your game, and what players must do in order to follow them. Are there any cases where your wording could be clearer for first-time players? Are there situations where experienced players of your game feel like they are doing excessive book-keeping or note-taking, or performing multiple automatic steps, where it would be possible to streamline the experience?

The Two Models of Usability

In usability for computer applications, there are two related concepts: the user model and the program model. The user model is how the user (i.e. the player) thinks that things should work. The program model is how the software actually works. (In non-digital games, you can think of the “program model” as the actual rules of the game as intended by the designer, and the user model is what the players think the rules are.)

Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the player is going to do something, they’ll expect one thing to happen, but another thing happens instead. With computer games, this leads to frustration, and reviewers will say the game has “poor play control” (often without fully understanding why).

In board games, if the player model and the “program” model are different, the players will just play the game incorrectly. Sometimes, this means the players will have a suboptimal experience, because some aspects of the game will feel unbalanced. Other times, the players will have a perfectly good time, but when they later play the game with other players who are playing the game the “right” way there will be rules arguments.

Changing the User Model

It is common to see a user/program model mismatch during playtesting. Here is what it looks like: with every playtest group, the players always do one particular thing wrong the first time around. This suggests an ease-of-learning problem.

A more serious case is an ease-of-use problem with the UI of your game. It looks like this: one or more players accidentally do something wrong in the rules. You point it out to them, and they correct their behavior. But then they forget, and they do it wrong again on the next turn. And the next. And the next. And your players apologize to you for continuing to get it wrong, and they feel like idiots.

In cases like this, it would be ideal to change the user model. That is, you’d like to change your players’ expectations or actions in order to match the “correct” model of the game itself. Unfortunately, in practice, this is effectively impossible to do. People are creatures of habit. We build up elaborate mental models of the world around us, and we rely on those models greatly. Changing a model is a slow process that requires great effort on the part of a person, and most people are not going to put that kind of effort into your game.

To illustrate this in my classroom courses, I tell the story of the design of a fighter jet. Once upon a time, the military was noticing that one particular type of aircraft had a much higher-than-average number of accidental pilot ejections (that is, the pilot’s ejection seat was activated when the pilot did not intend for that to happen). Given the cost of military aircraft, it gets very expensive when something like this happens, so they had a lot of engineers study the problem to figure out why the seat was ejecting, but no mechanical or electrical problems could be identified. Eventually, someone got the bright idea to look at the aircraft that the accidentally-ejected pilots had trained on. It turned out that in all cases, they had trained on an aircraft where the positions of the throttle and the ejection seat controls were reversed! So, when the pilots got in this new aircraft, they had already formed a mental model of where all the controls were, and no amount of training on the new aircraft could change it.

Identifying the User Model

Okay, so we can’t change the user model. That means if you find a mismatch between the user model and the game, you should change the game’s interface so that it either conforms to the user model, or change the interface so that it is different enough that it triggers a different user model. But how do you know what the user model is in the first place?

Thankfully, this is pretty easy to do. The easiest way is to ask. Find people who play games similar to the one you’re making. Set up a situation for them, and ask them how they think the game would work (or how they would accomplish some task, or whatever you’re trying to figure out) if they had to guess. Once you ask a few people, a clear consensus will emerge pretty quickly.

Another pretty easy way to identify the user model is to playtest. Watch when people are playing the game, and make note when they do something wrong.

Lastly, if your game’s model is nontrivial, it is probably wrong. Other things being equal, people will assume simplicity.

Whose Responsibility Is It, Anyway?

You might wonder, in some cases, if usability issues are really your problem as the game designer. After all, if you create a good game and you give a complete and correct set of rules, isn’t it the responsibility of the players to actually, you know, read the rules and follow them? If they play your game wrong, how is that your fault? Some people are just stupid or careless, and certainly the brilliant designer should not be held accountable for these people. Right?

Well, first off, it may not be the player’s fault. They might have been taught by someone else. They might be in a distracting environment, so they can’t give the rules their undivided attention. They might not have the rules; maybe they purchased the game second-hand and the rules were missing. The language the rules were written in might not be their first language. There are any number of reasons why a perfectly intelligent and rational person might have difficulty. So, don’t just write these people off as not worth your time.

Second, most usability failures feel like a mistake on the part of the user (player), but they are actually a UI issue that could be fixed. Consider: if your game were easier to use, it wouldn’t let the players make mistakes. As the designer, take responsibility for the usability of your game, and you will find that players are learning it faster, making fewer mistakes, and generally having a better time.

Building a Good UI

Now that we know how to identify a bad UI, how do you design a good one? In general, a good UI does two things:

  • It does what the user thinks it will do; and
  • It gives the user feedback so they know what it did.

If the game doesn’t do what the player thinks it will, that is a problem with the user model not matching the game model, as we’ve already discussed. But there is one other aspect to designing the UI: giving the player immediate feedback so that they know what they did is correct (and, in the unlikely event that they did something wrong, they will immediately see that it is wrong and understand why).

Here is another way of looking at what a good UI does:

  • Make it easy to do things correctly; and
  • Make it hard to do things the wrong way.

Here’s an example: suppose you have a board game with several kinds of tokens. Maybe you have one set of markers that keeps track of player score, using a scoring track around the edge of the board. Maybe the game board has a map divided into provinces, and players have military units that are placed in the provinces. Maybe there’s also a global market with goods for purchase and sale, and a separate track for each trade good that lists its current price.

It would be easy to get all these different game bits confused. But what if each token was a different size and shape, and each space on the board matched the shape of the token that was used there? All of a sudden, it becomes a lot easier to figure out that the small square tokens must go on the small squares of the scoring track, the star-shaped goods markers go on the star shapes of the trade good price tracks, and so on.

How will the players remember how to adjust the trade good values on each track? A rules summary printed on the board right next to the tracks makes it easy to remember. What about how combat is resolved? Unit strengths, stats and abilities can be printed on the military units themselves, and the remaining rules can either be summarized on the board or on a quick-reference card or other player aid given to each player at the start of the game.

As you go about designing the UI, here is a process you can follow:

  • First, make a list of tasks that players need to accomplish in the game. Make it easy to do those tasks.
  • Second, pay special attention to the most common tasks, the ones that players are doing over and over. Difficulty and complexity of a task should be in proportion to how rarely it is used.
  • Iterate through playtesting.

Use of Color

Color is a great way to convey information to players if done well. It is efficient: color takes up no additional space on a game component, because the component is already there; all you’re doing is coloring it. Here are a few quick-and-dirty tips for thinking about color use in your game:

  • The colors that normal human eyes detect most easily are red and green, followed by blue. These colors will tend to stand out more… which can be good for drawing attention, but bad for eye strain if you use fully-saturated bright colors.
  • Don’t rely on color alone; a nontrivial portion of your audience has some degree of colorblindness. Vary the intensity of colors as well (so that if, for example, photographed with a black-and-white camera, you would still see a difference), and use different shapes in addition to different colors. By having things differentiated in multiple ways (different shape, different color, etc.) it makes it really obvious that those things are distinct from each other.
  • Use color consistently. If you use one color for several things in a game, those things should be related. Some board games I’ve played, for example, have (say) five different resources, and each one has a color; but each player also has a color, and some player colors and resource colors are the same, even though there is no relationship between the green player and green resources. This kind of thing can confuse players who might think that a particular resource is owned by their opponent when it isn’t.

More UI Design Tips

In no particular order:

  • Automate or eliminate tasks that don’t involve interesting decisions, if possible. Every click or keypress in a video game, or die-roll or card flip in a board game, should involve the player doing something that is interesting to them. If the player first has to do a bunch of upkeep tasks just to have the privilege of making interesting decisions later, see what you can do to streamline the boring stuff.
  • Use visual metaphors. They make it obvious what something represents. If your players control a bunch of pieces that represent people, using people-shaped pawns is clearer than using wooden cubes. Compare the pawn images below. Each has a very different effect on how the player views it.

WoodPawns

  • Likewise, if you use icons in the game to represent certain abilities, choose icons that look like the concept they’re representing (if you can).
  • Be consistent with similar games. In an RPG, red hearts probably mean life or hit points, while blue drops probably represent mana or magic power. Why? Because that’s how everyone else does it, and your players will assume by default that you do it that way too.
  • Don’t just say “well, this is confusing, so we’ll explain it in the manual.” Remember, your players may not have the manual and they may not read it. Try to make your UI intuitive enough that your game doesn’t even need a manual.

Lessons Learned

Giving your game a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.

Further Reading

There are many great books on UI design. If this topic interests you, I would recommend Donald Norman’s Design of Everyday Things, which gets into the details of how the design of something as simple as a door or a stove can go horribly wrong… with lessons that can be applied directly to games, both digital and non. Also, for ways to show game data to players in efficient and innovative ways, I would recommend any of Edward Tufte’s books: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.

If you are primarily interested in video games, there are so many great sources on computer UI that it would be hard to list them all here. If you have any personal favorites, leave as a comment on this blog post, or post on Twitter using #GDCU.

Homeplay

The ongoing homeplay from a week ago was to arrange for a blindtest session, which should be completed on or before this Thursday (August 27). Continue working on this if you have not completed it already.

Your other task, also before this Thursday, is to critically analyze your game with respect to user interface. Think about your playtests so far, and what rules your players have had trouble with. What kinds of components or player aids would make it easier for them to remember?

Come up with a user interface plan for the final version of your game. This plan should involve the following:

  • A complete list of all game components that will be included in the final game.
  • For each component, a detailed description of what you are planning to use. If you have, say, “one pawn to represent each player”, how many pawns are included? What colors will they be? What shapes? Will they be made of metal, plastic, wood, or something else?
  • If there are cards, describe a sample card. What information will be displayed on each card? Will the card be oriented as “portrait” or “landscape”? How will the information be laid out – where on the card will each item go? How will it be displayed – what colors, shapes, and keywords do you plan to use (if any)? If there are several kinds of cards, do this for each.
  • If there is a board, describe the layout of the board. As with cards, consider what information will be displayed on the board, how it is laid out, and how it is displayed.
  • If there are other components, give similar information to that listed here.

This list is mainly for your own reference, and the purpose is to make it as easy as possible for you to assemble your final game (which you will be doing this next week). The list also serves as a sanity check: do you have access to all the components you need? If you do not own some of them, think about how and where you plan to create or purchase them.

Post your UI plan to the forums no later than this Thursday (August 27), noon GMT.

By next Monday (August 31), read and respond to at least three other posts at the same level as you, giving preference to those that have not had any responses. By reading, it may give you some ideas to use on your own project. You may also be able to share some ideas you already have with others, helping them to improve their projects.

If you have made it to this point, your game is hopefully coming along nicely and you are approaching the final stages of design. You may still have temptations to mess around with the mechanics, especially given the short time period allotted for the Design Project, but at this point I want you to settle on something that is at least “good enough” so that you can experience the later stages of design.

Once your mechanics are complete and the game is playable, balanced, and meets your design goals, the last thing to do is figure out how to construct the final version. This is not simply a matter of drawing up some art for your cards and board and sending it off to the printer. There are some considerations to be made concerning the user interface of your game, and those considerations are what we will talk about today.

Readings / Viewings

Read the following:

  • Challenges for Game Designers, Chapter 16 (Creating a User Interface)
  • Cooperation and Engagement, a Google tech talk by game designer Matt Leacock. This video actually ties together a lot of the concepts we’ve talked about in this course, from difficulty levels and flow states to the iterative process to game narrative, and it should serve to solidify those concepts using the concrete example of Pandemic, one of the best-selling hobby games of last year. But what I really want you to pay attention to is how Matt presents his iterative work on the design of the game components themselves, such as how he determined the shape, orientation and color of the cards. The actual talk is only 30 minutes long, although there are an extra 20 minutes at the end from audience Q&A.

What is a User Interface?

Normally, we think of the term user interface (or UI) as it applies to software applications. This term refers to the parts of the software that interact directly with a human. It covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). In general, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).

What if you’re making a non-digital game? Is there a UI? Of course there is – and if anything, it is more important to get it right, since you don’t have a computer automatically enforcing the game rules. If the players don’t understand the rules of a non-digital game, the only recourse is often to stop playing. As the game’s designer, the last thing you want is for your brilliant mechanics and carefully-crafted play experience to be ruined because of an interface issue.

In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.

User Interface Design

What makes one UI better than another? We generally talk of two things:

  • Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?
  • Ease-of-learning. If you are new to the game, how easy is it to figure out what you are allowed to do and what information is available to you?

In practice, there is often a tradeoff between these two. For example, on computers, the presence of special “hotkeys” (Shift/Alt/Ctrl/Cmd key combinations and the like) saves time by making it fast and easy to perform common tasks like saving a file or switching between applications. But if these are the only way to perform that task (as is the case with some older word processors that lacked menus), it makes the applications difficult to learn for the first time.

In board games, you often see this tradeoff with how information is presented. Charts, tables, keywords, special symbols and icons – all of these make it much easier for an experienced player to get a quick summary of the game state, but they can be confusing and intimidating to the novice player who does not know what these things mean. The alternative, writing everything out in longhand, makes it much easier for a new player to see immediately what everything does… but it also makes the game take longer for players who already know the rules and do not need them repeated in full on every card.

Sometimes you can include both. Modern software applications include hotkeys and menu items, and some even have a “beginner” mode that hides advanced functionality to keep the menus simple, making the software much easier to learn. Card games like Magic: the Gathering include keywords, but then explain those keywords in parentheses for players who do not know what the keyword means.

[[insert Magic Card art]]

Look at all the mechanics in your game, and what players must do in order to follow them. Are there any cases where your wording could be clearer for first-time players? Are there situations where experienced players of your game feel like they are doing excessive book-keeping or note-taking, or performing multiple automatic steps, where it would be possible to streamline the experience?

The Two Models of Usability

In usability for computer applications, there are two related concepts: the user model and the program model. The user model is how the user (i.e. the player) thinks that things should work. The program model is how the software actually works. (In non-digital games, you can think of the “program model” as the actual rules of the game as intended by the designer, and the user model is what the players think the rules are.)

Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the player is going to do something, they’ll expect one thing to happen, but another thing happens instead. With computer games, this leads to frustration, and reviewers will say the game has “poor play control” (often without fully understanding why).

In board games, if the player model and the “program” model are different, the players will just play the game incorrectly. Sometimes, this means the players will have a suboptimal experience, because some aspects of the game will feel unbalanced. Other times, the players will have a perfectly good time, but when they later play the game with other players who are playing the game the “right” way there will be rules arguments.

Changing the User Model

It is common to see a user/program model mismatch during playtesting. Here is what it looks like: with every playtest group, the players always do one particular thing wrong the first time around. This suggests an ease-of-learning problem.

A more serious case is an ease-of-use problem with the UI of your game. It looks like this: one or more players accidentally do something wrong in the rules. You point it out to them, and they correct their behavior. But then they forget, and they do it wrong again on the next turn. And the next. And the next. And your players apologize to you for continuing to get it wrong, and they feel like idiots.

In cases like this, it would be ideal to change the user model. That is, you’d like to change your players’ expectations or actions in order to match the “correct” model of the game itself. Unfortunately, in practice, this is effectively impossible to do. People are creatures of habit. We build up elaborate mental models of the world around us, and we rely on those models greatly. Changing a model is a slow process that requires great effort on the part of a person, and most people are not going to put that kind of effort into your game.

To illustrate this in my classroom courses, I tell the story of the design of a fighter jet. Once upon a time, the military was noticing that one particular type of aircraft had a much higher-than-average number of accidental pilot ejections (that is, the pilot’s ejection seat was activated when the pilot did not intend for that to happen). Given the cost of military aircraft, it gets very expensive when something like this happens, so they had a lot of engineers study the problem to figure out why the seat was ejecting, but no mechanical or electrical problems could be identified. Eventually, someone got the bright idea to look at the aircraft that the accidentally-ejected pilots had trained on. It turned out that in all cases, they had trained on an aircraft where the positions of the throttle and the ejection seat controls were reversed! So, when the pilots got in this new aircraft, they had already formed a mental model of where all the controls were, and no amount of training on the new aircraft could change it.

Identifying the User Model

Okay, so we can’t change the user model. That means if you find a mismatch between the user model and the game, you should change the game’s interface so that it either conforms to the user model, or change the interface so that it is different enough that it triggers a different user model. But how do you know what the user model is in the first place?

Thankfully, this is pretty easy to do. The easiest way is to ask. Find people who play games similar to the one you’re making. Set up a situation for them, and ask them how they think the game would work (or how they would accomplish some task, or whatever you’re trying to figure out) if they had to guess. Once you ask a few people, a clear consensus will emerge pretty quickly.

Another pretty easy way to identify the user model is to playtest. Watch when people are playing the game, and make note when they do something wrong.

Lastly, if your game’s model is nontrivial, it is probably wrong. Other things being equal, people will assume simplicity.

Whose Responsibility Is It, Anyway?

You might wonder, in some cases, if usability issues are really your problem as the game designer. After all, if you create a good game and you give a complete and correct set of rules, isn’t it the responsibility of the players to actually, you know, read the rules and follow them? If they play your game wrong, how is that your fault? Some people are just stupid or careless, and certainly the brilliant designer should not be held accountable for these people. Right?

Well, first off, it may not be the player’s fault. They might have been taught by someone else. They might be in a distracting environment, so they can’t give the rules their undivided attention. They might not have the rules; maybe they purchased the game second-hand and the rules were missing. The language the rules were written in might not be their first language. There are any number of reasons why a perfectly intelligent and rational person might have difficulty. So, don’t just write these people off as not worth your time.

Second, most usability failures feel like a mistake on the part of the user (player), but they are actually a UI issue that could be fixed. Consider: if your game were easier to use, it wouldn’t let the players make mistakes. As the designer, take responsibility for the usability of your game, and you will find that players are learning it faster, making fewer mistakes, and generally having a better time.

Building a Good UI

Now that we know how to identify a bad UI, how do you design a good one? In general, a good UI does two things:

  • It does what the user thinks it will do; and
  • It gives the user feedback so they know what it did.

If the game doesn’t do what the player thinks it will, that is a problem with the user model not matching the game model, as we’ve already discussed. But there is one other aspect to designing the UI: giving the player immediate feedback so that they know what they did is correct (and, in the unlikely event that they did something wrong, they will immediately see that it is wrong and understand why).

Here is another way of looking at what a good UI does:

  • Make it easy to do things correctly; and
  • Make it hard to do things the wrong way.

Here’s an example: suppose you have a board game with several kinds of tokens. Maybe you have one set of markers that keeps track of player score, using a scoring track around the edge of the board. Maybe the game board has a map divided into provinces, and players have military units that are placed in the provinces. Maybe there’s also a global market with goods for purchase and sale, and a separate track for each trade good that lists its current price.

It would be easy to get all these different game bits confused. But what if each token was a different size and shape, and each space on the board matched the shape of the token that was used there? All of a sudden, it becomes a lot easier to figure out that the small square tokens must go on the small squares of the scoring track, the star-shaped goods markers go on the star shapes of the trade good price tracks, and so on.

How will the players remember how to adjust the trade good values on each track? A rules summary printed on the board right next to the tracks makes it easy to remember. What about how combat is resolved? Unit strengths, stats and abilities can be printed on the military units themselves, and the remaining rules can either be summarized on the board or on a quick-reference card or other player aid given to each player at the start of the game.

As you go about designing the UI, here is a process you can follow:

  • First, make a list of tasks that players need to accomplish in the game. Make it easy to do those tasks.
  • Second, pay special attention to the most common tasks, the ones that players are doing over and over. Difficulty and complexity of a task should be in proportion to how rarely it is used.
  • Iterate through playtesting.

Use of Color

Color is a great way to convey information to players if done well. It is efficient: color takes up no additional space on a game component, because the component is already there; all you’re doing is coloring it. Here are a few quick-and-dirty tips for thinking about color use in your game:

  • The colors that normal human eyes detect most easily are red and green, followed by blue. These colors will tend to stand out more… which can be good for drawing attention, but bad for eye strain if you use fully-saturated bright colors.
  • Don’t rely on color alone; a nontrivial portion of your audience has some degree of colorblindness. Vary the intensity of colors as well (so that if, for example, photographed with a black-and-white camera, you would still see a difference), and use different shapes in addition to different colors. By having things differentiated in multiple ways (different shape, different color, etc.) it makes it really obvious that those things are distinct from each other.
  • Use color consistently. If you use one color for several things in a game, those things should be related. Some board games I’ve played, for example, have (say) five different resources, and each one has a color; but each player also has a color, and some player colors and resource colors are the same, even though there is no relationship between the green player and green resources. This kind of thing can confuse players who might think that a particular resource is owned by their opponent when it isn’t.

More UI Design Tips

In no particular order:

  • Automate or eliminate tasks that don’t involve interesting decisions, if possible. Every click or keypress in a video game, or die-roll or card flip in a board game, should involve the player doing something that is interesting to them. If the player first has to do a bunch of upkeep tasks just to have the privilege of making interesting decisions later, see what you can do to streamline the boring stuff.
  • Use visual metaphors. They make it obvious what something represents. If your players control a bunch of pieces that represent people, using people-shaped pawns is clearer than using wooden cubes. Compare the pawn images below. Each has a very different effect on how the player views it.

[[ insert picture of Meeple, people-pawn, and normal pawn ]]

  • Likewise, if you use icons in the game to represent certain abilities, choose icons that look like the concept they’re representing (if you can).
  • Be consistent with similar games. In an RPG, red hearts probably mean life or hit points, while blue drops probably represent mana or magic power. Why? Because that’s how everyone else does it, and your players will assume by default that you do it that way too.
  • Don’t just say “well, this is confusing, so we’ll explain it in the manual.” Remember, your players may not have the manual and they may not read it. Try to make your UI intuitive enough that your game doesn’t even need a manual.

Lessons Learned

Giving your game a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.

Further Reading

There are many great books on UI design. If this topic interests you, I would recommend Donald Norman’s Design of Everyday Things, which gets into the details of how the design of something as simple as a door or a stove can go horribly wrong… with lessons that can be applied directly to games, both digital and non. Also, for ways to show game data to players in efficient and innovative ways, I would recommend any of Edward Tufte’s books: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.

If you are primarily interested in video games, there are so many great sources on computer UI that it would be hard to list them all here. If you have any personal favorites, leave as a comment on this blog post, or post on Twitter using #GDCU.

Homeplay

The ongoing homeplay from a week ago was to arrange for a blindtest session, which should be completed on or before this Thursday (August 27). Continue working on this if you have not completed it already.

Your other task, also before this Thursday, is to critically analyze your game with respect to user interface. Think about your playtests so far, and what rules your players have had trouble with. What kinds of components or player aids would make it easier for them to remember?

Come up with a user interface plan for the final version of your game. This plan should involve the following:

  • A complete list of all game components that will be included in the final game.
  • For each component, a detailed description of what you are planning to use. If you have, say, “one pawn to represent each player”, how many pawns are included? What colors will they be? What shapes? Will they be made of metal, plastic, wood, or something else?
  • If there are cards, describe a sample card. What information will be displayed on each card? Will the card be oriented as “portrait” or “landscape”? How will the information be laid out – where on the card will each item go? How will it be displayed – what colors, shapes, and keywords do you plan to use (if any)? If there are several kinds of cards, do this for each.
  • If there is a board, describe the layout of the board. As with cards, consider what information will be displayed on the board, how it is laid out, and how it is displayed.
  • If there are other components, give similar information to that listed here.

This list is mainly for your own reference, and the purpose is to make it as easy as possible for you to assemble your final game (which you will be doing this next week). The list also serves as a sanity check: do you have access to all the components you need? If you do not own some of them, think about how and where you plan to create or purchase them.

Post your UI plan to the forums no later than this Thursday (August 27), noon GMT.

By next Monday (August 31), read and respond to at least three other posts at the same level as you, giving preference to those that have not had any responses. By reading, it may give you some ideas to use on your own project. You may also be able to share some ideas you already have with others, helping them to improve their projects.

Level 16: Game Balance

August 20, 2009

When veteran gamers or game designers are playing a game, if they are doing too well or too poorly, they will often comment on the game’s balance. This word is important, but I fear it is often overused. Like the word “fun,” there are different kinds of balance, and understanding what game balance is and why it’s important is what we cover today.

Why are we only covering this now and not earlier (like, say, at the start of the Design Project)? As mentioned earlier, balancing the game is something that is best left until after you have a good set of core mechanics. Balancing a game that is simply not meeting its design goals is a waste of time, and when you change the core mechanics you’ll just have to balance the game again. So here we are, with a work-in-progress that has survived multiple rounds of playtesting, and it is time to take it to the next level.

About the Pace of this Course

At this point, I realize from the comments and some forum posts that many of you are falling behind. As a reminder, this course is going at a brisk pace, and I recognize that many participants may not have the time to devote to this one hundred percent. On the bright side, the playtesting part of designing a game can go at a fast or slow pace; for your own hobby projects, time may not be of the essence, so you can continue to follow along at your own pace.

If you can still keep on schedule, that is great. If you are finding that setting up playtest sessions and modifying your game is taking too much time, my suggestion would be to do things as soon as you are able, and then follow along through the rest of this course a little behind schedule. I’m not taking this content down any time soon, so it will patiently wait for you. The rest of the course will concentrate on the Design Project and there will be no other homeplays to distract you.

I would recommend keeping up with the readings on this blog, however, if you have the time. This will give you an idea of what to look for in your project as you look ahead, and I may make announcements here that I’ll want you to see.

Readings

No additional readings for today. There is plenty of material here in this blog post.

What is Game Balance?

In a two-player game, saying it is “balanced” usually means that one player does not have an unfair advantage over the other. But we also hear the term used in relation to single-player games, where there is no opponent other than the game itself, and any “unfair advantage” the game may have could just be considered a challenge. And then we may talk of individual cards in a game like Magic: the Gathering as being “balanced” even when all players have access to that card, so it does not give an advantage to any individual. What’s going on here?

In my experience, when we talk of “game balance” we are generally talking about one of four things. Context usually makes it clear which one we are talking about:

  1. In single-player games, we use “balance” to describe whether the challenge level is appropriate to the audience;
  2. In multi-player games where there is asymmetry (that is, where players do not start with exactly equal positions and resources), we use “balance” to describe whether one starting position is easier to win with than another.
  3. Within a game, if there are multiple strategies or paths to victory that can be followed within the game, we use “balance” to describe whether following one strategy is better or worse than following another.
  4. Within a system that has several similar game objects (such as cards in a trading-card game, weapons in a role-playing game, and so on), we use “balance” to describe the objects themselves, specifically whether different objects have the same cost/benefit ratio.

Let us examine each of these more closely, and then we will go over some practical techniques for balancing your game.

Balance in Single-Player Games

In single-player games, we use “balance” to describe whether the challenge level is appropriate to the audience.

Note that, by simply playing the game and getting experience with it, your audience will eventually become more skilled at the game. This is one reason why the later levels of video games are usually harder than the earlier levels. (Recall that another reason is so that the gameplay matches the dramatic tension in the narrative.) The change in difficulty over time in a single game has a name: we call it pacing.

There is one obvious problem here that we face as game designers: how do we know what an “appropriate” challenge level is? Sure, we can say that a logic/puzzle game for adults is probably going to be harder than a similar game for young children, but beyond that… how are we supposed to know what is too easy or too hard? The obvious answer: playtest!

There is another problem, however: not all players are exactly the same. Even within a narrow target audience, players fall along a bell curve, with a few that will be highly skilled and a few that are the opposite. In your playtests, how do you know where your testers fall on that bell curve? If you are just starting out, the ideal thing to do is to use lots and lots of playtesters. When you have dozens or hundreds of people giving feedback on your game, you can get a pretty good idea of what the overall ranges are. As you gain experience as a game designer, you will get a better feel for your audience, and you will need progressively fewer and fewer playtesters to give you the same good results. (If you’re starting out but you don’t have the time or resources to do lots of playtests, you can sometimes fake it if you have some idea of where your own playtesters fall on the curve. Do they consider themselves above-average or below-average skill level, compared to the other kinds of people you’re making your game for?)

Even if you have a pretty good idea of how to modify the difficulty of your game and where your target audience falls, what do you choose as your challenge level when the audience is diverse? No matter what you do, your game will be too hard for some people and too easy for others, so this appears to be a no-win situation. If you must choose a single level of challenge, a rule of thumb is to aim for the middle of the curve, as you will get the most people (the widest possible audience) that way. Another way around this is to provide support for those at the ends of the curve, using multiple difficulty levels, handicaps, or alternate rule sets to make things easier or harder.

Balance in Asymmetric Games

In multi-player games where there is asymmetry (that is, where players do not start with exactly equal positions and resources), we use “balance” to describe whether one starting position is easier to win with than another.

Truly symmetric games are rare. We think of classic games like Chess and Go as symmetric, since each player starts with the same set of pieces and plays by the same rules, but there is one asymmetry: one player goes first! If you modify Chess so that both players secretly write a move on a piece of paper and then the moves are performed simultaneously, it becomes fully symmetric (and plays very differently).

This brings up an interesting question: if your game is symmetric, do you need to worry about game balance at all? After all, both players start with exactly identical resources and starting positions and so on, so by definition no player can have an unfair advantage. This is true, but the designer must still consider other types of balance, particularly whether there is a dominant strategy. Simply making all players equal does not get you off the hook.

Even if your game is asymmetric, why bother balancing it? The simple answer is that it is a typical player expectation that a game will not give an automatic advantage or disadvantage to certain players, other things being equal. (You can play around with this. The card game The Great Dalmutti, for example, intentionally casts players in unequal roles as a way of showing how life isn’t fair; but that is part of the game, and the instructions and mechanics go to great lengths to set player expectations accordingly. But if your game is not breaking this rule with specific intent, you should be thinking about how to make it as balanced as possible.)

Asymmetric games are, naturally, harder to balance. The more asymmetric, the more carefully the game must be playtested carefully. One of the easiest ways to confirm this kind of balance is to find ways of relating each players’ resources to one another. If you determine that in gameplay, one Apple is always worth exactly two Oranges, then a player who starts the game with an Apple will be balanced against a player starting with two Oranges.

Sometimes, players are so different that direct comparisons are impossible. Some games not only give players different starting resources and positions, but also different rules to play by. Some players may have exclusive access to certain resources or abilities. One common asymmetry in games is to give players different and conflicting objectives (for example, one team’s objective is to survive for some number of turns and the other team’s objective is to eliminate the first team before that many turns). The more difficult it is to make direct comparisons between players, the more you will have to playtest to compensate.

Balance between Strategies in a Game

Within a game, if there are multiple strategies or paths to victory that can be followed within the game, we use “balance” to describe whether following one strategy is better or worse than following another.

One might wonder, why bother with this? If a game allows for multiple strategies but one is more powerful than the others, doesn’t exploiting the best strategy just equate to players trying to win? As long as no individual player has an unfair advantage, isn’t it okay for your game to simply be “whoever finds the most powerful strategy wins”?

The problem here is that, once a dominant strategy is discovered, astute players will ignore all suboptimal strategies. Everything in the game that is not part of the dominant strategy becomes extraneous noise. There is nothing inherently wrong with a game that has a single winning strategy, but in this case the suboptimal ones should be removed to make the game more streamlined. If you include options for players that are suboptimal, these become false decisions, because really there is only one decision (follow the dominant strategy).

If it is worth including several potential winning strategies in a game, then, it becomes much more interesting if those strategies are balanced. Again, much of this comes down to playtesting. In this case, when players are playing your game, make note of whether certain strategies seem to be used more often than others, and which ones seem to win. If several items are available for players to purchase in a game, is there one that seems to always get bought early, while others seem to be used rarely if ever? If players have a choice of actions each turn, does the winner of each playtest always seem to be the one that chose one particular action more often than everyone else?

Playtesting alone is not automatic proof that a particular strategy is unbalanced, but it should give you strong signals that certain aspects of the game need closer inspection. Sometimes, players will use a particular strategy because it is the most obvious or the easiest and not because it is the most optimal. Some players will avoid anything that seems too complicated or requires finesse, even if it is ultimately better in the long run.

Balance Between Game Objects

Within a system that has several similar game objects (such as cards in a trading-card game, weapons in a role-playing game, and so on), we use “balance” to describe the objects themselves, specifically whether different objects have the same cost/benefit ratio.

This kind of balance is specific to games that give players a choice between different game objects. Some examples:

  • Cards in a trading-card game. Players build a deck with a set number of cards from their collections. The choice of which cards to add is one of the key factors in the game’s outcome, and designers try to make the cards balanced with one another.
  • Units in some war games and real-time strategy games. Players have the ability to purchase units during play, and different kinds of units may have different abilities, movement rates and combat strengths. The designer will try to make the units balanced with one another.
  • Weapons, items, magic spells, etc. in a role-playing game, either tabletop or computer/console. Players may purchase any of these for use in combat, and they have different costs and different stats and abilities. The designer will try to make these objects balanced with each other.

In all of these cases, there are two goals. The first is to prevent any game object from being so weak that it is useless in comparison with other objects. This again becomes a false choice for the player, because they might be able to gain or purchase a certain object but they will quickly find that it is not worth using; the object is therefore a waste of the player’s (and designer’s) time.

The second goal is to prevent a game object from being too powerful. Any single game object that becomes a dominant strategy makes all other objects in the game useless in comparison. In general, if you absolutely must choose between making an object too weak or too powerful, err on the side of making it too weak.

Two objects are balanced if they have the same cost/benefit ratio. That is, what you give up to gain access to an object (this includes explicit costs like in-game money or resources, and also opportunity costs like drawbacks, limitations, or exceptions to the object’s capabilities) should be in some proportion to the in-game benefits you get from the object. The costs and benefits do not have to be exactly the same (in fact, usually the benefits are greater, or else you would simply ignore the object). However, when comparing two different objects, the proportion of costs to benefits should be roughly the same for each.

Three Ways to Balance Game Objects: Transitive, Intransitive, and Fruity

I have encountered three general methods for balancing game objects. The first is technically referred to as a transitive relationship. In more colloquial (but still geeky) circles, it is called a cost curve. This is the most direct way to balance objects. The general idea is to find some desired proportion of costs to benefits. This may be a linear proportion (something twice as costly is exactly twice as powerful) or it may be curved in some way (perhaps there is a law of diminishing returns, where you have to pay progressively more for each additional bit of benefit; or perhaps there are increasing returns, where you essentially get a “bulk discount” for paying a lot at once). It all depends on your particular game, but playtesting, experimentation and instinct will help you to figure out what kind of relationship there should be.

The next step is to reduce every cost and every benefit to a single number that can be compared. Take all the costs of an object and add them together; also sum the benefits. Compare the two, and see if the object is giving the correct numerical benefit for the cost.

This method is often used in trading-card games. If the game has an established cost curve, it makes it much easier to create new cards with combinations of existing effects. In Magic: the Gathering, if you want to create a new creature with a given color, power, toughness, and set of standard abilities (say, a White 4/3 with Flying and First Strike), there are already several costs it can be, and designers working on this game (and sufficiently informed players) could tell you exactly what those equivalent costs are. Adding more abilities comes with an increase in cost, and decreasing the cost would necessitate a removal of stats or abilities.

The second method is an intransitive relationship between game objects, better known as a rock-paper-scissors relationship. In this case, there may not be a direct relationship between costs and benefits, but there is a relationship between the game objects themselves: some objects are inherently superior to others and inferior to still others. The game Rock-Paper-Scissors is the canonical example; none of the three throws is dominant, because each throw will draw with itself, beat one of the other throws and lose to the third one.

This can be seen in some strategy games as well. In many real-time strategy games, there is some kind of intransitive relationship between units. For example, one common relationship is that infantry are strong against archers, archers are strong against flying units, and fliers are strong against infantry. Part of the game is managing your particular allocation and positioning of units (in real time) in comparison to your opponent.

Note that transitive and intransitive relationships can be combined, as in the previous example. In typical real-time strategy games, units also have different costs, so a weak (but cheap) archer may still be defeated by a strong (and expensive) flying unit. Within a single class of units, there may be transitive relationships, but the different classes have intransitive relationships with one another.

Intransitive relationships can actually be solved, using matrices and some basic linear algebra. For example, the solution to rock-paper-scissors is that you expect the proportion of each throw to be equal to the others: there should be a 1:1:1 ratio. Now, suppose you modify the game slightly, so that each win with Rock scores 3 points, a win with Paper scores 2 points, and a win with Scissors scores 1 point. What is the expected ratio now? (It turns out the ratio is not what you’d expect; with optimal play on both sides, you would see 1 Rock for every 3 Paper and every 2 Scissors. The math required to do this is outside the scope of this course.) If you are looking for players to use objects in a certain proportion (with some being more commonly used than others), a well-balanced intransitive relationship is a good way to guarantee this.

A third method of balancing game objects is to make each one so different and unique from the others, that direct comparisons are impossible. (I call this “fruity” in the sense that the designer, and later the players, can only compare apples to oranges.) Since formal and numerical comparisons between objects cannot work, the only way to balance this is through excessive playtesting.

There are challenges associated with all three of these methods. For transitive relationships, everything relies on the designer finding the correct cost curve. If your math is wrong, it will be wrong for every object in the game; if you find one thing that is unbalanced, you’ll probably have to change everything. Transitive relationships are much easier to develop in retrospect after playtesting, than developing them ahead of time. Since so much relies on getting the math right, it also tends to take a lot of trial-and-error and therefore a lot of time.

Intransitive relationships, as noted above, take some tricky math to solve. Another drawback is that, unless done very carefully, their presence can make the entire game feel like glorified Rock-Paper-Scissors, which some players find to be a turnoff – many have the perception that intransitive relationships are nothing but guessing games, where every decision is based not on strategy but on luck and randomness. (A full discussion of whether this is or is not the case is also outside the scope of this course.)

“Fruity” relationships are really hard to balance, because one of the most important tools in doing so – mathematics – is no longer available.

Three General Game Balance Techniques

In general, there are three ways to balance games:

  • Use math. Create transitive or intransitive relationships in your game, and make sure that everything is in line with the cost.
  • Use your instincts as a game designer. Change the balance in the game until it “feels right” to you.
  • Use playtesting. Adjust the game based on the results of playtests, where the players are experienced gamers who have been instructed to play to exploit and win.

There are challenges with each of these ways:

  • Math is hard, and it can be incorrect. If your formulas are wrong, everything in the game may be off a little bit, which is inconvenient for rapid prototypes. Some really strange abilities or game objects may not have any math to them if they are too unique, requiring other ways of balancing.
  • Instinct is vulnerable to human error. It is also not absolute or reproducible; different designers may disagree on what is best for the game. This is particularly dangerous on large team projects, where one designer may leave in mid-project and another cannot take over (or rather, they can, but they will not be able to finish the game in the same way that the original designer would have).
  • Playtesting relies on the quality of your testers. Testers may not find every balance issue with the game; some problems will go undiscovered for months or years (even after public release of the game). Worse, some testers may intentionally avoid showing you rules exploits, because they plan to use them after the game is released!

What is a designer to do? Do the best you can, and understand both the strengths and limitations of the balance techniques that you are using. And as a game player, the next time you run into a game that seems horribly unbalanced, have some appreciation for how difficult it can be to get things perfect.

More Game Balance Techniques

Here are a few other random bits of advice I’ve picked up, in no particular order.

Be aware of the different objects and systems in your game and their relationships. You should already have done this during your initial design of the game, of course, but it is easy to forget the big picture when you start focusing on small details. There are two things in particular that you should return to first, whenever you make changes to your game:

  1. What is the core aesthetic of your game? Does this change support the core?
  2. Look at the interconnections between systems. If you change one thing, you should know what other things will be affected. Individual game elements rarely exist in a vacuum, and changing one thing can have ripple effects throughout the game. By being aware of the relationships between systems and objects, it becomes easier to predict the second-order effects of a mechanics change.

Make one change at a time. We’ve said this before, but it bears repeating. If something breaks after making a change, you know exactly why. If something breaks after making ten changes, you don’t know which change (or combination of changes) caused it.

Learn to love Excel. It can be any computer spreadsheet program, though Microsoft Excel is the most popular among game designers. Often, students look at me like I’m crazy when I suggest that a spreadsheet is useful in game design. (Like, aren’t those things only used by corporate finance dudes or something?) Here are some examples of how spreadsheets are used:

  • Excel makes it easy to keep lists of things and organize them. List all of your game objects and their stats. In a role-playing game, list all weapons, items and monsters; in a tabletop war game, list all units and their stats. Anything that you’d find in a reference chart in the instructions (or a strategy guide) probably started off its life in a designer’s Excel sheet.
  • Excel is great for keeping track of tasks and status, which is useful for a complicated game with lots of systems and components. If you’ve got a table with a couple hundred monsters and all their stats, it might also have an entry for whether the art for that monster is done, or whether the stats for that monster have been balanced or playtested yet.
  • Spreadsheets are good for collecting and manipulating statistics in your game. In a sports game where each player has a list of stats, are all of the teams balanced with one another? Sum or average all of the stats on the team, and you can get some idea of the overall strengths and weaknesses of each team. In a game with transitive relationships, is each game object balanced? Add up the costs and benefits in a spreadsheet.
  • You can use spreadsheets to run statistical simulations. By generating random numbers (in Excel you can use the RAND() function and press F9 to reroll), you can generate random die-rolls for things like damage within a range, many times, to see the overall range and distribution of outcomes. (Statisticians call this a “Monte Carlo” simulation, in case you were wondering.)
  • Spreadsheets help you to see causes and effects of changes in the game. By creating formulas based on specific values that you want to change, you can change one value and see what happens to the other values that depend on that one. For example, if you’re working on a Massively-Multiplayer Online RPG, you could use Excel to compute the damage-per-second of a weapon and then instantly see how that changes when you modify the base damage, accuracy, or attack speed.

Use the Rule of 2. Suppose you have some number in your game that you know is too high, but you don’t know how much. Maybe it’s just a little bit too high, or maybe it’s quite a bit off. In either case, cut it in half. Likewise, if you have a value that you know is too low, regardless of how much too low it is, double it. If you aren’t 100% sure of what the correct value is, double it or cut it in half. This is the “Rule of 2.”

At face value, this sounds rather ridiculous. If the cost of a gemstone is only 10 to 20 percent too low, what could be gained by taking the drastic measure of doubling it? In practice, there are some reasons why this works. First, you might think that it’s only slightly off, and you might be wrong; if you only make minor adjustments and the value really did need to be doubled, it will take you much iteration to get to where you needed to be in the first place.

There is a more powerful force at work, though, when applying the Rule of 2. Game design is a process of discovery. The fact is, you don’t know what the correct numbers are to balance your game; if you did, the game would be balanced already! If one of the values in your game is off, you need to discover what the correct value is, and you do this by changing the value and seeing what happens. By making a major adjustment, you will learn a great deal about the effect of this value on the game. Maybe it did only need a minor adjustment, but by doubling or halving the value, you will learn so much more about your game.

Occasionally, you will also find that by making such a large change to your game, it changes the dynamics in a way that was unexpected but (accidentally) superior to your original design.

Balancing the first-turn advantage. In turn-based games in particular, it is common for there to be a very slight advantage (or disadvantage) to going first. This is not always the case, but when it is, there are a few common techniques for compensating:

  • Rotate who the first player is. In a four-player game, for example, after each complete round (where every player has a turn), rotate the starting player to the left for the next round. In this way, the player who goes first on this round will go last on the next round. (When I was growing up, my game group used a pencil to mark the first player, so we dubbed this the “Pencil of Power” technique.)
  • Give the disadvantaged players some extra resources. For example, if the objective of the game is to score the most points by the end of the game, give each player a different number of points to start the game, with the last player having slightly more points to compensate for the disadvantage of going last.
  • Reduce the effectiveness of early turns for the first players. In a card game, maybe players typically draw four cards at the start of their turn. You could modify this so that the first player only gets to draw one card, the next player draws two, and so on until all players are drawing four.
  • For very short games, play a series of games where each player gets to go first once. This is common with card games, where a complete game is played in a series of hands.

Write down your own rules as you learn them. As you design games, you will have successes and mistakes. You will learn from both (especially your mistakes). When you find a “law” of game design or a new game balance technique, record it and review your notes periodically. Tragically, very few designers actually do this; as a result, they cannot pass on their experience to other designers, and they sometimes end up making the same mistakes on multiple games because they forget the lessons learned from earlier ones.

The Role of Balance

In my early days as a designer, I was very passionate about game balance. “A fun game is a balanced game, and a balanced game is a fun game” was my mantra. I’m sure I annoyed many of my seniors with my rantings on the imbalances in our games and why we needed to fix them immediately. Such is the privilege of youth.

While I still believe balance is important and a key skill for any game designer, I now take a more moderate line. I have seen some games that are fun in spite of being unbalanced. I’ve seen other games that are fun specifically because they are intentionally unbalanced. I have seen some games that have done astoundingly well in the marketplace, despite having egregious imbalances. These are rare and special cases, to be sure. But let this serve as a reminder to you that the techniques and concepts discussed today should never take priority over the ultimate design goals for your game. Let these techniques be your tools, not your master.

Homeplay

Your homeplay this past Monday was to arrange for a blindtest session, to be completed on or before next Thursday (August 27). Continue working on this if you have not completed it already.

Your other task, before next Monday (August 24), is to critically analyze your game with respect to game balance. Playtest the game once (either on your own or with others) with the purpose of finding balance issues – instruct everyone to intentionally seek out optimal strategies and exploit them. Play to win. Be vicious.

Then, from there, think of what systems and game objects are in need of modification (sometimes this is called tuning). Think about what techniques best fit your game. Are there transitive or intransitive relationships? Is it more suitable to balance primarily with playtesting, math, your own instincts, or some combination of the three?

Lastly, decide on the most serious game balance issue you identified in your earlier playtest. Make at least one change and playtest again (you can probably do this in the same test session). Did you fix the problem, or at least reduce its severity? Then, think about what other changes you might make, and what you will look for in future testing.

Level 15: Blindtesting

August 17, 2009

When your game is playtested without you (or another of the game’s designers) being personally present to observe, it is called blindtesting. This is the subject we cover today.

Readings

No readings for today. As before, if you know of any relevant readings you have encountered, post it as comments to this blog post, or on Twitter with the #GDCU tag.

The Challenges with Blindtesting

As you might imagine, blindtesting has a lot of problems compared with a playtest that you run in person:

  • Without you there, any issue the players run into is a show-stopper that prevents them from finishing.
  • Perhaps worse, the players may interpret the rules incorrectly and play anyway. If they are unaware they are playing “wrong” your test results may be skewed, and the testers won’t even know it.
  • Feedback is highly variable; as you have no doubt seen by now, some playtest groups are better than others. This problem is made worse when you are not present and cannot ask targeted questions.
  • You cannot observe in real-time. The only information you get is what the group can report back to you in retrospect. The fidelity of information is much lower than when you are present.
  • Setting up a blindtest takes a bit more time. You cannot simply bring your prototype with you to a friend’s house and play right then. You have to find a way to get a copy of your game into the hands of your testers, and then you have to leave. Then you have to wait while your testers play your game, on their schedule, and then finally get back to you with some results. Even in the best case, blindtest results may take a day or two to get back to you, which is far more than an in-person playtest which you can conduct in a matter of minutes or hours.

Blindtesting is therefore limited in the type of information it can provide, and the schedule on which it can provide it.

Why Blindtesting?

If blindtesting is so limited, why bother with it at all? What use is it?

This is a technique we borrow from science. Awhile ago, some researchers noticed that the results of an experiment would be different if the researchers are in the room. Sometimes, test subjects would say what they thought the researchers wanted to hear rather than what they actually thought. Sometimes, the researchers would give subtle non-verbal cues that neither they nor the subjects would consciously notice, but that would bias the results of the test. For example, if the experiment is a taste test between two leading soft drinks, if the researchers know which drink is which and they know which one they want the test subjects to pick, they might suddenly find that all of the test subjects are choosing the “right” drink… but only because the researchers are (accidentally) telling them what to choose!

The solution to this is the so-called double-blind experiment, where neither the researchers nor the test subjects know what the “right” answer is. This eliminates many sources of accidental bias, making the results of an experiment more valid.

Playtests share a lot in common with science experiments. In both cases there is a hypothesis (“I think this game is fun”), an experiment is designed (building a prototype), the experiment is run (the playtest), results are analyzed. The purpose of both is to find out more information about the inner workings of the system that you are studying.

Blindtests, then, are the only way to get a true idea of what your game is like “in the wild” – that is, how players will react to it if they have just purchased it from a store and are playing it for the first time, without a designer present at their table to answer questions.

When to Blindtest?

Because you can get so little information from blindtesting, it is not suitable for an early test when your game is in a rough state (the testers would likely run into problems, be unable to continue, and you would have spent a lot of time waiting for something that you could have figured out much faster with an in-person playtest. Blindtesting is most suitable near the end of development, when you already have a high degree of confidence in your game.

The purpose of blindtesting is to catch the non-obvious problems that you may not be catching in your in-person playtests, because you accidentally bias the results of the test by helpfully being available to answer questions. Even if your playtesters never have to ask you anything, the very knowledge that you could can sometimes make people relaxed enough to get through the rules, where they might otherwise get flustered and give up. Or, you might say some key piece of information when introducing the players to the game (“this is an auction/bidding game”) that is not written anywhere and clarifies a lot by creating some preconceived notions in the minds of your testers. Without you present, you’ll see just how accurate your in-person playtests are, and you may catch some surprising errors that you did not notice before.

Who to Blindtest With?

Most board games require multiple players. For practical reasons, most blindtests done with professional games are done with regular game groups. Some companies keep a list of volunteer groups and put out calls to their private list for playtesters; they will then send out advance copies of their game in exchange for feedback. For our purposes, this is unhelpful, because most of you do not work at such a company and do not have a database of volunteers to call at a moment’s notice.

Ideally, your blindtest should be with people who are in the target audience for your game. If you’re making a children’s game, your blindtest should involve kids in your target age range (and perhaps their parents). If your game is made for people who are already avid Eurogame players, you’d do well to find a group that plays these kinds of games regularly. And so on.

There are a few ways to find blindtesters for your Design Project in this course:

  • Your social network of friends, family, and colleagues. These people may be local, or they may live in another city or even another country from you. Since you don’t have to be present, at least this time, geography is not a barrier.
  • Other people who are taking this course. If you already have a local playtest group that you’ve used before, you can put out a call for help on Twitter or the forums. Offer a blindtest exchange: you’ll blindtest their game if they will return the favor with yours.
  • As a last resort, you can look outside of this course for other discussion forums or other online hangouts for board game designers and/or playtesters, and see if there is a method for recruiting blindtesters.

How to Blindtest?

With in-person tests you can afford to be a little bit sloppy. Maybe you accidentally left some of your game components at home, or some of your rules are a little unclear and need clarification. It’s not ideal, but a playtest session that runs into problems can be salvaged when you are there. With blindtesting, you do not have this luxury, so you must be extra careful to make sure that your testers have everything they need to give your game a proper playtest. This includes:

  • A complete set of game components. Double and triple check to make sure that you have everything the players need, together, in one package.
  • A list of everything that your package should contain, so that the testers can verify for themselves that nothing was left out (and if it was, it will at least give them a clue of what they need to supply as replacements).
  • A complete set of rules describing how to play. (The components list can simply be part of the rules.)
  • A separate set of instructions on how to conduct the blindtest. Is there anything in particular you are looking for the players to do? Do you just want them to see if they can play through the game? Do you want to know if they find the game enjoyable? Do you want them to try to find rules exploits and imbalances?
  • A final set of instructions on what should be done on conclusion of the playtest. How should the testers contact you (phone, email, etc.)? What should they tell you when they contact you – if you don’t give a list of questions for them to answer, you will just get whatever they happen to feel like telling you, making your results a lot less focused than they could be. Give some thought to what information would be the most useful to have, what kinds of feedback are most important to you… and ask for it!

How do you get your package into the hands of the playtesters? If they are local to you, it is as simple as taking your playable prototype and handing it off. If your blindtesters are not local, this presents additional challenges. You have two options here.

First, you can mail your prototype to them through the postal service. Depending on where they are, this step alone can slow things down considerably (not to mention making it more expensive), so plan your schedule accordingly. If you want your prototype back, consider including a return package inside the main one, already addressed to you and with postage already paid.

Second, you can handle everything over email. Send documents that can be printed out and assembled to make a playable prototype, and include instructions on how to print everything. Do everything you can to reduce the amount of work that must be done at the playtesters’ end of things. After all, you are already asking for their time in the form of a playtest; asking for another hour or two to print and cut sheets of cards is adding insult to injury. Along the same lines, try to keep the cost of materials down and availability high if you’re expecting your blindtesters to provide their own. For example, do not insist on printing on heavy card stock (which may require a special trip to a print shop) when printing on plain paper will do.

Contingency Planning

In the field, game companies do not rely on a single blindtest group, but several. Aside from the obvious reason that more tests give more data, there is also the problem that blindtest groups are unreliable. Without you in the same room, they may take awhile to organize a playtest, and they may take even longer to get back to you. Some groups may lose the components, or forget about their obligation, or they may simply be so busy with other things in their life that your game takes lower priority. Or maybe you’ll send your game through the post and it will get lost. In this course, when you set up a blindtest, you may find yourself in the frustrating situation of waiting for test results that are simply not coming… or at least, they may not arrive within the schedule you set for yourself.

You have three options for dealing with this potential hazard. It is up to you which method best fits your personal situation.

  1. You can set up multiple blindtest groups. As a rule of thumb, three is a fairly safe number. That way, if one or two groups don’t show, you’ll at least have some results. (Note that if you are doing a “blindtest exchange” with other participants of this course, that means you’ll be testing three other projects, so make sure you have time for this.)
  2. You can choose a blindtester that you know and trust to be reliable. If you are sending your game to a friend who is highly organized and always keeps their promises, you may have confidence that they will get back to you when they say they will.
  3. You can cross your fingers and hope that something bad won’t happen to you. This third method is not recommended for professional projects.

Homeplay

Your homeplay this past Thursday was to arrange for a playtest session with non-designers. You may have already performed this playtest, or you may have just scheduled it to take place over the first part of this week, but that playtest session should be concluded before this Thursday, August 20, noon GMT.

In addition, you should find a blindtest group and arrange for a blindtesting session, to take place after the non-designer playtest. If possible, you should plan to have blindtest results on or before Thursday, August 27.

Feedback

Do you know of any great articles on blindtesting? As you conduct your own session, or you’re your own personal experience if you’ve done this before, have you found any helpful tips or tricks that you’d like to share? Post in the comments on this blog, or on Twitter with the #GDCU tag.

Level 14: Playing with Non-Designers

August 13, 2009

In 2006 at GDC, game designer and academic Jesse Schell said that the most important skill of a designer is to listen:

  • Listen to your playtesters. They may not be professional designers and their suggestions may seem to make no sense. But if they react in a certain way to your game, it’s up to you to figure out why.
  • Listen to your game. Games often seem to take on a life of their own once they reach a certain complexity, and it’s more important to make a great game than to make the game that you originally intended.
  • Listen to yourself. Every time you follow your instincts as a designer, whether you’re right or wrong, your instincts get better. (This is, incidentally, why a 20-year industry veteran is going to be a better game designer than a beginning college freshman, no matter how much “natural talent” either one possesses. There are no shortcuts. This is also why I’m having you make so many games over this summer, to get you to a higher level as fast as possible.)

Today, we cover the first of these: listening to playtesters. Once you are at a certain point in your game, you will want to playtest with some new people – preferably, the people in your target market, the ones who are representative of those you ultimately want to be playing your game.

Playtesting with gamers is very different from playing with other game designers. Done right, the feedback you can get from players in your target audience is even more meaningful than getting feedback from game designers, because you are seeing firsthand how your game will be experienced by the very kinds of people who will eventually be playing the final version. However, it is a very different skill. Non-designer playtesters will give a different kind of feedback, and it takes a bit more effort to find the root cause of problems that are identified. You have to be much more observant.

Readings

No readings for today. As with last time, if you know of any relevant readings you have encountered before, post it as comments to this blog post, or on Twitter with the #GDCU tag.

Street Performers

Have you ever seen a street performer? This is a musician, magician, juggler, mime, or other person who is performing for an audience of passers-by. These people rely on donations from observers; they do not get any pay other than what these strangers on the street choose to give them. Because of this, they tend to be very good at pleasing a crowd – if they aren’t, they don’t get to eat.

During the act, the audience is obviously paying attention to the performer. But what is the performer paying attention to? Next time you see one of these people, don’t watch the act, but instead watch the performer. They aren’t concentrating on themselves or their act, the way the audience is (the performer knows their own act inside and out, after all). Instead, they are watching the audience. They are looking for interest and excitement in the crowd. If they see a positive reaction or a negative one, they will adjust their act accordingly, on the fly. Maybe this particular crowd likes magic tricks with coins but not cards, or they seem to like blues more than jazz, or they’re more excited by juggling pins than balls. The performer’s most important skill is being able to read the audience.

Note that they do not ever stop their act to ask whether people are having a good time. They know by observing. They don’t have to ask.

What Does This Have to do with Game Design?

When you are playtesting with non-designers, your role is similar to that of a street performer. Don’t simply ask your playtesters if your game is fun; they may not be able to tell you, and if they do, they may not give you an accurate or precise answer. Instead, watch your testers as they play, and take notes:

  • What is everyone’s body posture? Are they leaning forward with interest? Are they leaning back in boredom? Are they standing up from excitement?
  • Where are everyone’s eyes going? Are they scanning the board constantly? Are the players looking at each other? Are they looking at you? Or are they looking around at the rest of the room, or counting the dots on the ceiling tiles?
  • What kinds of moves are people making? Are they playing aggressively or defensively? Are players cooperating and negotiating, or are they backstabbing each other?
  • Are your testers playing the game by the correct rules, or are they playing the “wrong” way, breaking rules or forgetting restrictions accidentally? Do your testers ever get stuck and need to look something up (or ask a rules question), or are they following the game flow smoothly?
  • How do your observations compare to the design goals of your game? Is your game meeting its goals, or is it falling short?

Note that all of these things may vary during a single play session. You may find that certain parts of your game generate more engagement than others. Your goal during the playtest session is to observe these things.

Preparing for a Playtest Session with Non-Designers

People who are not fellow designers are sometimes (not always) less tolerant of extremely rough prototypes. A typical gamer, when handed a stack of hand-written index cards and instructed to move pennies around on a game board that’s hand-drawn on notebook paper, may be concentrating so much on the poor quality of components that they have trouble thinking about the game mechanics. You may get a lot of comments about missing art or board layout, which are a waste of your time – after all, at this stage you just want to get feedback on the play experience, not the final artwork. We haven’t even started talking about the appearance of the game yet!

If you are lucky enough to have some playtesters lined up who can handle a rough prototype, then you might not need to do anything. For everyone else, it may be worth a little bit of time at this point to create some components that, while not necessarily high-quality, are at least close enough to fake it.

As with your rough prototype, you do not want to put too much time into revising your components here. The more time you put in, the harder it will be for you (emotionally, at least) to make massive changes.

How do you make a prototype that looks better than hand-drawn, without taking too much time? Here are a few quick tips:

  • Google image search is your friend. If you want art for some cards or a game board, type in some relevant search terms. Copy and paste. You can do this in minutes. Steal other people’s artwork liberally.
  • For basic components like pawns or tokens, use game bits from other existing games you might already own (if you do not already have a selection of these). It gives the game a slightly more professional look than using bottle caps or pennies or pieces of lint.
  • For cards, you can create nice-looking ones in a program like Powerpoint or Visio without too much trouble. Standard-size cards are 2 ½ inches wide and 3 ½ inches tall. On a standard 8.5×11 sheet of paper, you can fit eight cards in a 4×2 grid with landscape orientation, or nine cards in a 3×3 grid if you use portrait orientation. Print out on standard paper and just cut with scissors.
  • If you want your cards to be easier to shuffle and hold, use plastic card sleeves (normally sold in game and hobby shops to protect collectible cards like Magic: the Gathering cards). Insert a standard card of some kind (either a Magic card or just cards from a standard Poker deck) so that there are uniform card backs, then add your slip of paper in front.
  • For a game board, printing it out on one or more pieces of paper is sufficient at this stage. You can create a board in Powerpoint or even in something as simple as MS Paint, using basic lines to make squares, the text tool to write text or numbers on the board, and copying/pasting art from other sources where needed or desired.
  • You may find other tools that you like to use. Feel free to post them here!

Running a Playtest Session with Non-Designers

Since you are going to spend so much time taking notes and observing, you will probably find it easiest if you do not actually play the game. You may be able to take the role of a player when testing with other designers, and you’re obviously taking on the role of all players when solo testing, but in the kind of testing we’re talking about today you should avoid playing so that you can focus all of your attention on how your testers are interacting with the game and with each other.

If you didn’t before, you should formally write out a set of rules now. Hand the rules and components to your testers, stand back, and get out of their way. Let them know that you are there merely as an observer, not as a player and not as a resource. Instruct them to pretend you are not there, and to proceed as if the designer of the game were not in the room.

Your playtesters will probably forget this often. They will run into a place in the rules that is unclear, and they’ll have to ask clarification from you. Do not answer immediately. Instead, first answer their question with a question of your own: “If I weren’t here, and you had to make a judgment call on your own, what would you think?” Their answer may be the correct one… or it may be incorrect but enlightening. Either way, it will tell you how players are likely to perceive your game by default. After your players answer you, then you may give them the answer they were seeking. But don’t lose the opportunity to get a valuable bit of information in the process.

Sometimes your playtesters may not ask you, and they’ll simply start playing “wrong.” Maybe each player is supposed to draw two cards on their turn, but they only draw one. Or they skip the first step of every turn. Or they forget to apply the effects of some tiles in play. Resist the temptation to stop them. You will find this excruciating. There are few things as painful as watching people play your game as it was not designed. And yet, this is likely how people would play if you released your game at this moment, and this is something that is important for you to see, so that you can clarify the rules and game components later.

There is one other useful aspect to letting people play the game “incorrectly.” Sometimes you will find, quite by accident, that the way your testers are playing is actually better than your original rules. Most people, even non-designers, have a strong instinct towards play. Sometimes, people will violate the rules of a game because at an instinctive level, they are playing in a way that they believe will be more fun.

Finding Non-Designer Playtesters

Here’s the good news: finding non-designer playtesters is much easier than finding other game designers. There are more of the former than the latter in the general population.

This is where friends, family, and colleagues can become useful. They are often easy to ask for a favor. For many of us, they are local and available. If you somehow know no one in your local area (maybe you just moved), consider this just one more incentive to get out there and meet people – as if you didn’t already want to.

Do keep in mind that the people that know you are far less likely to give strongly negative criticism. They may tell you it is the best game they ever played, even if it isn’t, because there is an interpersonal relationship at stake that is likely more important to them than the outcome of some game project. In other words, expect some of these people to be big stinking liars. This is where observing them closely comes in; it is up to you to figure out what parts of the game are actually fun for these people.

Homeplay

Your homeplay this past Monday was to arrange for a playtest session with other designers. You may have already performed this playtest, or you may have just scheduled it to take place over the weekend, but that playtest session should be concluded before next Monday, August 17, noon GMT.

In addition, over the weekend, you should arrange a playtest session with non-designers, to take place after the designer playtest. This session can take place at any time on or before next Thursday (August 20), but it should be arranged (that is, you should have made plans with specific people) on or before next Monday (August 17).

Time permitting, you may continue to run additional playtest sessions, either with designers or non-designers.

Feedback

Do you know of any great articles on running playtests? Do you have any favorite tools using a computer to generate quality game components quickly and easily? Post them in the comments on this blog, or on Twitter with the #GDCU tag.

Level 13: Playing With Designers

August 10, 2009

As the designer, it is an important skill to be able to playtest your own creations (which you’ve already done at least once). It is also important to be able to set up conditions for other people to playtest your games, so that you can get useful information from the precious time you have (which we will cover over the next week).

There is another side to playtesting: the ability to playtest other people’s games and provide quality feedback. This is a skill in and of itself, and a surprisingly rare one to find. This scarcity makes it a valuable skill. Personally, I have received many freelance opportunities through colleagues, simply because they know that I am good at finding the flaws in their designs. This is what we cover today: the ability to critically analyze a fellow designer’s work-in-progress.

Readings

Read the following: “Giving Criticism – the good, the bad, and the ugly!

This may not be a class on giving constructive criticism, but it is something I’m going to ask everyone to be doing. Far too often in classes, students are asked to give peer feedback and review, and yet not given the tools to do so in a useful way. I think many teachers either take the stance that simply giving feedback enough times will make people better at it (“practice makes perfect”) or else that feedback techniques should be taught in some other class (“I can’t waste precious class time on that”).

This article may not be particularly comprehensive, but it is short, and after doing a Google search for “constructive criticism” it is the one that I found that fits best with the advice I give in my classes.

The Time Barter System

At Protospiel, an annual gathering of non-digital game designers, participants are encouraged to give as much playtesting time as they take. For example, if your prototype takes two hours of play and discussion and it requires four players (other than yourself), a single playtest consumes eight person-hours of time; in exchange for that playtest, you are then expected to playtest other people’s prototypes for eight hours of your own time. This system prevents there from being an extreme shortage (or surplus) of testers relative to games, and it gives people incentive to respect each other’s time.

Notice that this means you tend to spend far more time playing other people’s games than you do playing your own. You could even say that, given the time difference, the ability to be a good playtester is more important than being able to design your own games.

Keep this in mind as you proceed through the rest of this course. You will be consuming large amounts of other people’s time as you iterate through your own designs. Accordingly, treat your testers with respect. (It wouldn’t be out of the question to give them food or some other compensation, as well, if it is in your means to provide.)

If you are in a group, playtesting with other designers should be relatively easy. Just meet up with your fellow designers. Keep in mind that you should be giving more of your time to other people’s games than your own.

Next Steps After Solo Testing

At this point in the project, you should have a playable prototype of your game, and a set of rules. You should have playtested on your own at least once, identified any really obvious problems, and iterated on your design. You should continue to do this until your design is at a point where you are confident that you can play all the way through without having to make major changes.

Once you reach that point, your goal shifts from “make this game work” to “make sure the core mechanics are fun” (or whatever your design goal happens to be, if not “fun”). Who would make the best playtesters to help with this?

Normal players (such as friends and family, or even complete strangers) are marginally useful here. By watching them, you can determine if they are having a good time and if your game is meeting its design goals. However, if there is a problem, a typical gamer will not be able to give you useful feedback other than “it’s great” or “it sucks.” It will be up to you as the designer to identify and fix the problems. Therefore, normal testers can be used if necessary, but their usefulness is limited.

Far better is to playtest with other game designers. Game designers can also let you know if the game is fun, and they can offer suggestions on where the problem points are and what can be changed to make your game better. You can often have wonderful discussion following the play of the game, on the design of your game and sometimes on game design in general. These kinds of discussions are important, and your game can get better much faster with them.

Finding Designer Playtesters

There are a few places to find other game designers.

If you are lucky enough to already work at a game company (or know someone who does), you probably already know some designers who you work with regularly. In this case, finding skilled testers is the easy part. The difficulty is that professional designers are often busy with work, and simply do not have the time to help you. You must work around their schedules. Also be prepared to offer something of value in exchange. You are essentially asking for a professional game design consult. Your colleague could spend the same amount of time freelancing and make anywhere from US$40 to $250 an hour, depending on their experience and the nature of the project. (I get those figures from personal experience and what I can piece together from what my colleagues say on the subject.) If you are asking for their time for free, be prepared to give a comparable amount of your own time to their projects in the future. At least be prepared to be extremely grateful.

What if you don’t know any professional designers? Perhaps you signed up for this course in a group with your friends. This is where that group of yours will come in handy. Get in touch with your friends, and arrange a time to meet in the near future for a playtest session. Play through each of your games.

If you took this course alone and don’t know anyone else, the next best thing is to check the forums. The bottom section of forums, “Local Communities,” was set up specifically so that you could find other people in your local area. If you are not yet registered on the forums (but you did sign up for the course ahead of time), do that now – just be sure to sign up with the same email address that you registered with for the course (or at least drop enough clues in your forum account info to let me figure it out on my own). Arrange through the forums to meet at a neutral location. Who knows, this may be the start of a long-term professional relationship.

If you’re having trouble finding others in your area on the forums, as a last resort, post your work on the course wiki and beg on the forums for playtesters. There may be other people in similar situations. Again, if others are willing to take a look at your work and provide feedback, return the favor and playtest their work. When playtesting another’s work in this way, be sure to give them instructions for assembling a playable prototype. The easiest way to playtest in this way is to solo test each others’ games. Another option is to arrange a meeting over the internet (using a chat tool such as IRC or Skype) and attempt to play remotely in real time (some games are easier to do in this way than others).

Being a Great Designer

As other people playtest your game, keep in mind the following:

  • Your game is not perfect. If your game were perfect, you wouldn’t need to playtest.
  • There will be problems. The goal of playtesting is to find and eliminate those problems. If all your playtest did was confirm that your game is perfect, you have just wasted your own time and everyone else’s.
  • It is far better to identify problems in a small playtest, than for them to be found after the game is printed and ships to millions of players.
  • If one of your playtesters finds a major problem in your game, they have given you a great gift. Do not be hostile or defensive; be gracious.
  • When a problem is identified by a playtester, your goal is not to verbally defend your game or to explain why the playtester is wrong. First, even if your playtester is “wrong,” it probably means a lot of other players will also be “wrong” in the same way, and you can’t ship yourself in a game box in order to explain your Grand Vision to everyone. Second, the playtester is probably right – they are seeing your game through fresh eyes, and are more likely to have an unbiased view of the game.
  • If your playtesters do identify problems, the correct response is to write the issue down in your notebook… and then discuss your design goals with the playtesters so that you can get some ideas of how to preserve your goals while changing the game.
  • Not all people are tactful. Sometimes people will say things about your game (or even about you, personally) that are downright hateful. Sometimes people will make fun of your game, or will taunt or berate you for a problem with your design. Keep in mind that, no matter how it is delivered, this is still extremely useful content.
  • It takes a strong person to hear a statement like “your game sucks, it is the worst game I’ve ever played, and by extension you suck and you are nothing better than a waste of space” and to genuinely reply: “You have just helped me identify some major flaws in my game. Thank you.” Getting to the point in your life where you are emotionally strong enough to have an exchange like this should be one of your long-term goals as a game designer. You do not have to be like this right now. I’m not. But I have seen an exchange like this before from a great designer, and it made me realize how far I have to go.
  • If it sounds like I’m repeating myself here, it’s because I’ve seen this go horribly wrong so many times, that I think it is worth repeating.

Running a Great Playtest Session

If you want your playtesters to keep coming back for your future designs, be as respectful of their time as possible. Here are some things to consider:

  • Before you show your game to other players, make sure the rules are fresh in your mind so that you do not need to look them up. Try explaining all of the rules to yourself in the mirror to make sure you can do it. This will save time, if it only takes you a couple minutes to explain rather than half an hour.
  • If you already know there are problems (and you just don’t have the solutions) or if you have specific design goals other than “make a fun game,” let your playtesters know this up front. It will help them to be more aware of potential solutions.
  • End your playtest as soon as you can. If you have received as much useful information as you are likely to after a half hour of play, stop there (even if the full game would last three hours). Remember that the purpose of the playtest is to identify problems, not to “play games.” If you’re not identifying problems, you are wasting everyone’s time.
  • Bring your playtest notebook and take good notes. You will forget everything that takes place, no matter how obvious your playtest results seem at the time, so make sure you write down every piece of information that you don’t want to lose.

Being a Great Playtester

Here are some of the things you should keep in mind when testing other people’s games:

  • When testing, give the designer and the game your undivided attention. You would want others to extend the same courtesy to your game, after all.
  • Don’t leave in the middle of a test. Aside from being rude, it can throw off the results (not all games can gracefully handle it when a player leaves). At minimum, if you know you have limited time or that you may get called away in mid-game, let others know this up front so they can handle it accordingly.
  • Be as detailed as possible. Don’t just say that the game is “fun” or “boring,” try to analyze why. You should have enough of a background at this point to give meaningful feedback. Make use of your design skills!
  • Allow some time after the game for discussion with the other testers and the designer. Talk about your play experience, and how it was related to the mechanics.
  • Remember that there are many possible playtest goals. Are you playing to see if the game is fun? Are you playing to win? Are you playing to find holes in the rules? Play accordingly. We are so used to playing games in our own personal style, that it can be difficult to remember that there are other ways to play. Keep the goals of the playtest in mind.
  • Be polite. Attack the game mercilessly, but do not attack the designer.

Homeplay

Continue working on your game from last time. If your game is not already at the point where it is ready for playtesting with other designers, continue testing on your own until you are at that point.

You have two additional tasks.

First, before Thursday, August 13, noon GMT, arrange a playtest session with other designers. The session itself should take place on or before next Monday (August 20).

Second, playtest other people’s games. Keep track of the number of person-hours spent in the playtest of your own game (not including yourself), and give at least that many hours of your own time towards helping your fellow participants.

Feedback

Do you know of any great articles on giving constructive criticism, or playtesting games as a designer? Post them in the comments on this blog, or on Twitter with the #GDCU tag.

Level 12: Solo Testing

August 6, 2009

At this point you have some ideas, and you have some feedback. As with many things in life and in game design, you could sit here forever contemplating which is the best choice… but at some point you’ll need to start working towards your goal. Choose a direction and go with it, even if it might not be the best one. Trust that you will be able to use the iterative process to fix any mistakes you make along the way.

Today I’d like to cover the general concept of playtesting. As we will see, there are many different kinds of playtesting, and it is important to be able to differentiate between them in order to get maximum value from our time.

 

Readings

There are no readings for today, other than this blog post. Take the time that you would have spend reading, and use it to work on your Design Project.

 

Different Kinds of Playtesting

The word “playtesting,” like the word “game,” is overused and can mean different things to different people. In general, the term covers any activity where you are playing a game in progress for the purpose of improving it. But different playtests may have different goals, and it is important to know what your goals are before you do anything.

I’ll be playing a bit fast and loose with terminology here, so in this case the concepts are more important than the labels I’m giving them.

Bug Testing (or Quality Assurance)

The purpose of QA is to find errors in the game’s behavior relative to its design. “Fun” does not enter the equation. If the designer says that the game should do one thing and it actually does another (even if what the game is doing may be superior), that is a bug that needs to be identified.

Normally, we think of bug testing as specific to video games. Board games do have a corresponding kind of testing, where the purpose is to find holes in the rules and dead ends in gameplay – gaps in the game that the designer did not cover.

Focus Testing

In a focus test, you bring together players that are part of the target audience’s demographic in order to determine how well a game serves their needs. This is normally done for marketing purposes, but if game designers are involved it can also help to make the game more enjoyable for that particular demographic.

Usability Testing

In a usability test, players are given specific tasks to accomplish in an attempt to see whether they understand how to control the game. This is done frequently in the greater software industry to make sure that a piece of software is easy to learn and easy to use. Video games can take advantage of this as well, and results from a usability test can be used to either change the controls or modify the early levels to teach those controls more effectively.

In board games, usability is doubly important, because there is no computer to respond to player input for you. If you misunderstand how houses work in Monopoly and place them on Community Chest spaces, the game will not stop you. By observing players who are trying to play your game, you can learn a lot about how to design the various game bits so that they are easy and intuitive to use.

Balance Testing

A fun game can quickly become boring if some kind of play exploit exists that lets a player bypass most of the interesting choices in the game. If only one strategy can win and it is just a matter of which player follows that strategy the best, it is not as interesting as if there are multiple paths to victory. Likewise, if one player has a clear advantage over the others, it is important to identify that so that players do not feel the game is being unfair. The purpose of this kind of test is to identify imbalances in the game so that the designer can fix them.

Fun Testing

A game can be usable, balanced and functional and still be uninteresting. That elusive “fun factor” may be hard to design intentionally, but when people are playing the game it is pretty obvious whether they are having fun or not. Certain aspects of the game may be more fun than others, so it is also important to figure out what parts of the game need to stay the same… not just what to change.

 

All of these forms of testing have some elements in common. Best practices are similar if not identical. All are important to the success of a project. So why make a distinction?

The reason is that each is appropriate at different stages of completion in a project. Each kind of testing has different goals, and you need to know what your goal is before you can achieve it.

 

Order of Effects

When should you do which kind of playtesting? What order do you do them in? A lot depends on your particular project, so some of this will be up to your judgment as the designer. However, there are some rules of thumb.

  • Very early on in the project, you need to make sure your project will meet its design goals (usually the “design goal” is to make a game that’s fun to play). Testing for fun is necessary to make sure you do not spend a lot of time building on the wrong foundation. If you are making a game for a specific market, focus testing may be involved at an early stage as well, simply to ask the target audience if a game with a particular concept sounds interesting to them at all.
  • Once you know that you have something, you need to solidify the mechanics. Design the whole game, making sure that all the details are taken care of. Test for “bugs.” (Note that bug testing in software projects is often done continually throughout the project, increasing in intensity toward the end. Non-digital games are easier to “debug” though, and a “bug” can stop a playtest in its tracks, so it is important for us to have a complete set of rules early in the process.)
  • Once the game is fun and the design is complete, gradually shift from testing for fun to testing for game balance. Make sure that all the numeric values and player abilities are where you want them to be.
  • When the game is working and balanced, towards the end, you’ll want to think more about the usability of the game. When you change usability you are not changing any mechanics, merely the way those mechanics are presented visually to the players. This is an important step that is often neglected. If you’ve ever encountered a game that you could only learn by being taught by another player (as opposed to reading the rules yourself), that is the kind of usability failure you want to avoid in your own projects. You may also do additional focus testing at this time, to make sure that the theme and visual elements of the game appeal to the target audience.

As I said, these are just guidelines. If it is incredibly important that your game be well received by a particular demographic, for example, you may be doing focus testing throughout the project at all stages. Do not let this order of things be your master.

 

Different Kinds of Playtesters

As there are different kinds of testing, there are also different kinds of testers. Each kind of tester has their own strengths and weaknesses, and some are more important for some kinds of testing than others.

  • Yourself. You are your own most valuable playtester. Do not forget your ability to play your game on your own. You know your game better than anyone.
  • Other game designers. If you are lucky enough to personally know some other skilled game designers, you can get some very useful testing done through them. They are able to critically analyze your game and propose design solutions. (If you do not know any professional designers, perhaps you can at least make contact with other participants of this course.)
  • Close friends, family, and confidantes. People close to you who are willing to provide their time to test your game are very useful. They are approachable and can make themselves available as a favor to you. Take good care of them, and do not abuse their kindness. Note that these people may not fall into any of the other categories, so while they are good for early tests, they may not be appropriate in more focused testing for bugs or balance since they may not know what to look for.
  • Experienced gamers. Skilled game players are great at finding exploits and dominant strategies in a game, and are appropriate for balance testing.
  • Complete strangers. People in your target audience are appropriate for focus testing and usability testing, and they are absolutely critical when testing for fun. Finding them can be tricky, though, because it is not in most of our natures to just walk up to someone we’ve never met and ask them to play a game. We will talk more about this in the coming weeks.

 

Order of Familiarity

In general, you will want to go through testers in order from more to less familiar. Test with yourself first, then with close friends, then with acquaintances that are useful (because they are designers, gamers, or part of the target market), and then with strangers.

If you show your work to other people too early, it will likely be in such a rough state with multiple design flaws and holes in the rules that it will waste their time and frustrate them, and you want to treat your playtesters better than that. Also, if you start playtesting with strangers too early in the process, you may not get useful feedback – if your game prototype is in a rough state with only crude art and components, for example, the playtesters may be so busy commenting on the poor quality of the pieces that they will not be able to concentrate on the gameplay.

At this point you might be tempted to just do all of the playtesting by yourself, so that you don’t need to rely on other people or keep track of them. In practice, the designer eventually gets too close to their own project and is so familiar with the game’s systems that they can miss some really obvious flaws. If you keep the same set of playtesters for long enough, they will suffer from this problem as well. You need to bring in fresh sets of eyes to look at your game on a continuing basis throughout the project.

 

Playing By Yourself

In the early part of playtesting, when you are playing the game on your own, here are some things you should be looking for:

Does the game meet your design goals?

Is it fun, at least for you? While you are not the ideal playtester to judge effectiveness most of the time, if you are not having fun then most other people will probably not either.

Are there any holes in the rules?

A “hole” is a situation where the rules simply do not say how to proceed. For example, perhaps one of your rules is that a player’s army can attack another player’s army, but you don’t yet have rules for resolving the attack. What happens in this case? In practice, what happens is that the players sit around and wait while the designer figures out what to do!

As an example, consider these rules for Tic-Tac-Toe played on a 4×4 grid:

  • Players: 2
  • Objective: Get a straight line of symbols.
  • Setup: Draw a 4×4 square grid.
  • Progression of play: On your turn, place your symbol (“X” or “O”) on an empty square.
  • Resolution: If either player on their turn has a set of four of their symbol in a straight line (across, down, or diagonally), they win.

If you try to play this game just following the rules, you’ll quickly realize that you can’t even start – nowhere does it say which player is X or O, or who takes the first turn! To fix this, you would add a situation to handle this. For example:

Setup: Draw a 4×4 square grid. Choose a player to go first, who is assigned the symbol “X”. The other player is given the symbol “O”.

Are there any dead ends?

A “dead end” is a game state where there is no way to proceed further, but the game is not resolved. Consider our revised 4×4 Tic-Tac-Toe rules above. Suppose that both players fill up all squares on the board without anyone winning. At this point the game cannot proceed, because the rules say a player must place their symbol on an empty square. There is no empty square, so the player cannot take a turn. But there is also no resolution, because neither player has won. In this case, a new rule would have to be added (such as: in the resolution, if neither player can make a legal move and no one has won, then the game ends in a tie).

Are any of the rules unclear?

It is natural for us to assume things that are in our head, to the point that we often forget to write them down in our rules. Try to look at your rules and see if there is anything you are assuming that your players might not.

Are there any really obvious rules exploits?

Is there a single strategy that wins the game easily? Try to find it. It’s much less embarrassing if you find and fix it yourself, as opposed to having it discovered by your playtesters (or worse, your players after you release the game). Clarity and exploits are often hard to find in your own game; you tried to design this game to not have any problems, after all. Still, make an honest effort, and sometimes you will be rewarded by finding and fixing errors early (which saves a lot of time in the long run, leaving you more time to iterate on other parts of your design).

You might think that looking for exploits is something to do later in the project when balancing the game. Sometimes it is. It is a matter of degree. If an exploit is so powerful and so obvious that it prevents your playtests from giving you real information about your game, fix it now.

 

Solo Test Difficulties

There are a few things that are hard to test alone:

  • Realtime multiplayer games, such as games where you must slap a card or say an answer faster than your opponent.
  • Hidden information games, where each player has information that only they know and that is important to keep secret from the opponent.
  • Trading, negotiation, and auction games, where each player must place a value on an item, and different players may value things differently (and especially when players can artificially extort high prices or drive up the cost of an item at auction just to make their opponent pay more).

For the latter two, it is possible to play anyway, by simply limiting your actions to what you think you would do if you were in each player’s situation, knowing only what they would reasonably know. Some people find this more difficult than others.

The simplest answer here is, for the purposes of this project, to not use mechanics that you can’t test yourself. The alternative is to bring in another player or two early on in this case only, after you take things as far as you can on your own.

 

Let It Grow

Experienced designers often talk of a game “making itself” – as if the game has a life of its own, and the designer is merely guiding it rather than creating it. On the surface, this seems strange because really, the game is just sitting there and doing nothing unless the designer is playing it or changing it. What’s going on here?

I think that what is really happening is that the creation of a game is a learning process. You may have some idea of where you want your game to end up, but the final version may be very different from what you originally envisioned. The reason why it changes is that at the beginning, you don’t know very much about your game. You have some basic ideas, but you don’t actually know how the mechanics will interact, or what the actual dynamics and aesthetics will be. As you playtest, you learn more about how your game’s systems are working. As you learn, you become more able to predict the effects that changes will have on the system.

Right now, though, you don’t have that experience… at least not with this game. Playtesting on your own is your first act of discovery. As you discover, it may seem as though your game wants to grow in a new direction, as if it has a life of its own. If you feel that, go ahead and listen to your game. See where the process of discovery takes you.

 

Homeplay

As the nature of the work at this stage is solo, you do not have to post anything on the forums. Work alone until Monday, at which point we will start involving others.

Before Monday, August 10, noon GMT, create a playable prototype of your game. You may find it useful to review the section of Level 4 on prototyping. Remember that you can make a prototype in about 15 minutes – it doesn’t have to be pretty and it doesn’t even have to be complete (yet), but it does need to be at the point where you can sit down and play it by yourself.

Then, play the game by yourself, at least once. In your idea notebook, write down any problems you encountered or questions that you ran into. Trust me, no matter how obvious the things are that you need to fix, you will forget them if you don’t write them down.

Finally, write down the rules once your game is at least somewhat playable. This is also for your own reference, so that you do not forget.