Wednesday, July 30, 2008

New Blog on Game Design Textbooks

Game educator Malcolm Ryan has recently started a blog about books that are useful for game designers. He is planning to review one book per week until his bookshelf runs empty. So, it's no longer just me doing this, which is great because the more critics we have, the better (given how many horrible books there are out there).

So, let's all give Malcolm a warm welcome.

Saturday, July 26, 2008

Challenges for Game Designers

So, the book I've been writing with Brenda is almost done. We're going in to print this week, which means it should be available soon thereafter.


Game designers, like other artists, get better with practice. "Challenges for Game Designers" is a series of creative exercises based on real-world problems, allowing the aspiring and practicing game designer to hone their craft without taking the time and risk inherent in a full game development project. Well-known game designers contribute their own unique solutions, allowing a window into their thought processes. While most books in this field admit that a game designer must regularly design games, no other book gives the reader, whether student or professional, a starting place to practice their essential skills. "Challenges for Game Designers" is nothing but practice, making it an essential book on any designer's shelf.

The book came about when Brenda and I witnessed some other game educators asking if there was any way to teach game design that didn't require getting involved with computers and programming. Yes, of course you can, but there weren't any books that would really give a list of exercises that you could use for practice. So, we made one. The entire manuscript took about 6 months, so we probably set a new land speed record.

If you're interested, you can order it here, among other places. If you're an educator, contact the publisher for a free desk copy. If you're still making up your mind, the book also has a companion blog that you can view for free here.

Friday, July 25, 2008

Design Challenge on

Apparently someone at GameCareerGuide was paying attention to this blog, because Jill Duffy took my game design assignment as inspiration for a full-fledged design challenge: create a player aid for RISK.

So, if you're interested in trying it out for yourself, head over there and read it, and then submit your work on their forum.

Monday, July 21, 2008

Another class assignment

A teacher presented this as an assignment in a college Economics class. I think it would work well in a game design class as well, but this makes an interesting point: "design a game around the subject material" is actually a great assignment in any school subject.

This particular assignment had two parts:
  • Form groups. In your group, design a game, or mod an existing game (in this case, a game that uses economics to drive its core mechanics, but replace whatever suits you).
  • Then, give your game to another group, and receive a game from a third group. Playtest the game you're given, find the holes, and provide meaningful feedback.

This assignment gives practice in designing games, and also critically analyzing them, and also receiving constructive feedback on your own designs.

Friday, July 18, 2008

A Game Design Assignment

Another teacher of game design mentioned this at Origins:

Take a relatively complex board game (say, Puerto Rico). Design a player aid for the game.

This forces students to exercise the following skills:
  • Reading and understanding the rules! This is actually a difficult task, and going through the process involves understanding that games are composed of rules, and learning how the different rules can work together. Students who play through the game instead of merely reading a rule sheet will learn that the dynamics of a game set in motion are sometimes very different -- and sometimes easier to understand -- than the static nature of a written document.
  • Learning how to explain the rules to someone else. This doesn't just mean writing a manual, it means making the game easy enough to learn that you don't need a manual. (Consider all of the video games today that do such a good job of teaching the player in the first few levels, that the written manual is superfluous.)
  • Evaluating the User Interface. Players must decide what parts of the game are the most confusing or intimidating. What is hard to use? What aspects of the game are unclear? This also requires the ability to conceptually divide the game into its component parts, and see the relationship between the mechanics and the UI.
  • Improving the UI. Once a problem is identified, the student must come up with a superior solution. In this case, it involves adding a new component: a player aid or quickref sheet of some kind, meant to simplify some confusing aspect(s) of the game. Oh, and of course you have to design the player aid so that it is itself easy to use, and doesn't make things more confusing.

And for all this thinking, the actual work output is simple: a small piece of cardboard or a single sheet of paper, perhaps. And that's the beauty of it: students learn that sometimes, a huge amount of work goes into a very small component of the game, but that component ends up making a huge difference in the player experience.

As an alternate, more advanced assignment, find a game with long, difficult or confusing rules and have students rewrite the rules to be more clear and concise.

Tuesday, July 15, 2008

Gender Pronouns in Writing

