Textbook Review: The Game Design Reader

This is part of the series on book reviews.

"The Game Design Reader" (Katie Salen and Eric Zimmerman)

This companion to Rules of Play is simply a collection of important essays and other written works about games. It includes pretty much everything that I'd call "foundational" to the field: Costikyan's I Have No Words, Church's Formal Abstract Design Tools, Bartle's Player Types, and so on.

Unfortunately, it tries to be a little of everything; there's some New Games Journalism, some pieces on players and gamer culture, and other things that don't really have to do with designing a game. And most of the articles are freely available online anyway, making me wonder why I should force my students to pay some exorbitant amount of money for a textbook.

This is not to say that the articles (design-focused and otherwise) aren't useful. They are still important works in their own right, many people in the industry have read them already, and any serious student should read everything in this book. It's just that no matter what the subject of the course, the majority of the works in this book won't be relevant. I suppose you could build a course around the book, "Important Readings in the Game Industry," but I'm not at liberty to do that right now. An alternative is to require this book for several courses in game design and game studies, with each course covering different readings… but that requires a bit of coordination between professors to ensure minimal duplication, and pity the poor students who take half the courses only to have to purchase the same book again if it ever goes to a Second Edition.

Students: If you’re serious about games, you should have at least a passing familiarity with everything in this book. Buy it on your own and read it over a summer when you’ve got nothing else to do. Or, if you’re on a tight budget (and what student isn’t?), find the book in your local bookstore, copy down the table of contents, and track down all of the articles online. For those few readings that can’t be found online, you should be able to check out the appropriate works from a library, or just read them in the bookstore.

Instructors: I’ve gotten by with just assigning relevant online readings, without forcing students to buy this book. I do suggest to my students to track down additional relevant readings from the book on their own time.

Professionals: At the very least, take a look at the table of contents and see how much of it you recognize. If you haven’t seen anything mentioned, you’ve got some wonderful reading experiences ahead of you. More likely, you’ll recognize some important works that you’ve encountered before, and the rest won’t be relevant to you. Take a look and decide for yourself.

Textbook Review: From Blue Sky To Green Light

This is part of the series on book reviews.

"Game Design: From Blue Sky to Green Light" (Deborah Todd)

This relatively short book covers everything that happens in preproduction; it gives a reasonable treatment to game design documents and the iterative process, and it even has a section on pitching a game to a publisher. It also covers the creative aspects of game design that I myself am weakest at: storytelling, character design and level design.

Overall, the book delivers what it promises, and not much else. You won’t find a lick of material on technical game design, content development during the actual creation of a game, or anything like that.

The only real weakness of the book is that it’s extremely current and uses a lot of very recent examples (as of the time of publication). This means it is likely to obsolete itself in a fairly short time, as the games within become dated and the business of the industry (hopefully) moves beyond the developer/publisher royalty-with-advance model. Although perhaps that’s intentional, if the author hopes and expects to make new editions every few years.

Students: Odds are, the first project you work on will already be in full production by the time you’re hired. Preproduction work, concepting and pitching are usually reserved for experienced design leads (not always, but usually), so this will not be immediately applicable to your first job. That gives you time to read it after you break in to the industry, if you're the procrastinating type. But if you’re curious what the early stages of a game project are like, you’ll get a pretty good overview by reading this book. It’s also not terribly big or intimidating, so reading it while still a student might not seem like such a daunting task.

Instructors: This book is rather specific to the earliest phases of game development, making its use limited in most classes. If you’re teaching a practical game design course where the deliverables include a one-page game concept, a slightly larger game proposal, a game design document and a verbal pitch to a “publisher” (i.e. the instructor), this book will cover you. If the only practical development course you teach involves all of that in the first three weeks and then it’s straight into prototyping, you might not have enough time to make the book worthwhile as a required text.

Professionals: Designers in the industry are still very guild/apprentice-like. If you do indeed start your first design job in the middle of a project, you’ll probably experience a few preproduction cycles vicariously through your leads before you’re forced to do it yourself. Depending on how you look at it, that either makes this book redundant with your experience, or it will reinforce it. In any case, it’s probably worth a read just to see what others have to say on the subject. And if you happen to find yourself in a small studio where you’re thrown into the role of Lead Designer on your first job fresh out of college… then you should read this just so you have some experience backing you up (even if it’s not your own).

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

Textbook Review: 21st Century Game Design

This is part of the series on book reviews.

"21st Century Game Design" (Chris Bateman and Richard Boon)

This is a dangerous book. I can recommend it for veteran game designers since it provides an approach to game design that they may have never encountered before, and it's one more tool in their already-large toolbox. For anyone else (especially students), this can take you down the path to ruin if you just follow it as gospel.

The idea behind the book is simple: identify your target audience, then use psychological profiles to predict what games and mechanics are most compelling to the intended market. This basic concept of "designing for the audience" is a useful one, and I can see it being applied successfully in the field if used with care.

Strangely, the authors seem overly fond of MBTI as the preferred player demographic. For those who haven't encountered Myers-Briggs, it defines sixteen personality types and then proceeds to lump all of humankind into one of these compartments. Reading a description of these personality profiles bears a striking resemblance to another method of classifying people, and my understanding is that either one is about as useful as the other in terms of predictive value. (If you're curious, I'm ISTP, and Virgo. Those of you who place great faith in personality types are now saying to yourselves, "ah, of course!" while the rest of you already know me far better from my writing than any category I fit into.)

I find it ironic that Ernest Adams, who writes the foreward to this book, wrote years ago how designers should concentrate on making great games instead of spending all their time talking about marketing and player demographics. He even talks about how Purple Moon -- a company that used a startlingly similar approach advocated to this book in order to make "games for girls" -- died horribly because their designers spent so much time doing market research that they forgot to actually make their games fun.

