Wednesday, October 21, 2009

Textbook Review: The Art of Game Design

It's been awhile since I did one of these, mostly because I've been busy with other things aside from reading. I'm glad to be looking at textbooks again, because quite a few interesting ones have surfaced in the past year or two. And so today I examine:

"The Art of Game Design: A Book of Lenses" (Jesse Schell)

Now, this book came out about the same time that mine did, and it managed to steal the spotlight, so I really wanted to hate it. But it really is a solid book, and fully deserves the praise it has been receiving.

The information is solid, as I would expect it to be. Game design is a broad field, and Jesse has an even broader skill set, allowing him to effectively write about game design... but also about a variety of other fields that game design can (and should) draw from. This on its own makes the book stand out; many books that are supposedly on game design do not teach the first thing of it, so it is nice to read from someone who actually knows what he's talking about.

The writing is very conversational and even intimate in tone. Only Jesse could have written this, and his voice is very clear in the writing to anyone who has met him. There are no practice problems or quizzes, making it feel more like a guided tour than a stuffy textbook. I found it easy to start reading, easy to keep reading, and very accessible throughout.

Perhaps the best part, the part that I am likely to steal for my own classes, is the organization of the book. Each chapter introduces one aspect of game design, such as story, game worlds, game mechanics, game balance, or the iterative process. The topic is explored in depth, and connected to other topics. Throughout the book, a concept map is built piece by piece, chapter by chapter.

The book is comprehensive, covering not just the core concepts of game design but also everything immediately surrounding it: interfacing with the rest of the development team, dealing with companies and funding and profit-making, player communities, and so on. While a "pure" game design course might eschew these kinds of peripheral topics, I find their inclusion necessary as a way to prepare students for the realities of the industry: you are not going to be creating your own games from whole cloth, you will be designing other people's games according to their own constraints, so get used to dealing with that on multiple levels.

Embedded within each chapter are a series of "lenses" as alluded to by the subtitle. Each lens is one way to evaluate a game-in-progress, and includes one or more direct questions to ask of the current iteration. Many of the lenses directly reference one another (or sets of lenses are grouped together in the text), making something of a concept map between them as well.

If the book has any weakness as a course textbook, it is that it does not give exercises or other tasks that could be assigned as homework, so the teacher will need to provide that on their own. Additionally, the book seems to naturally assume that the reader is already working on their own game idea; it therefore does not provide any direct call to action for readers (particularly students) who may not know where to begin if they have not already started. In this, it actually makes a great companion to my book (which is practically nothing but a series of constraints that can be used to start a game project).

Students: If this textbook is not required reading in your game design courses (or especially if you do not have any game design courses), take some initiative and go read it yourself. Its combined breadth and depth make it an ideal starting point to show you all practical areas of game design and (most importantly) to get you thinking like a designer. Think of it as a foundation, upon which everything else can be built.

Instructors: This book is perfect for an intro game design course. You could cover a selection of topics that are of interest to you (or that best fit your curriculum), or try to cover all of the topics briefly just to give some exposure (as you might in a survey course). Consider having students hang onto this text so that some parts can be referenced in higher-level design courses.

