Naches / Kvell

I just received news that one of my students (well, ex-student now, I suppose) just got his first game industry job as a designer. That makes two success stories total. Given how difficult it is to find an entry-level game design job, this makes me feel fulfilled in exactly the way I was hoping to be when I first became a teacher.


Interestingly, the two students who are now working as game designers were also the only two students of mine who attended GDC this year. I don't believe this is a coincidence at all. I tell all of my students that GDC is pretty much a mandatory step for anyone who wants to "break in", and now I have stronger evidence than just my own say-so.

Much as I'd love to take total credit for being such a great teacher, my students this year were pretty amazing. All I did was point them in the right direction, but they did all the legwork to reach their destinations.

For those unfamiliar with the terms Naches and Kvell, a description can be found here, on page 6 (the rest of the document is well worth reading too, especially if you're a game design student).

Textbook Review: Rules of Play

This is part of the series on book reviews.

"Rules of Play" (Katie Salen & Eric Zimmerman)

I’m really glad this book was written. It was the first book ever written about game design that actually looks like a textbook. It’s big, it’s heavy, it has lots of small-print writing with exercises at the end of each chapter and a bunch of appendices at the end. Its very existence gives the entire field some modicum of academic merit.

The content does not deal so much with how to design games per se, but instead gives many different ways to critically analyze games. For example, if you consider a game as a system of rules, you are going to see it differently than if you look at that same game as a narrative, or as a sociocultural activity, or… well, you get the idea. It is therefore useful to game designers only in the most abstract sense of gaining a deeper understanding of what these things called “games” are, these things that we work with every day.

As a bonus at the end of each of the four sections, there are the rules for a game you can play (I found most of them to be quite good). In addition to the game itself, we can also see the designer’s notes about how the game started out, what kinds of things were found in playtesting and how (and why) the designer addressed the game’s shortcomings. This insight into the brain of a designer-in-motion is most interesting, and practically worth the (hefty) price tag of the book on its own. There’s also an essay by Reiner Knizia, which also makes for great reading, even if it doesn’t necessarily fit the theme of the rest of the book.

Unfortunately, this book has a few weaknesses in its presentation. The writing is a bit on the long side. As a game designer, I found that if I just read the bullet-point summary at the end of each chapter, I usually got all of the information I needed; actually reading the chapter itself was a waste of time. (Yes, I read every chapter first, just to make sure.) I’m not sure if this is just from my experience; if there are any students in the audience who can say whether this was true for them as well, please post in the comments.

Also, the authors have this unfortunate tendency to create their own vocabulary. Their new terminology mingles liberally with established industry jargon, but with no mention of which is which. I can’t fault the authors for this (what else could they do?) but it does make it more difficult to use this as a textbook: my students who go to GDC should know what an Avatar is, but if they start talking about “schemas” and “constitutive rules” and “transformative social play” they’re just going to embarrass themselves.

Students: I doubt any student would choose to read this on their own. Most of you don’t enjoy reading to begin with, and a book this abstract would probably bore you to tears. You may be forced to read it as part of a game design class (and if so, you have my sympathy) but otherwise, you’re safe avoiding it for the time being if you want to be a game designer. If you’re more interested in game critique or game studies, you’ll probably find this quite useful and fascinating. I could never figure out game studies people.

Instructors: This book would be perfect for a “Critical Game Analysis” class that acts as a dual requirement for Game Studies and Game Development students. I’d expect it to be an upper-level class, simply because of the highly academic writing in the text. For any course focused entirely on game design, there are better texts; as noted above, this book does nothing to explain how to actually design games.

If you do use this book for a class, be sure to differentiate between the terminology used that already exists, versus that which was created by the authors. Your students should be able to speak clearly about games to people who haven’t already read Rules of Play.

Professionals: This book took me about half a year to read through from cover to cover (in my spare time, granted). You can get all the same benefits in a fraction of the time by just skipping to the end of each chapter and reading the summary, then going back and looking up anything that doesn’t make immediate “well, duh” sense to you. Also read the Knizia essay and commissioned games, of course. Do that and you’ll finish reading it in a few days.

Textbook Review: Game Design Workshop

This is part of the series on book reviews.

"Game Design Workshop: Designing, Prototyping & Playtesting Games" (Tracy Fullerton, Chris Swain, Steven Hoffman)

This book covers the core concepts and best practices of game design. It is organized into three parts. The first part gives a formal description of all of the different aspects of games, to build a framework for discussing how to design them. The second part talks about the iterative process as it applies to game design (in particular, how to prototype, focus test and playtest, and respond to feedback); in fact, this is the only game design book I've seen so far that does so. The last part gives an overview of the game industry and the job roles and responsibilities of the game designer.

The first part of the book gives a reasonable breakdown of games into their component parts. The second part gives great practical advice on the process of game development from a designer's point of view. The third part is easily the weakest link; it starts out worthless (everyone reading a book like this already knows what a game designer is, why else would they read it?) and proceeds into the realm of actively damaging (giving the waterfall model of production, and a design document template as examples of best practices). It is best for everyone with this book to just pretend the third section doesn't exist; thankfully, the rest of the book is worth the price of admission.

Sprinkled throughout the book are numerous interviews with famous designers, offering many (often conflicting) perspectives on the field; these make great discussion fodder for classes, and also provide some insight into what aspects of game design are universal (where many designers agree) versus those that are a matter of personal style (where designers give opposing answers to the same questions). They don't seem to have much relation to the section of the book they appear in, they're just diversionary sidebars... but they make interesting reading nonetheless.

Students: You can read this book on your own, but you'll probably get the most out of it if you take a class that uses it as a textbook. If no such class exists, reading the first two parts is still a worthwhile use of your time -- certainly better than nothing.

Instructors: The book contains many exercises, some highly conceptual and some quite practical, making it very easy to use as the basis for an intro course in game design. This is, in fact, the book I used myself for just such a class, and I was quite happy with it. I found that, while it does involve a lot of reading, the reading goes quickly; the students taking a game design class are already motivated, and this book contains the material that they want to know. I encouraged students to read those parts of the book that we didn't get to during the course, on their own time... except for the third part of the book, which I advised them to rip out of the book on the first day of class.

Professionals: The first part is worth a read if you're a practicing game designer; many of the concepts will probably not be news to you, but it might give you a few new conceptual ways to think about the design of games in the abstract. The second part is worth reading for both game designers and producers, especially if you're not working at Maxis or Firaxis or some other place that already embraces iterative design; it gives great practical advice for doing so. The third part is even more worthless than it would be for a student; you're already a practicing game designer, so the last thing you need to be taught is "what it's like in the game industry".

Teaching Licenses

I've been thinking about how to best use a license when designing games, since long before I was teaching. Everyone has their theories but no one has an official industry-wide best practice. But when I'm running a class on game design, I feel obligated to say something about it, because it's something that comes up so often in industry.

The first time around, I got through this by mediating a class discussion. (Ha ha, I don't need all the answers, I can just have my students provide them!) We listed a lot of licensed games that were either really good or really terrible, and then looked for common themes. We agreed mostly on two general rules: respect the license (something that a certain dog food company would do well to understand), build a game in the fictional world without trying to recreate the original fiction, and choose a game style and genre that are appropriate to the license. The class then went on to create short pitch documents for a game that used the Care Bears license.

I thought about this again earlier today, when I saw a new Scrabble-branded instant-win game at Subway, and I wish I were teaching class right this moment so that I could lead a discussion on this. It's an interesting case in that it's a game license in reverse: a game itself is a license being used to promote an entirely different product, rather than the other way around. But I assume many of the rules of using a license well still apply. I have to wonder: was this a good use of a license? Okay, it's obviously competing with the Monopoly game from McDonald's. But Monopoly is at least a game about money, so a game where you (theoretically) win money makes sense. And collecting all title deeds of the same color has meaning from within the game, so it makes sense that doing so in an instant-win game is meaningful. I don't see this with Scrabble. In the game I get points, not cash; and I'm not collecting one letter at a time to spell words, either. Neither license has anything to do with fast food. So, I don't really see the use. I have to wonder whether this promotion will have a greater effect on sales of sandwiches, or Scrabble sets.

All that said, it will be a happy day for me if I ever see a big fast-food franchise running a Settlers of Catan scratchoff game.

Feel free to leave other comments on common themes of games that make good use of licensed material.

Analogy: Learning as Painting

I heard an interesting analogy today that I hadn't encountered before: we learn in coats of paint.

First we get a general big picture with broad strokes, then as we revisit the material we add finer and finer details. This is why there's so much review in school; the first time you learn something like integral calculus it's all very new and confusing, but the third time around it gets a lot easier.

Interestingly, this is also how we play video games. At first you have a basic idea of what's going on -- the basic controls to make things happen on screen. After playing for a little while you find additional layers of strategy (or increase your skills) to the point where you understand finer details about how the game works. We even have a name for this: the MDA framework. The broad brush strokes (from a player's point of view) are the aesthetics, the feeling you get from playing the game. The medium-level details are the dynamics, the way that various components in the game interact with one another. The fine details are the mechanics, the underlying rules of how everything is actually resolved by the computer.

If this is, by its very nature, how we learn new material -- learning it once formally and then revisiting it multiple times until we finally grok it -- that has a number of implications for structuring a class. Among other things, it means that any individual course shouldn't be designed in a vacuum; it should have a lot of connections to other classes within the overall curriculum, so that each later class reinforces the material from the earlier ones. (I ended up doing this in a lot of my classes last year, not by design, but more because I thought some topics were important enough that I should make sure all of my students encountered them, even if they only took one class and not another.)

People who have Ph.D.'s in education probably have a theory named after some famous person in the field to describe all this, but I'm still just figuring it all out as I go...

The importance of a Game Industry course

I taught a course last year called Game Industry Survey, sort of a who's-who and what's-what of the industry. Recent events highlight why such a course is inherently useful.

See, there was this game called Guitar Hero, and if you haven't heard of it, it became a surprise hit, originally launched in 2005 with a sequel the following year. The original and sequel were developed by Harmonix and published by RedOctane. Then, things got complicated. RedOctane was purchased by Activision, and development on Guitar Hero 3 was handed to Neversoft (of Tony Hawk fame). Meanwhile, Harmonix is focusing its efforts on Rock Band, an iteration on the same basic concept.

What needs to be understood about this mess?

• There is a difference between the Developer and the Publisher. (Briefly: Developers make games; Publishers make money.)
• Intellectual Property is often tied to a specific Developer or Publisher, but it can also be its own separate entity, as is the case here.
• Ditto with the code base for a game series, which is often tied to the IP (and the Developer) but not always... as in this case.

Why is understanding these things useful?

• A lot of people in the game industry are following this unfolding story with great interest. A lot of us like the original games, you see. So, if you're talking to a developer and you don't understand this stuff, you're likely to have a foot-in-mouth moment that could cost you a job opportunity.
• Even if you're not interested in joining the industry, if you're just an avid game player who likes the series, understanding these things lets you make better purchasing decisions. "I likes the first two Guitar Hero games, so I'm guaranteed to like the third one" is no longer given if the people actually making the third game are different from the ones who made the originals. If you follow the developer and not the publisher, you'll usually find more consistency in product lines.

My thanks to the industry for making my job easier. For once.

Game Designer as Chef

Another analogy for game design occurred to me yesterday while making dinner: that of the professional chef.

The human body is capable of recognizing five different kinds of taste (eight kinds of fun). Various foods (games) stimulate different combinations of our taste buds (fun centers in the brain) to produce different experiences in the taster (player). The goal of the chef (game designer) is to combine ingredients (game mechanics) in such a way as to produce a unique and satisfying experience.

Ingredients are not static; sometimes a specific combination leads to a result far greater, or lesser, than the sum of the parts. Some ingredients also give different flavors when raw or cooked. The chef understands how the ingredients can be combined to create certain flavors and aromas (game dynamics) which in turn produce a tasty meal (a fun game).

But the consumer doesn't generally notice the individual ingredients (gourmets excepted), but the overall experience. Because of this, presentation of the meal, with proper garnish and arrangement (cool graphics and sound) is as important as the ingredients themselves. Additionally, meals and games fall into genres based on common characteristics and ingredients... whether it be BBQ / Italian / Chinese, or FPS / RTS / MMO.

Skill of the chef is important; it takes talent and experience to make a decent souffle, and if you get it wrong it's pretty obvious. On the other hand, most people have enough talent to at least follow a recipe (playing a good game in an unfamiliar genre) and get reasonable results. In fact, most people are capable of improvising to create their own modifications to recipes when they want to (creating house rules for board games, either to make them more fun or to add handicapping so that they're more fun for younger players). A few people make gourmet cooking (indie game development) into their hobby even though they never plan to make it their profession. Some people teach cooking classes, but one generally wouldn't trust a teacher who was never a professional chef. And while many of the people taking those classes dream of being Emeril Lagasse, most of them will end up working as a nameless grunt for one of the big-name restaurant chains.

The analogy starts to break down when you compare a master chef to Master Chief...