Students: Avoid this book. (In my experience, most students don't need much convincing to not read something, so that's all I'll say on the matter...)

Instructors: Do not use as the sole text for a book. If you mention this book in your classes, warn the students that it is just one of many approaches... and one that has not yet been used successfully to make a hit game. It may be worthwhile to discuss short excerpts in an advanced class, as one of many methodologies for designing a game; as an exercise, have students rip apart the logic, separating the useful from not-so-useful parts.

Professionals: It's worth reading the first part of the book, before it goes into the actual details of personality types, just to consider the concept of a player-centric approach. The rest of the book is built on the foundation of MBTI, though, so it's not worth considering the remaining content unless you've already drunk the MBTI kool-aid.

Taking Advantage of Students

When I first read this article on how some unscrupulous companies will try to bilk students by promising them high-paying summer jobs in the game industry, my thought was that this behavior is abhorrent.

My second thought is that it's unnecessary. Aspiring game developers already go to great lengths to convince themselves that they'll be able to enter the industry in the first place -- something that, sadly, not all of them will ultimately do. These people don't exactly need any extra false hope; most of them already have plenty as it is.

The one thing I make sure to drill into my game design students -- I probably mention this more than anything else in my classes -- is that no one should expect to get an entry-level game design job in the industry fresh out of college. Yes, a few lucky ones do, but it's so rare that no one should be relying on it as their primary career. I want no one to have any illusions about this.

This comes as a surprise to many students. After all, game development programs are sprouting up all over the place, so at first glance one might think that industry demand is increasing at a proportional rate. It's not.

As far as I'm concerned, any university that touts any kind of game development program (and especially anything involving game design) is implicitly telling prospective students that they will be able to get a job in the field that they're studying. This is just as much of a lie as the article I was reading. Compare:

"Get paid $80 per hour in QA for the summer! Just pay us a $39.95 membership fee."

versus

"Get a full-time job as a game designer! Just pay us $100K tuition."

As such, universities should be careful to notify all prospective undergrads that a game-focused major is dangerous: it doesn't guarantee a job in the industry and may make it more difficult to fall back on a job outside the industry. Given the time and expense it takes to earn any degree at all, these disclaimers need to be shouted loud and up front, before a student decides on what school to attend.

Some might protest that trying to talk students out of attending your school would lower enrollment. In my experience, though, the students who ultimately make it into the industry are the types who are well aware of the risks and who are dedicated and persistent enough to go through with it anyway. The students who would have second thoughts are precisely those students who would make your school look bad to the industry and lower the quality of your program anyway. So, in the short term you trade off quantity for quality; in the long term, your higher quality gets industry recognition which feeds back into greater quantity. Therefore, being up front with prospective students could actually raise enrollment in a few years!

Granted, you should have a quality program as well if your school is going to offer one at all. If your classes consist of teaching students how to tighten their graphics, you're not doing anyone any favors.

Textbook Review: Patterns in Game Design

This is part of the series on book reviews.

"Patterns in Game Design" (Staffan Bjork and Jussi Holopainen)

If you've never seen a book on Patterns before, this is likely to be different from your usual experience. A "Pattern" is, more or less, a common problem and its established solution. The point of a book of Patterns is to prevent you from reinventing the wheel with each new project.

Most Patterns books are programming-related, because programming is the most expensive part of game development, so a lot of cost savings can (theoretically) come from code re-use. Applying the same concept to game design is intriguing; as far as I know, this is the only book to do so (although similar works like the 400 Project existed first).

This book's concept of a Pattern is slightly different. It is more of an encyclopedia of game design concepts; for each concept, it explains what it is, what design decisions must be made to include it, and links to other related concepts.

Unfortunately, the book has some inherent flaws due to its very nature. For one thing, the field of game design does not have an established critical vocabulary, so the authors had to invent names for a lot of concepts that will be unfamiliar to designers or students. This makes the book read like a foreign-language dictionary: every time you try to look up the definition to a new word, the definition itself contains half a dozen words that you also have to look up. This makes for frustrating and dull reading, and since it's a physical book you don't even have the benefit of having hyperlinks to click on. This would have worked much better as a wiki than a book.

To make matters worse, the publishers decided for some strange reason to put about 200 of the Patterns on an included CD instead of in the printed book. However, many of the Patterns in the book reference those on the CD (and vice versa), so when looking at references you have to go back and forth between the two media.

I found the most useful thing about this book to be the overall taxonomy of concepts, where a game is broken down into major component parts (such as goals, rules and player actions) and then each of those parts has a number of concepts (e.g. different kinds of goals, such as Chase or Capture or Evade). This would fit well into a conceptual class on game design, as it goes into more detail than any other book I've seen on the list of concepts.

Students: You can safely avoid this book for the time being. You get enough tedium from the rest of your classes; there's no need to inflict more of it on yourself. Also, there's no obvious way to tell the difference between the terminology that is in common use in the industry, and that which is purely the invention of the authors; talking about Avatars and Bosses is all fine and good, but if you mention Hovering Closures or Focus Loci in your job interview you'll probably just confuse everyone else.

Instructors: The basic concepts in this book could be used in your lesson plans to supplement a theory-based game design class, when you talk about the component parts of a game. Just don't borrow the terminology that isn't in common use. I wouldn't recommend this as a required text for any class; it's not organized in any fashion that I can imagine being useful for a class, and it doesn't lend itself well to exercises. Keep a personal copy for reference when making your lesson plans, but keep it away from students.

Professionals: The terminology and organization of this book give it a large up-front cost in time; even if you just want to use it as a reference text, it's only practical if you've already read through (or at least skimmed) most of it already. If you do put in the time, it may be a source of inspiration when you're working on the core mechanics of a game... but only if the game is highly derivative by nature, because this book only documents common game features that already exist. In other words, it may help you solve problems that have already been solved in other games, but only in exchange for actively reducing your creativity.

Results of E3

Of the whole of the game industry, nothing has forced me to rewrite my lesson plans as much as E3 with its unexpected "downsizing" last year. So, I'll take this opportunity to read between the lines in the media coverage -- a useful skill that I try to teach in Game Industry Survey, since it's rare to see a negative spin on anything, but you can still spot it if you look closely.

Focus on First Party. ("First Party" are the console manufacturers, for those of you just joining us.) There was a lot more squawking about Xbox 360 vs. Wii vs. PS3 than there was about the games themselves. Given that this is the first E3 in the new console generation, I suppose it's only natural. But how quick people are to forget that a new system is only as good as its games!

Price Wars? There was a lot of talk about "price wars" among consoles. As far as I could tell, this consists of Sony threatening to drop the price of the PS3 and then raise it again, while Microsoft and Nintendo mostly ignore them. Doesn't a "war" require two parties? Maybe "price civil war" would be a more accurate description.

Console Hype. Overhyping is alive and well, thanks. Sony claims that Blu-Ray is the future and HD-DVD will be dead within months, so that's why you need to buy a PS3, yeah that's the ticket. Microsoft responds that their death has been greatly exaggerated, and by the way if it does die they'll just make a Blu-Ray peripheral for the 360, and we've got better games, so nyaah. Nintendo ignores them both and just states for the record that they think they'll sell a hundred million Wii. Wiis. Wii's. Wiii. Oh, whatever.

Games for Girls. Ubisoft announces "Imagine", a series of games targeted at girls age 6-14. Due to "extensive research" of the target market. And the games will allow girls to "explore their favorite interests and hobbies". Do these people not study their history? This is almost word-for-word what Purple Moon was claiming to do, and we all know how that turned out.

Oh, and I hear there were some cool games announced at this year's E3, too.

As for whether this is the death of E3, or same old same old, people seem split about 50/50. Personally, I'm more likely to listen to someone's opinion if they're not wearing a chicken suit. But hey, that's just me.

Textbook Review: Basic Game Design and Creation for Fun and Learning

This is part of the series of book reviews.

"Basic Game Design and Creation for Fun and Learning" (Nanu and Naveena Swamy).

It is books like this that give the rest a bad name. For starters, in spite of the title, this book has absolutely nothing to do with game design. It should not be surprising that the authors have no published titles to their name and have apparently never worked in the game industry, which is a strong warning sign for any book.

In reality, this book covers the basics of implementation in Game Maker, a game authoring tool. Now, I'm a big fan of Game Maker itself. But the help files and example games included in the download and the forums on the website are far better at explaining how to use it, and go into greater depth than this book does. So, the book itself is entirely worthless; there is no need for it to exist in the first place.

To add insult to injury, the book attempts to explain some basic Object Oriented Programming methodology... and actually gets it wrong! If you're going to use the term "polymorphism" and apply it to Game Maker, be sure you know what it means first.

Students: Avoid this book. If you're interested in programming games but you're not comfortable with the more technical programming languages like C++ or Java, then you might consider starting out with something simple like Game Maker. But the documentation with GM is sufficient, and if you absolutely need a book to read there are better ones.

Instructors: If you're going to devote an entire class to teaching a single tool, you'd probably be better off teaching Flash than Game Maker; Flash is more versatile and powerful, and it's actually used in the industry from time to time. Even if you do want to teach Game Maker as part of a larger course, there is no need to use this book to do it.

Professionals: If you're a non-technical game designer who wants the ability to express your ideas in the form of a digital prototype, again, Flash is probably the best tool for the job if you have it available. Game Maker can be used to make certain kinds of prototypes really fast... but again, there's no need to use this book.

Origins Report (Part 3)

As the board game and video game industries are inextricably linked, it's sometimes useful to compare the trends in both. Here are the recurring themes I saw this year in eurogaming:

• Pirate and superhero themes. No doubt this is to capitalize on the popularity of these themes in the movies. We often talk of the link between Hollywood and video games, but the link is very much there for board games as well.
• Animals. I found a disproportionate number of board games that featured animals, including three games with camels, three games with sheep (not including the line of Catan games), two games with cheetahs, and then the occasional monkey, giraffe, elephant, kangaroo or penguin. I have no earthly idea why the fascination with animals, or why it's so much more pronounced in non-digital games.
• Gladiator combat. If conflict is an inherent element of games, then it's no surprise that games should be particularly good at modeling a straight-up fight. Still, there haven't been many gladiator games in past years, so I'm guessing this year's rash of them is just a statistical fluke.
• Educational games. There was a game that could be described as the Periodic Table of Pokemon. Another game that taught K-6 math skills, with a superhero theme. And another that featured many historical figures, with the History Channel brand. The thing I found shocking is that these games are actually touting their educational value as their main selling point. While this may get some extra sales with teachers and parents, it probably loses just as many (if not more) sales from gamers who would play these games except that we all know how much educational games suck. I have to wonder what would happen if a company released the same game under two different names -- one with an obvious educational slant ("Numbers League: Adventures in Addiplication") and another where the education is intentionally hidden ("Stupor Heroes"). Same game, different name and box copy, in an attempt to capture both the educational and gamer markets. No one is doing this, but I think it's an opportunity just waiting to be grabbed by any or all of them.
• Shorter play times. Due I suppose to today's ADHD society, games are getting shorter. I noticed a large number of very solid, deep strategy games that were playable in 45 minutes (a couple of years ago, these kinds of games mostly took two or three times that long). I think this is great; I can play more games to a satisfying conclusion in less time. There are even some tabletop wargames that are playable in under an hour nowadays; thirty years ago, these were the kinds of games that would take an entire weekend to play.
• Longer play times. Perhaps as a backlash of the shortening trend, I also saw a number of games that take 3 to 6 hours. You can always tell these games because they come in these gigantic boxes with tons of boards and tokens and figurines, and they cost $80 or so. Interestingly, the video game industry followed this same trend with budgets, starting about five years ago: you have to either be a "value" (very low-budget) or "AAA" (very big-budget) game, with it becoming increasingly difficult to find funding in the middle. That trend continues in video games to this day, although it may start reversing itself with third-party Wii games.
• Reiner Knizia. Seriously, the man seemed to have at least one new game with every major publisher. I don't know if he's just morally opposed to an exclusive contract, or what.

Origins Report (Part 2)

Lewis "Lou" Pulsipher is another game-designer-turned-teacher. I seem to find more and more of us each year. He gave a session this year on game design. I was less interested in the content, more in how that content was presented (since that's the real challenge, isn't it?).

Lou is a big believer in documentation and backups. If you have an idea and don't write it down, that idea may never come to you again and it will be lost forever, so always have something nearby to record your thoughts. Regularly transcribe your ideas from the paper you wrote it down on to a computer document, and back up your hard drive regularly. Even if the idea goes nowhere right now, having it preserved lets you go back and dig up old ideas later on; they can be a source of new ideas, and you might also (years later) finally figure out how to get that old game to work. Having lost my own share of ideas over the years to lost documentation, I'm not going to disagree, and I found it interesting that he hammered on this idea quite a bit -- most game design books don't say much about it at all. I suppose this is the difference between theory and practice.


Also on the subject of documentation, Lou points out that many people don't want to read the game manual, they much prefer to have a friend show them how to play because it's easier. This is no big surprise to anyone who plays a lot of video games (nowadays it's standard for them to have an on-board tutorial that teaches you everything, so that the manual is superfluous) but the board game industry still hasn't caught on. Lou suggests that it would be very easy to audio-record a gamer explaining the rules of a board game, as if to their friends, juxtaposed with photos, diagrams or video. This provides a pretty efficient rules "document" that could either be packaged on CD with the game, or at least put on the publisher's website. Lou also mentions that this would be particularly useful for educational games; many teachers who aren't hardcore gamers would still like to integrate some games into their class, but they don't want to take the time to learn the rules.


Lastly, Lou proposes that a game can be broken down into nine atomic parts. Not all games have all these parts, but the sum of them could be used to completely describe a game His parts are:

• Theme/history/story
• Objectives or victory conditions
• Game state (he called this "data storage and information management" -- a way to record the important variables in a game such as victory points, board position, cards in hand, etc.)
• Order of play (turn-based, realtime, etc.)
• Movement and/or placement
• Information availability (that is, what information is visible or hidden from each player; this includes immediate information hiding such as a closed hand of cards or fog-of-war mechanics, but also includes unknown future information such as the outcome of a die roll)
• Interaction of game entities, including conflict resolution
• Economy: resources, the means to acquire them, and the means to exchange them
• Rules of player-player interaction outside of the game state (this includes mechanics such as trading, negotiation, auctions, and metagaming)

I find it interesting to compare this to the list of formal elements from Game Design Workshop:

• Players
• Objectives/Goals
• Procedures (I found this confusing in the text, but it essentially means the UI -- the actions available to the player allowed by the rules)
• Rules
• Resources
• Conflict
• Boundaries (that is, where does the game end and the Real World begin; includes physical boundaries such as a proscribed area of play, and conceptual boundaries that let the players know who "is playing" and who is not in the absence of physical boundaries)
• Outcome
• Dramatic elements (this includes story and narrative, but also the aesthetics created by the dynamics of the game itself, such as rising tension in a well-paced game)

There are similar elements on both lists, so it may be useful to combine them the next time I teach a theory-of-game-design class.

Origins Report (Part 1)

Last year at Origins, most of the sessions I went to seemed a bit... sponsored. As in, "Hi, I'm a representative from a boardgame publisher, and I'd like to tell you why you should use our games in your classroom. By the way, I have no experience in education, and I have no lesson plans, but don't let that stop you from buying lots of stuff."

This year was much improved. Publishers who were pushing their own agenda at least brought a good assortment of lesson plans and were presented by someone who'd been teaching for twenty years. Others, even if presented by someone who worked at a publisher, concentrated on practical content. And then there were the independents like me, just out to spread the word about whatever we had experience in.

Mark O'Bannon gave a primer on good storytelling practice. Since this was at a game convention, the subject was approached mostly from the perspective of "how to become a better GM by understanding what makes a good story", although the basic principles are the same whether you're writing a book, a screenplay, the plot of a video game or a tabletop RPG adventure. It occurs to me that "write a two-hour game session and then run it with fellow students in a group" would be an interesting assignment for a creative writing class.

The session was pretty basic, so there weren't many surprises for me: most of the content was taken from the holy trinity of Aristotle, Campbell and McKee. Two other books were mentioned as being useful in the context of game writing: "Characters and Viewpoint" by Orson Scott Card, and "How to Write Science Fiction" (someone said at the session this was written by Ben Bova, but a search through Amazon suggests this was Card also). I'll evaluate these later this Summer if I have time.

There were a couple gems in the session I hadn't encountered before:

• When creating a setting, build what O'Bannon referred to as a "community of opposites": character rivalries, feuding factions, environmental hazards, etc. -- things that exist as sources of conflict in the setting itself.
• On the subject of showing character, a useful way to think of this is to have two emotions fighting against each other. When one emotion wins, that's when you see a person's true character. (Example: pride vs. fear. Put a proud character in a dangerous situation and see whether they fight or flee.)
• McKee especially talks a lot about how the main character should change during a story, but O'Bannon points out that this doesn't have to be the case; it's possible for the main character to be more of a catalyst, someone who causes change in all that he touches, without actually changing himself. An example would be Kwai Chang Caine.

This post is already getting pretty long, so I'll summarize the other sessions later.

Speaking at Origins: Final Details

As promised earlier, here are the details of my speaking engagement:

I'll be speaking twice, once on Thursday July 5 at 9am, and again on Friday July 6 at 3pm.


The title of the talk is "Why use games in a classroom?" but that's actually not the best title. Presumably everyone attending Origins already understands the positive effects of gaming, and anyone attending a session for teachers is already on board with the whole games-for-learning thing. I'll actually be talking about some basic game design theory (i.e. "What Makes Games Fun") and then applying that to education, to make the class time more engaging for students.


If you're in the area, drop by and say hi!

Textbook Review: A Theory of Fun for Game Design

This is the first in a series of book reviews. I'll start of with one of the few useful books I've read.

"A Theory of Fun for Game Design" (Raph Koster).

Everyone involved in game design -- students, teachers, and professionals -- should read this. It's very short, uses a large font, and every other page is a cartoon; you can read through it in an afternoon. It makes the case that learning is the source of fun in games, and that game designers are just a specialized type of educator.

This book is fairly light in content; it's not about how to design games, per se, but about what game design actually is. Probably the most important thing you can get from this book is a way to describe your field to friends and family who aren't gamers (particularly those with the attitude of "why are you wasting your life with those games, instead of studying something real?").

Students: Due to its brevity and tight focus, this is one of the few books that is easy for a student to just pick up and read on their own. If you're broke, you can always just read the thing in your local Borders some random afternoon.

Instructors: I think it would be tough to use as an actual textbook in class; it's too short. For classes where this book would be appropriate, just read it yourself and prepare a lecture that summarizes the key points. And then encourage students to read the entire book on their own time, if they find the topic interesting. Another option would be to require it as one of several short textbooks, and include assigned reading (with a summary report to be handed in) as part of a larger class -- either mandatory, or for extra credit.

Professionals: Pretty much every game designer I know personally has already read this book. If you haven't, you probably should, if only because it comes up in conversation from time to time. But if you work with other designers, they were probably bugging you about reading this long before I made this post.

Textbook Reviews

Last Summer, I posted a proposed college curriculum for game design. That project is complete, so I would be in need of a new Summer-long blogging series for this year.

Books on game design are tricky things. There's an awful lot of material out there, enough to be quite daunting to the student, teacher or professional looking for the right one. A disappointingly large percentage of the books out there are practically worthless, and telling them apart from the "good" books often requires enough experience that you wouldn't need the book anyway. Fear not; I shall wade through the mountains of manure to find the few shining gems, so that you don't have to.

Then there's the matter of breadth. Game design is a huge field, like Science; you could no more write a single unified textbook on "game design" any more than you could write a "science" textbook. Every book will necessarily have its own specialization, so even the books worth reading may or may not be useful to a specific designer.

I will comment on several things for each book: first, the focus of the book (because the books themselves rarely tell you), and whether the writing on that topic is worth a darn. Next, the intended audience; again, the books themselves will almost always say they're "for everyone" or "for all levels" because the publishers know better than to limit their audience, so I'll provide my own opinion of who the book really seems most useful for. Then I'll talk about each of the three groups that comprise most of the readers: is the book suitable for a student studying on their own; is it useful for a practicing game designer in the industry; and is it useful as a textbook for a class (and if so, which class).

I realize that some of this may involve biting the hand that feeds me, since many of these books were given to me for free by the publishers so I could evaluate them as potential textbooks for my own classes. In this case, I feel my allegiance should be more to the cause of education than the financial interests of book publishers; if anyone wants a good review from me, they'll have to write a book worthy of it, plain and simple. (I receive no kickbacks or other compensation whatsoever for anything that I post here, nor will I ever do so. I promise.)

I will also include links to all reviews from this post right here, same as last summer, so bookmark this one later if you want the complete list:

A Theory of Fun for Game Design, by Raph Koster
Basic Game Design and Creation for Fun and Learning, by Swamy & Swamy
Patterns in Game Design, by Bjork & Holopainen
21st Century Game Design, by Bateman & Boon
Game Design Workshop, by Fullerton, Swain & Hoffman
Rules of Play, by Salen & Zimmerman
Game Design: From Blue Sky to Green Light, by Todd
The Game Design Reader, by Salen & Zimmerman
Game Design, Theory and Practice (2nd Ed.), by Rouse
Fundamentals of Game Design, by Adams & Rollings
Introduction to Game Development, edited by Rabin
High Score!, by Wilson & Demaria
Introduction to the Game Industry, by Moore
Chris Crawford on Game Design, by (surprise!) Chris Crawford
Break into the Game Industry, by Ernest Adams
Teaching Videogames, by Oram & Newman
Challenges for Game Designers, by Brathwaite and (shameless plug) myself
The Art of Game Design, by Jesse Schell

If Game Design were Painting...

Here's another way of looking at what game design is, thanks to a recent conversation I had with Brenda.

Suppose I have this great idea for a painting, but I don't have the artistic or technical ability to pick up a brush. I could spend years learning anatomy, perspective drawing and the use of various tools, but that would take too long. I can picture this thing perfectly in my mind's eye, although once it's actually on physical canvas it might not look as cool as I'd originally thought. Or, maybe I have all the ability that I need, but I just don't want to put in the effort, because painting is hard work and takes a lot of time.

So, instead of doing it myself, I'll write down a detailed description of exactly what I want painted. I'll include all kinds of details, descriptions of characters and background scenery and color... although my vocabulary might be a little strange to a professional artist, if I never learned technical terms like "vanishing point". Then I'll give this description to a professional artist, and if my idea is cool enough maybe she'll make the painting for me.


Suppose I manage to find a willing artist. A first draft of the painting is made. I offer corrections, in some cases because the artist's work includes better ideas than what I'd originally envisioned, and in other cases because I was unclear in my "spec" and the artist misunderstood what I wanted. We go back and forth like this for awhile. Finally, the painting is done and we're both happy with it (or, I decide that it's "close enough" and I need the money). We sell the painting. I get all the credit, because it's my idea, and the painter was just my instrument. The painter gets more of the money from the sale, because of supply and demand (fewer people want to build someone else's idea, than to come up with the ideas themselves).