Also, if you are just planning out your first game design course, you could do worse than following this book (addressing each chapter in the order it's presented) as a rough syllabus.

Professionals: A lot of the information here might seem basic if you are an experienced designer. That said, we all have our weaknesses -- a technical designer might not be great at building worlds, while not all story writers are proficient at game balance -- and this provides an accessible way to get at least a minimum baseline of understanding of those other parts of design that are so mysterious to you. The most useful part will probably be the lenses themselves (of which you can purchase a separate deck of cards, one lens per card, as a quick-reference) as they provide an easy way to objectively examine the game you are currently working on.

Thursday, October 15, 2009

Lessons from SIEGE

For those of you waiting patiently, I am now back, and can hopefully get back to a quasi-regular posting schedule. This summer's online course took pretty much all my attention, and I am now getting caught up.

(For those of you working at game companies or academic institutions, I'm going to teach another free class next year, and am looking for sponsors. If you want to broadcast your message worldwide to people interested in learning game design, email me: my address is ai864, and it's a account.)

I returned just last week from SIEGE 2009, a small conference in Atlanta. Even though it is largely focused on game development in Georgia and the surrounding region, for some reason they like to bring me down there. I spoke on a panel about experimental games (short version: find them, play them, make them) and ran two game design workshops. Here are my takeaways from the conference:

Game Writing

Story/dialogue/creative writing is one of my weak points as a designer, so when people who know about this stuff are speaking, I pay attention. This session was given by Bill Bridges, Nathan Knaack, and Joe Carriker.

  • Create a backstory document for internal use only. The idea, I assume, is that you should know enough about your world that (especially if you use multiple writers) you can avoid contradictions and continuity problems. This was referred to as the "writing equivalent of concept art."
  • The hardest part of game writing is making it succinct, because game writers instinctively want to write long walls of text (which leads to the "TLDR effect").
  • Separate the gameplay-relevant text from the flavor text (flavor text is, by definition, that text which is not useful for gameplay and is purely for the enjoyment of players who want to know more about the story world). A good example of this was given in World of Warcraft, where the text for a quest includes a short gameplay synopsis ("kill 5 rats") alongside a large block of flavor text (telling you why you're supposed to care about killing 5 rats).
  • Someone asked, why not include some gameplay text inside the flavor text, as a way of giving a gameplay bonus to those players who read the story? Great answer: if you do this, you are giving a gameplay advantage to precisely those players who don't want it! The players who care about getting more plusses on their equipment are the ones that ignore your story because it slows down their power-leveling, and if you force them to read your elaborate story just for an extra +1 they will resent you for it. (The roleplayers who just want to immerse themselves in the story, meanwhile, are more concerned with reading the story then optimizing their stats.)
  • Corollary: one positive trend in game writing these days is to try to embed the story in such a way that it is optional -- players who care about it can spend all the time they want reading it, but it should not get in the way of players who just want your story writers to shut up and get on with the game already. (Ideal example: the audio tapes in Bioshock.)
  • When writing dialogue for characters, give each character a unique voice. By giving different accents and verbal mannerisms, it's an easy way to give them more personality, while also making it easier for the player to tell the NPCs apart.
  • Writing for MMOs is a huge challenge, above writing for most other kinds of games. Why? Because story is about change, and in MMOs there is not a great deal of change. Any game writing in MMOs has to work around this somehow.
Player-Centric Design

The actual name of this talk was "Getting the Human in the Game" and it was about never forgetting that you're designing your game for actual players, not robots. What followed was a blast of quick game design tidbits from designers Andrew Greenberg, Danny Miller, Michelle Menard, and Harrison Pink.

  • Many games follow the classic Hero's Journey quite well, until you get to the end, where the hero is supposed to return with the Prize and then share it with the rest of society to make a better world. This last bit is an important part of the classic story structure, and most games leave it out entirely. One major exception: MMO Raids, where a group of heroes follow this journey and return with epic loot that they can all share.
  • One other challenge to the classic Hero's Journey: most hero stories center around a single heroic figure, but in games we are moving towards a collaborative set of heroes rather than a single central hero (think Team Fortress 2 or Left 4 Dead). This is not unheard of in classic hero stories either (Jason and the Argonauts has an all-star cast of heroes, it's not just about Jason) but this is something that contemporary game writers should be aware of when crafting their stories.
  • Interesting potential for exploration in game design: there are six primal emotions (fear, disgust, joy, sadness, surprise, anger). Instead of saying "I'm going to create a game that causes a particular emotional response in the player," start the other way around: find existing game moments that produce your desired emotions, then extrapolate to figure out what mechanics can cause those emotions.
  • When trying to force an emotional response in the player (especially towards an NPC or other object in the game world), do not assume players will inherently know that, say, dogs are scary or that they should love butterflies or whatever. Show them through NPC dialogue or behavior modeling that this is how things are in your world. For example, if you want the player to find a certain flower beautiful, have an NPC remark on how pretty that flower is. (I think a great example of this is the Weighted Companion Cube in Portal, where players can become emotionally attached to a crate, simply because this psychotic disembodied voice tells them to.)
  • Numerical score is meaningless nowadays. You scored 10,500 points -- is that good or bad? How would you know? An alternative is low-dimensional scoring (say, a score of 1 to 10). There is a temptation to make scoring complicated for the purposes of game balance, and feel free to do this, but it is important to make the final score less granular so that the player can have some idea of how good they really did. Examples: ranks or letter grades; achievements and badges; or giving some kind of context ("your score is better than 80% of other players").
  • We think little kids are dumb, but they are actually smarter than we are much of the time. When designing for kids, we tend to lead by the hand to make sure they don't lose... but the end result is that they don't feel a sense of accomplishment. Alternative: create safe spaces for kids to fail.
Better Business Models

Jason Della Rocca gave a wonderful keynote entitled "10 things that don't suck about the industry." There were a number of points he made, but the most relevant takeaways I saw were from finding new business models beyond the current AAA publisher / third-party developer model.

  • Current typical business model: spend lots of money (in the millions), then stop development and release your game, then make money (hopefully more than you spent). This sucks -- you get no feedback during development, so the best you can do is cross your fingers and hope. Failures are expensive and cannot be undone, leading to the excessive risk-aversion that we all love to whine about.
  • Here's a better alternative, which we are already seeing with many social network games: spend a small amount of money, then do a "soft" beta launch and start making money much earlier. At this point you can then manage your income against your development expenses in realtime. Ideally, have several games in development at once, and you can shift dev resources from the worst-performing to best-performing games.
  • Even better: we are moving towards a better understanding of how to collect and make use of metrics in games. Combine that with fast releases, and we can use metrics to figure out what games are and aren't making money, and why. This can greatly reduce the risk of development, allowing developers to take greater creative risks while still reducing the cost of failure.