Game designers do a lot of writing. So do teachers. And students, for that matter. So, I thought this writing tip that I picked up at Origins would be useful to most of you. (If only I had known this before finishing the writing on my textbook. Well, there's always 2nd Edition...)

Gender pronouns are always tricky. Use a gender-neutral he/his/him all the time and you've unwittingly added male gender bias (this is particularly insidious in game design documents, if you inherently assume the player is always male -- which perhaps explains why there are so many female characters in games wearing chainmail bikinis). Use she/hers/her and it looks like you're using feminine pronouns just for the heck of it. The dual him or her / he or she is unwieldy. The slash-based s/he looks ugly. The fusion hir looks downright alien. What's a writer to do?

Here's a simple solution: make it contextual. Use male pronouns for certain kinds of things, and female pronouns for others, and use them consistently.

The example given at Origins was in the writing of a rulebook for a tabletop RPG. The designer used female pronouns for the GM and male pronouns for the players. This not only caused the writing to be more gender-balanced, but also made the manual easier to read because it was clear who each pronoun was referring to!

Thursday, July 10, 2008

Giving Great Game Demos

Alex Yeager of Mayfair gave a great seminar at Origins called The 2-2-2 Demo. What follows are my notes. There are several applications:
  • If you regularly introduce your students or colleagues to new games, it helps if you can explain the rules succinctly. This is the direct application.
  • Explaining the rules of a game is no different than teaching any other course material. If you can explain how to play a game, you could use the same basic framework to explain your course material.
  • The process of creating a game demo has similarities to the process of designing an actual game.
  • You'll probably see other parallels as you read on.

What is a "game demo"?

In this particular context, it means a way of introducing someone else to a game they haven't played before. There are many reasons you might want to do this: to simply familiarize them with the game for educational or historical purposes, to get them interested in the game enough to play it, to convince them to buy it, etc.

There are many types of demos, but Alex gave three types: Two-sentence, Two-minute and To-play (hence, "2-2-2").

The Two-Sentence demo

In the game industry, we would call this an "elevator pitch." In just a couple sentences, state the basic theme and goal of the game. The purpose here is not to explain the rules, but to gauge and generate interest. It gives the other person an opportunity to bow out without you wasting ten minutes on a full rules explanation before saying they're not interested. If they are interested, this provides a context for everything that follows.

The Two-Minute demo

Discuss the type/genre of game, general flow of gameplay, win conditions and other important core mechanics. Take the two-sentence demo and add detail. Emphasize the important decisions that players are making.

Again, the purpose here isn't to give the other person everything they need to play, but it makes a full explanation of the rules go much faster if they already have a mental framework to put things in context. The purpose is still to generate enough interest to proceed to a full demo.

The two-minute demo has another purpose. People who have played the game, like it and want to evangelize it can use a version of your two-minute demo when they show the game to their peers. This provides a way for you to "deputize" players so that they can generate interest in the game from their friends, who can all them come back to you. (Think about this. Do you teach any courses where your students are actively recruiting on your behalf for next semester?)

It's worth mentioning that some games do this for you automatically. If a game has neat-looking components that make players go "wow... what's that? Can we play that one?" then you can safely skip the short version and leap into the rules. Not many games have that kind of "curb appeal" but a few do.

The To-Play demo

When game enthusiasts want to demo a game, many of them leap immediately into a full explanation of the rules. For some people (e.g. other hardcore gamers who have already agreed to play) this is fine. Other people (especially non-gamers) may still be tentatively deciding whether they want to play at all, and launching into a full-blown rules description can quickly overwhelm them.

Use this demo to teach the game to people who have already decided to play. They are actively engaged and they've got the time and opportunity. Otherwise, start with something simpler.

The best to-play demos are things you've practiced before. Become intimately familiar with the rules yourself before teaching them, ideally. Think of ways to present the rules so that they're easy to understand, flow well and can be explained in a minimum amount of time.

Personally, I've found that for most board games, the following framework tends to work well:

  • First, state the object of the game, unless it's really obscure or needs other information to be understood. It provides the context for why the player should care about other rules. Frame all other rules in terms of "how can you use this to win?"
  • Then, talk about the progression of play. How do turns work? What can you do on your turn? Start with the things you do most of the time, and just briefly touch on exceptions that only come up once in awhile.
  • Next, mention the game end condition. What causes the game to end, and how (if at all) do players have control over causing the game to end or continue?
  • If you can just set up the game yourself without having to explain initial setup as a series of rules, do so. Otherwise, explain the first part of the game last, after the players already understand the general flow of play and can make intelligent decisions during setup.

Implications for playing games

When explaining games to people who aren't gamers (like friends or family), start with very simple explanations. Don't continue into something more complex until you see the other person's interest, or else you may bore or overwhelm them.

Implications for teaching

Start each course topic with a general "why should I care?" / "why is this cool?" overview, then layer on some basic details and the overall flow of what you're about to learn, and then go into the gory details once you've got the class interested. Once your students see why the stuff you're teaching is important, they'll pay a lot more attention.

Implications for game design

Don't create a game (either digital or non-digital) where your players must understand and master all of the mechanics before they make their first move. Try to create play situations where the player is slowly and gently introduced to new mechanics, allowed to feel through the general flow of the game in a relatively safe environment. Then, add the details once the player is hooked.

Bonus insight: Implications for curriculum design

According to Alex, there's a pattern when introducing Eurogames to kids who are unfamiliar with them:

  • When you teach one game, that's all they want to play. "I played Settlers of Catan before, it was fun, I want to play it again." There are, apparently, no other games worth playing.
  • When you teach a second game, there's a choice: play X or play Y. "We played Carcassonne last time, let's try Settlers again."
  • But when you teach a third game, something magical happens. The players start seeing connections and comparisons that go beyond simple either/or choices. "Let's see... I'm in the mood for a trading/auction game, and Joe says he has to be somewhere in an hour so it can't be more than that, and Sarah hasn't played before and wants something easy to learn... how about Modern Art?"

I think education may work like this in general. Take a Biology 101 class where they force you to memorize all of the structures of the cell, and you assume that the entire field is just memorization. Take Genetics and you might think that the field is part memorization, part math. Take a microbiology course... and suddenly you realize that it's actually a really diverse field, and all those other courses aren't just repeats of the same stuff you've taken already, they're starting with some basic concepts and taking them in a whole new direction, and how cool is that? But only the people in the major get to see this. Implication: the "101" or "Survey" courses, especially those aimed at non-majors or prospective majors, should be designed to expose them to at least three different areas of the field. In these classes, focus less on laying a foundation for the major, and more on the diversity and overarching patterns and common problems that they will see in the field.

Wednesday, July 09, 2008

Back on regular posting schedule

First there was Origins. Then I came back to find that I had a week to finish up final review for my first book. Then I got some short-term industry contract work. So, things have kept me busy, but I'm now back. In the coming weeks I'll follow up with what I learned at Origins this year in terms of teaching, game design and more.

One thing I've been thinking about for a little while now is the similarity between education and game design. I'm starting to actually read some books on education, and an awful lot of concepts are identical, they just have different names. I heard this from several teachers at Origins as well -- after seeing my presentation, they remarked that some general concepts of game design are the same as in the professional literature for education, except that they are perhaps easier to understand in the context of games (if the teacher happens to be a gamer, at any rate).

For example, one of the concepts most game designers are familiar with is the MDA Framework, which says (among other things) that there are many different kinds of fun, that different games offer different combinations of these kinds of fun, and that different players find some kinds of fun more or less engaging than others. There's a parallel to different kinds of learners in a classroom environment: audio learners, visual learners, kinesthetic learners and so on, where each student is engaged by a particular type of activity. It's not much of a stretch to find links between the kinds of classroom activities and the kinds of fun in game that people find engaging.

A more interesting example is rubrics. I'd never heard the term 'rubric' before becoming a teacher. Essentially it means making a list of skills, and then grouping and classifying them. For example, a grading rubric for a class would list all of the things students are expected to be able to do after taking the class, and then what skills the students must build in order to do those things, and then what the students must demonstrate (and at what level) in order to achieve an A, B, C, etc.

Most teachers I know hate developing rubrics. It's a chore that involves tons of paperwork, and defining all these tiny details about a class and the concepts that you're teaching and how they all relate to each other and how you plan to measure everything. It's something that teachers do only when forced at gunpoint.

And yet, there are designers of computer/console role-playing games that do essentially the same thing. What are the capabilities that I want the players to be able to take advantage of in and out of combat? What are the skills, abilities and magic spells that I can make available to the players to allow them to accomplish these feats? How should I group these skills and abilities and spells -- by function, by elemental sphere, by character class? How do players gain access to these skills -- leveling up, completing quests, finding items? And this is the kind of content design that RPG designers absolutely love. It's the really fun part. It's a hoot. They'll go back and design more of these skills for fun, on their own time, rather than doing the important work like testing the combat system for balance.

Somehow, there has got to be a way to make rubrics as exciting as RPG design. I haven't figured out how yet. But it's the same freaking task.