Of course, this would never actually happen for a purely creative work. And yet... that's more or less the relationship between game designers and game programmers. And part of me has to wonder how we game designers can possibly get away with it.

A Reusable Game Design Exercise, Iteration 2

Awhile ago, I posted a way to randomly pick a set of constraints for a Game Jam. I actually used it to generate one of my final exam questions for the Digital Game Design course ("write a one-paragraph game concept that fits the following constraints...").

Alert reader Nathan Ostgard pointed a few things out to me in email:

• Exercising your skill of "learn to work within a set of constraints" requires different materials than exercising your skill of "be creative and come up with something new". My original spreadsheet is very much geared towards the former, and is not all that suited to the latter (mostly because it forces you to work within existing, well-established genres).
• There is a difference between Theme and Setting. I lumped them both together without really thinking, but you could easily separate them.
• You can easily add additional categories of constraints; the five I originally listed are by no means the only ones available.

He built a spreadsheet with the following categories, and elements in each category:

• Setting: Fairy Tale, Fantasy, Futuristic, Medieval, Mythology, Modern, Steampunk. (I would add: Historical, Historical Fiction.)
• Theme: Action, Adventure, Comedy, Crime, Drama, Horror, Mystery, Romance.
• Objective: Align, Avoid, Build, Chase, Collect, Destroy, Escape, Explore, Find, Grow, Race, Solve, Timed.
• Perspective: 3D Chase, 3D Eye, 3D Roaming, 3D Static, 2D Side, 2D Top. (I would add 2D Isometric, and the so-called "2.5D" of games like Viewtiful Joe.)
• Bonus: Abstract, Cooperative, Emergence, Five Minutes, Fog of War, Luck, Physics, Rulebreaking, Self-Expression, Sensation, Social, Squads, Turns, Vector.

Thanks, Nathan!

Pieces of Paper

A little while ago, two students presented very different views of my classes.

One student said that he took his tuition and divided by number of credit hours, and figured that he was paying about $120 for each of my two-hour lectures. This perspective made him extremely hesitant to ever miss class -- every time he did, it was like buying two new games and throwing them away!

Another student cynically disagreed, saying that what he was really paying for wasn't class time, but the piece of paper you get when you graduate. To him, the real value of school was its ability to qualify you for a job where you can "do interesting stuff".

The true irony is that this second student was in my Capstone class, working on a team to develop a game!

I wonder how I can best put up a resistance to this second attitude. Other than just being the best teacher I can, of course.

Fun with multiple choice

I prefer my exams to contain essay questions, because they offer greater opportunity for expression; they're harder to copy without cheating being obvious; and they give me a better idea of just how much my students grasp the material. The down side is that they take forever to grade, so I can certainly understand the practical consideration of a multiple-choice exam -- especially since the professor is under time pressure to turn in final grades at the end of the course.


Brenda, another game-designer-turned-professor, says to me about multiple choice:

For a multiple choice exam, you can create the silliest answers, and people will select them. It's like a mini-game. My favorite silly answer is "Costikyans". I use it a lot. We talk about Greg's articles regularly in the quarter, and it still surprises me when someone selects his name as an answer. In this case, the correct answer should have been "Semiotics."


I'll have to try that some time, just for laughs.

And now that she mentions it, if I ever make an RPG, I'll be tempted to name the currency the Costikyan. It doesn't sound that much more odd than, say, Gil, Potch or Zenny. "A sword of flame? That'll be 300 Costikyans, please."

Correcting the Answer Key

During the process of grading a final exam, one student's answer to a particular question was very different from my own "correct" answer, but persuasive enough to make me question my own assumptions.

After looking a few things up, I think the student is right. I now have to change my own answer.

Naturally, this was the last exam I graded, so now I get to go back through every single other one and redo the grading on this question. (I won't take points away from students who made the same mistake I did.)

I have to wonder how common this is. I know that every teacher says they learn as much as their students, but I didn't expect to be learning things after the class was already over.

Extra Credit

On my take-home final exam, just for fun, I included an extra credit question: "What is the secret code?"

I gave out the code on the last day of class, as a bonus for anyone who was there. It turns out that every student was there.

Some students missed the question. I have no earthly idea how they managed this.

Some students not only missed it, but made up their own code. Predictably, most of these students guessed the Konami Code. Except that -- get this -- they got the code itself wrong. I seriously considered giving negative points for this question in such a case, as penalty for defiling the memories of my youth.

The down side of take-home finals

The day that my take-home final is due, it occurs to me there is one slight drawback, especially if the exam is sent to students online:

All of my students now have a permanent copy of the exam, so I can basically never use it again without making serious changes. (At least, not in the same school.)

I'll have to keep that in mind next time.

The Final of a Thousand Faces

I've discovered the joy of the take-home final exam. It's like telecommuting: my students don't have to show up at any scheduled time, and I don't have to make the trip to campus. I'll definitely have to do this more often.

In one of those "why-didn't-I-think-of-that" moments, I recently heard of an interesting compromise: a "take-home" final that is posted online at a specific time, and must be turned in within 2 hours. Essentially, this contains the time pressure of a standard exam, but without everyone having to be in one place. I suppose it makes it tougher to police cheating... except that I prefer essay questions anyway, which are really hard to copy without the cheating being obvious (especially if the test is timed).

Self-Censorship

Game designes often struggle with "edgy" content. Do we put in this extra thing because it's cool, or leave it out because it might push the game's rating to M when the publisher demands that it be T? Or, even if it's an M game, maybe this is just a little too offensive; we don't want the industry to have to go through Hot Coffee all over again. And then we criticize ourselves for being too hypersensitive, and doesn't the industry have to deal with enough censorship without us doing it to ourselves?

Well, I just had that same kind of feeling when teaching, for the first time (and probably not the last). I encountered a game that would make a great example for my Game Design class, for why the theme of a game can make a huge difference in player experience even if the underlying mechanics are the same. In particular, there's this game that is mechanically an uninspired clone of a street-fighting game... but the theme is either going to be hilarious or offensive depending on who you talk to, because the playable characters are from the Bible. So, I only brought it up after class, to a few select students who I knew would appreciate it. And now I'm chastising myself for putting political correctness before education.

Life Imitates Games

Within the space of one day, I have two student game concepts that are imitated by the real world.

One concept is an anime-inspired "bunny girl versus cat girl deathmatch" sort of game. This morning on the radio I hear about an endangered species of bunnies being attacked by feral cats.
Another student proposed a collection of carnival-midway-style minigames, sort of like the retro game Carnival only with more variety. Today I see an announcement about just such a game, to be released for the Wii.

The news was dated after the assignments turned in, so it's just a really odd coincidence. (Or, my students are just really good at predicting the future. Maybe I should ask them to consider a career in meteorology.)

Bonus coincidence: my Capstone class has been working on a game for the past 20 weeks with the theme of killing your avatar in the most entertaining way possible (as a reversal of the standard goal of saving/protecting your avatar). Then I find a game called Five Minutes to Kill (Yourself)... thankfully, with very different mechanics.

Emergent Design: Student Paper Prototypes

If you're a designer, you haven't truly lived until a classroom full of students brings you paper prototypes of their video game proposals to evaluate. This was the most fun I've had grading. Ever.

Pretty much every student had at least one thing in their prototype that the rest of us (including me) can learn from, even if it was "don't do this". Failures of prototypes usually teach more than successes. Some students (correctly) failed on their own several times, threw away their own work and brought in something that worked much better -- allowing them to discuss failures AND successes.

I did have some assignments like this back in the Fall, but the students were leaping right into prototypes without first writing up a formal treatment (and also without having a solid foundation of game design theory to build on), so I think for best results this really should be a three-step process (theory, then treatment, then prototype).

The only part I had difficulty with was when a student brought in something that served as a negative example. Having your prototype harshly critiqued in front of an entire class would be mortifying, so part of me wanted to just move on without too much discussion... but on the other hand, part of me wanted to call this out as a great learning opportunity for the entire class. I think I managed to split the difference, embarassing a few students without providing the education for everyone else. Some day with more practice I'll find a way to do that better.

Culture Shock: Doing the Work

As my class ran under time today and students left about half an hour early, it occurs to me that the decision to cut things short was met with enthusiasm -- not because my students hate taking my classes (I hope!), but they've just been conditioned through years of education to get out of class as soon as possible.

This sort of thing doesn't happen in industry. If I'm working as a game designer and spontaneously decide to take half of the afternoon off, the rest of the team isn't going to heave a sigh of relief that I'm leaving (nor is the publisher, or the client). But here, my "customers" are perfectly happy if I'm not doing the job I get paid to do, at least to a certain point. It's rather unsettling, really.

Culture Shock: Transparency

In every game company I've worked at, management was pretty transparent. It's not like you could always walk into the CEO's office and ask to see the financials, but in general any company-wide decision was justified to the employees and there was room for discussion. Often there was discussion before any decision was made.

Universities aren't like that. For one thing, they're much larger than your typical game dev studio, so there's a lot more things going on at once; if you were informed every little detail crossing the desk of your boss (and your boss's boss, and boss's boss's boss) you'd have so much information to sort through that you wouldn't have time to get any work done. Also, I think there's more of an overall attitude that people should be separated; professors should teach and do research, administrators should administrate, and no one needs to be aware of anyone else's job. Information is distributed on a just-in-time, need-to-know basis.

I understand that there are very practical reasons for this, but at the same time it's still unsettling to not really be aware of what's going on around me. I hear the results, but not the reasoning... so when I hear "such-and-such department now has a new vision" I have no way to place that information in the proper context. I also worry that such opaqueness at the management level, whether at a university, company or government, opens the door to abuse of power since there's less accountability. Not that this will absolutely happen, mind you, but the door is open.

I suspect this isn't an "industry vs. academia" thing, so much as a "small vs. large organization" thing. All of the game studios I've worked for have been small: dozens of people, not thousands. And it's not like I can find a 30-person university to compare.

Speaking at Origins

In the board game industry, there are two major public-facing events in the US (similar to what E3 used to be for video games). One of them, Origins, takes place pretty close to where I live... and as if that weren't enough incentive to attend, teachers get in free.

Part of this education track involves access to a set of lectures and workshops about using games in the classroom. Most attendees teach something non-game-related, and many teach at the K-12 level.

I'll be speaking there for an hour on Friday morning (with a repeat on Saturday afternoon) on some theory of game design -- specifically, what makes students prefer games over classes -- and then how to incorporate that into the classroom to make it more engaging.

I'll post more details as they become available.

A Reusable Game Design Exercise

One of the designers I worked with at Cyberlore, Jesse King, once came up with a wonderful design exercise. He made some lists of game elements (mechanics, themes and such), put them in Excel, and used the functions VLOOKUP and RAND to display a random element from each list. Your goal as a designer is to come up with a one-paragraph game concept that contains all the given elements. Then you hit F9 (in Windows, anyway) to reroll and get a new set of elements. Repeat until you realize you've been doing this all afternoon, and then sheepishly return to your day job.

It occurred to me that a "random game idea generator" such as this has two academic uses: in the classroom (as a fun brainstorming exercise or even on an exam), and as a way to randomly pick a theme for a Game Jam.

I went ahead and made one of these specific to a Game Jam environment (that is, it avoids game elements that would be difficult to implement in a short time, such as 3D worlds or online multiplayer). It has the following categories, and elements in each category:

• Theme: Medieval Fantasy, Modern Fantasy, Modern Sci-Fi, Futuristic Sci-Fi, Alternate History, Romance, Drama, Crime/Mystery, Survival Horror, Ancient Mythology.
• Genre: Turn-Based Strategy, Realtime Strategy, 2D Platformer, Overhead Shooter, Scrolling Shooter, Sim, Graphic Adventure, Puzzle, Time-Based/Racing, Dance/Rhythm.
• Core Aesthetic: Physical Sensation, Growth/Advancement, Social Experience, Fantasy/Escapism, Narrative/Drama, Challenge, Discovery/Exploration, Deliberate Rulebreaking, Control/Leadership, Probability/Chance.
• Objective: Chase, Race, Kill/Destroy, Build, Collect, Avoid, Spatially Align, Escape, Explore, Solve.
• Design Challenge: Squad-Based, Nonstandard Control Scheme, Diplomacy, Feedback Loops, In-Game Economy, Emergent Systems, Fine Art, Training/Education, Fog of War, Abstract Graphics.

If you have any suggestions to add to any category, feel free to suggest in the Comments below.

If you'd like a copy of the Excel spreadsheet, email me at ai864 at yahoo. If you don't like Excel, you can do this with index cards instead; write a game element on each card, sort the cards into categories, and draw one random card per category.

Additional variants:

• Allow the designer to ignore any one category, but the game must fit all the others. This relaxes the restriction, and might be ideal in a Game Jam if you want more variation between teams.
• Choose game elements chosen randomly from among all the categories, so that you may get some blank categories and some categories with several elements that must be satisfied simultaneously (e.g. you may have two "genre" elements, 2D Platformer and Turn-Based Strategy, and you'd have to find some way to combine the two).
• Make a game out of it with several designers present: the first designer generates a single random game element and proposes a game that contains that element. The second designer generates a new element and must propose a game that contains both elements. Continue until a designer can't think of a game; they're eliminated. Also, you can't re-use earlier game concepts; you must propose a new one each time.

Written Exams

This past Thursday marks the first day I've ever given a midterm, and the second time I've had anything resembling a standard written exam.

It's much harder to make a written exam "game-like" without having rules that are so confusing that they get in the way of evaluating students' mastery of the material; the best I could hope for was an exam where students found the questions interesting and thought-provoking. (This meant essay questions. Lots and lots of essay questions. 18 of them, to be precise.)

Mostly, students complained about a two-hour written exam due to hand cramps. They can play video games with an ergonomically-destructive N64 or GameCube controller for ten hours straight, yet two hours of writing and they've suddenly got carpal tunnel. I don't get it.

Having never made an exam like this, I was afraid that it would be too easy, or too hard, or too short, or too long. As it turns out, it looks like I had some serious beginner's luck; no one ran out of time but most students stayed nearly till the end, and so far it's looking like the grades will fall on a nice bell curve. If I've made a serious mistake, it's setting myself up to grade 18 essay questions for 23 students over a single weekend (which is, honestly, much more writing than two hours on a single exam). No hand cramps yet, even with playing Guitar Hero during breaks!

Culture Shock: Citations in Games?

When an Academic writes a research paper, the paper generally cites a large number of sources. This serves several purposes:

• The more sources a paper cites, the more legitimacy it appears to have at first glance, since it is building on established material. Especially if it cites sources that are already well-known and established in the field.
• The more papers that cite a specific source, the more weight is given to that source, and the more prestige to its author(s).
• It helps avoid claims of plagiarism, copyright infringement, etc.

Ultimately, it benefits the creators of the cited work and the new work.

Games don't really do this. In the industry, an obviously derivative game tends to not list the game it's derived from in the credits, even under "special thanks". Sadly, this is even the case in direct sequels, where the team that built the original engine may get no mention in the credits of the sequel. The closest we get is paying homage to an older game by including an easter egg as a direct reference.

It struck me the other day just how wrong this was, when a student of mine pointed me to a game called Bubble Tanks. This game is an extremely obvious ripoff of Jenova Chen's flOw: both take place in water, both have relaxing background music, both let you grow by defeating enemies and shrink by getting hurt, both send you back to easier areas if you get hurt too much. Bubble Tanks adds the ability to shoot, and that's about it. And yet, Bubble Tanks makes no mention of flOw, either in the main screen or in its credits. "Special thanks to Jenova Chen for inspiration" would have been appropriate, no?

The issue is even muddier in this particular case, since flOw was part of a graduate student project, as the practical application of a written thesis. If Bubble Tanks were also a thesis project, you can bet there'd be some serious allegations of academic dishonesty; and if flOw were simply a commercial project everyone would call one or the other a "clone" and be done with it. But when a game crosses boundaries from Academia to Industry, then what? (Not to mention that flOw was commercialized; you can play it if you have a PS3.)

What do you all think? Should commercial games be required (or at least encouraged) to list the games that inspired them in their credits somewhere? I think it'd be useful, in that it would make it easier for Game Studies folks to trace the history of games and game mechanics... but at the same time, I don't see it happening any time soon. Which brings up another question: why the difference between academic projects and commercial ones?

The Many Faces of the Game Designer

If you're a student taking my Digital Game Design class, consider this a spoiler warning: we'll be covering the topic in this post later, so turn back now if you don't want to ruin the surprise.

Now, for the rest of you...

Explaining what "Game Design" is to people outside the industry has always been difficult, because it's such a broad field with such a wide variety of tasks, and because it's intangible (i.e. generally, you can't point to any part of the screen of a video game and say "that thing there is game design"). Yet, it is vital for us to be able to explain what we do to the rest of society -- or at least to our friends and families who want to know more about our lives. And for ourselves, so we can constantly remind ourselves of why we shouldn't just give it all up and become accountants.

So far I've found the following analogies useful:

• Game Designer as Architect. We don't build the game (or skyscraper) ourselves, we just outline the plans (game design documents / blueprints) to let the programmers (construction workers) know what to build and what it will look like when it's done. As far as I know, this analogy is original, and I was the first to state it this way.
• Game Designer as Party Host. We invite the players to play our game (visit our party), and do our best to make it an enjoyable experience for them. I first saw this analogy in the first few pages of the recent textbook Game Design Workshop.
• Game Designer as Artist. Much of game creation is just like the creation of any art form. This is self-evident to most game designers I know, but was proven ever so succinctly by Scott McCloud's Understanding Comics (which is as much about Game Design as it is about Comics, as any game designer who's read it can tell you). This was also touched on by Raph Koster in his book, A Theory of Fun. And of course there's been the question of "whether games are art" that has been argued on both sides since the birth of the medium... and if games are art, then it's not much of a stretch to say that designers are artists.
• Game Designer as Educator. Raph Koster's book argues this as well. In brief, the theory goes that games are fun because they keep us in the "flow", i.e. giving us tasks at the upper end of our abilities; our brains find this an enjoyable state to be in because they are improving by learning; thus, games teach... which means game designers are teachers. Raph makes the argument far more persuasively than I do.
• Game Designer as the Judicial Branch of the Government. Donald Norman, in his book Design of Everyday Things, famously states that "design is the successive application of constraints." Then designers are the ones who place constraints on the player -- you must do this, you can't do that -- similar to lawmakers in the rest of the world.
• Game Designer as God. No idea who I can attribute this to, and of course everyone who's passionate about any field thinks that God is one of their kind. But I mean this in the literal sense; we create a world, its inhabitants, and all of the rules that govern it... and yet, we also create free will (as exerted by the players). Generally, our games are much less complicated than the physical Universe, but the basic principles of creation are the same.

Do you have any other analogies you'd like to share? Post them in the comments.

Virginia Tech

I heard about the shootings yesterday morning on NPR. While driving to school. This gives a perspective that you don't really have when you're working for some software company. (Especially a game company. For all the talk of video games causing violence, I don't think there's ever been a single case of a workplace shooting in the game industry.)

It was appropriate for me to say a few words to my morning class about this. I started off by saying that I gave it a week before the first news story linking the killing to violent video games. I forgot about Jack Thompson, who was on the media scene within eight hours. I didn't expect a second volley from Dr. Phil. Ouch.

I said that any student asking themselves Why This Happened will find plenty of easy answers, all of them wrong. Those wishing to find the truth will have a difficult search, but hopefully a rewarding one.

For those students who wanted to explore their thoughts and feelings on the subject further, I recommended two movies and two games to get them started:

Arlington Road. Granted, the movie is about terrorism and not school shootings, but the lesson is the same: lots of people care more about having the false security that an incident is over, than learning the truth.

Bowling for Columbine. A documentary that examines shooting deaths directly.

Super Columbine Massacre RPG. Despite the obviously-inflammatory title of this game, it examines the anatomy of a school shooting from the inside. My students who played it already said that it made them feel very uncomfortable. And I think that's the point; if you aren't uncomfortable when examining a national tragedy, you're probably taking the easy way out.

Doom. One of the games most often cited as a catalyst in violent crimes. Thus, it's important (especially for students studying video games) to actually play the original game and decide for themselves just how much of a "murder simulator" it really is.

For what it's worth, my students had varied perspectives on the shooting... but we could all agree that our sympathies lay with the victims and their families and friends.

IGF Student Games

One last bit from GDC was the IGF Student Games roundtable. I was sad to see that the room was almost all students, no faculty. There were three IGF judges there, including one who judged student entries, and their advice was invaluable.

If you're a student creating a game, you should be thinking about making it worthy to submit in the IGF when you finish it. If you're a professor running a project-based class where students make a game, you should be thinking about encouraging your students to make it worthy to submit to the IGF. Any student team that becomes a Student Showcase winner gets some media exposure, and will therefore have a much easier time finding jobs in the industry.

My notes from the session, on how to make your student game project as competitive as possible:

• IGF student games should not be full productions. You only get about 5 seconds to hook a judge, and even then they’ll only have time to play your game for about 10 minutes.
• Consider your game as a “Demo”: Get to the “meat” (fun) of the game instantly… within 5 seconds; easy install/config helps a lot; about three good, well-defined levels will give about 10 minutes of gameplay.
• This year there were 108 submissions, 10 Student Showcase winners, and one grand-prize winner. “Don’t enter to be the William Hung of the IGF.” Only enter a game that you think can really compete. All of your first-semester individual student projects should not be entered by rote (although some of them may be good enough to enter). Generally, your game should be a good game.
• Include an automatic Install, and Uninstall. Judges don’t appreciate random stuff that’s stuck on their personal computers. There are plenty of free install apps; use any of them.
• For long-term student projects, you can still submit a project even if some of the original team has graduated. In fact, graduates can still work on the game, as long as they don’t get paid for their effort.
• Judges repeatedly used the word “polish” to describe what they’re looking for in a game, but were clear that this isn’t just about expensive production values. Game should be a complete experience. It shouldn’t feel like there are unfinished features. (Missing levels, sure, but not missing functionality.) Game design should clearly have undergone iteration. It should be fun. Game interface should also be iterated on. Does the game give good feedback? Is the UI “juicy”? Does the game train you to play it?
• Students would do well to check out the non-finalist games of the previous year to see what didn’t win. Decide for yourself why they didn’t win, and make sure your game doesn’t fall into the same trap.
• Focus test your game. A lot. When doing this, don’t tell people how to play it; just sit them down and see if they can figure it out. You learn a lot from watching people struggle, in particular with what player expectations are. One memorable quote from a student team: “We thought everyone was playing our game wrong; then we realized they were playing it right, and we made the game wrong!” It occurs to me that this is good advice for any development team, not just students.
• Make your game single-player (or, if it must be multiplayer, include a one-player version). It’s hard for judges to coordinate to play a multiplayer-only game. Memorable quote: “A multiplayer game is just another person doing the AI for you.”

Common mistakes for student games that keep them out of the top ten:

• Bugs/crashes, art issues, or other obvious flaws (of course).
• Accessibility: what’s happening when you start the game? Does the player have any idea what they’re doing, what the controls are or how the game works?
• Language issues: use clear English in your instructions (this is mostly a problem with foreign teams).
• No gameplay, just walking around in an empty level. No matter how brilliant your game engine is, you need to create at least some content to show it off.
• If the game is clearly in a genre, make it immediately obvious what makes your game different. The judge should not say “great… not another undifferentiated FPS/side-scroller/whatever”.
• Too difficult. Some games are supposed to be difficult and that’s fine, but don’t kill off the judge before they get to the fun part.