Escapist article

My debut as an Escapist columnist was just posted. It amazes me that I'm at a point where I can just send emails to some well-known game developers asking interview questions, and they actually respond. I'm still not sure how this happened.

For students, I'd also recommend reading the editor's note to this issue. It describes a little of the culture of game development, and is a reminder that this is not just an industry of gamers, but of human beings. Sometimes as a rabid game fan it is easy to lose sight of that.

One interesting thing I just realized is that you might or might not be able to ask the same question ("what games do you keep playing obsessively?") of teachers. Yes, many game development teachers are rabid gamers... but I've run into more than a few that have no personal interest in games. But I don't think I've ever met a game designer who didn't love games. It's strange, the differences between the two worlds.

Now, I just have to decide whether The Escapist counts as a peer-reviewed publication for purposes of my CV... probably not.

Culture Shock: the role of policy

In academia, there is less of a team spirit than there is in the game industry. Probably this is because there is less of a threat of, say, an entire department getting laid off because their collective product didn't sell enough units at retail. This difference has many manifestations.

One difference is in how closely people follow written policies.

In industry, while most workplaces do have some kind of Employee Manual with a list of policies, these are usually seen more as guidelines (except in the obvious cases where there would be legal repercussions if the policies are ignored). Getting an exception to, say, a sick leave policy is a matter of talking to your boss about it and having a good reason, especially if that reason ultimately benefits the team and the game.

In the academic world, policy seems a lot stricter. Asking for an exception is essentially asking your boss to go through some kind of appeals or justification process on your behalf. It is asking for more work, in a world where everyone already has quite enough work on their plate, thank you. So it is far more likely to meet a stone wall in this case. You are more likely to see bosses and administrators hiding behind official policy rather than explaining it or working around it, because following the rules is the path of least resistance, and there isn't much personal reward to putting in the extra effort.

For my peers in industry considering academia, this is one of those annoying things you can expect to run into. Ultimately, it means you have to choose your battles carefully, because you won't have enough time to fight over every silly little thing (at least, not if you expect to get all your work done).

Obviously, not all schools are this bureaucratic, and not all game companies are this relaxed. I'm talking general trends here, based on my experience. As usual.

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.

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

Soundbytes from Protospiel and SIGGRAPH

Protospiel is an annual gathering of non-digital game designers who come together to playtest their current works in progress. This is not a typical conference -- there are no sessions, lectures, or keynote speakers. It is all playtesting and analysis from start to end.

That said, I picked up a few things. In no particular order:

• Resource: http://www.eaieducation.com/ - a website where you can order colored stackables, plastic cubes, and other useful game prototyping bits for relatively cheap.
• Ever since the success of the Pandemic board game, a lot of people have been experimenting with pure cooperative games (I saw a number of co-op games at Protospiel, in addition to the ones coming out on the market already). One problem with the entire genre is when you have a situation with one expert player working with a group of novices. In this case, the expert dominates the game: they can either sit down and shut up and let everyone else flounder about (and now the expert is bored), or they can take charge and direct everything (and now everyone else is bored). They can offer hints while still letting everyone else retain their autonomy, but overall the game relies on the expert player to keep things fun (rather than the gameplay itself being inherently fun). This is a problem that arises from games that are purely cooperative and also offer complete information sharing between players. One possible solution is to build "information walls" between players so that a single player doesn't have the info to direct everyone else... but then this pushes players towards playing individually rather than as a coordinated team, and the whole point of being "cooperative" is lost. One interesting solution I'm seeing is to make the play real-time, so that the expert player just doesn't have the time to coordinate everything; this is how co-op video games work (one player can't simultaneously work four keyboards and mice), and there's no reason it can't work with board games... in theory.
• Games for girls: an important aspect here is the social dynamics between players. One designer did research on this by actually going to a mall, sitting on a bench outside a trendy store, and observing groups of shoppers. I thought this was a rather clever way to do research on a target audience, and could probably have applications with other audiences.
• Resource: A lot of designers have a game from Amigo called Rage. This is not because Rage is all that great a game. It is because it is a card game with seven suits, numbered 1 to 15 in each suit, along with several Joker-like suitless cards... meaning that you can use some subset of a Rage deck to prototype just about any card game you can imagine.
  

From a purely cultural standpoint, I noticed some interesting things about board game designers when they get in large enough groups for culture to emerge:

• You can tell which hotel rooms are populated by board game designers, because they all have the "do not disturb" sign hanging on the door at all times, even when they're not there. Why? Because they have learned through experience that hotel cleaning staff will often mistake their prototype game bits (torn pieces of paper, index cards and cardboard, etc.) for trash, and throw them away... or, almost as bad, to "helpfully" organize them so that you can't find anything. One game company employee reported that they no longer outsource the cleaning of their office, after one time when a janitor threw away a bag with prototype bits and a playtest notebook (this would be the non-digital equivalent of having your IT guy accidentally delete your entire code base on the server, along with all backups.)
• There are some differences in jargon between board game and video game designers. "Analysis paralysis" (where a player spends too long thinking about their turn, stalling the game) happens frequently enough in board games that it is simply referred to by its initials, as in "this game is really prone to AP, you should add a sand timer." In video games, AP means Associate Producer, which is a bit different.
• Meanwhile, a lot of board game designers have not been exposed to video game development at all. In a relatively large group discussion, someone was afraid of making too many differently-shaped custom pieces, and I suggested using "palette-swapping" -- that is, use a small number of shapes, and color them differently. No one had ever heard of the term before. This would not happen in a gathering of video game devs.

SIGGRAPH (I'm not sure why, but I always see people capitalize it like they're shouting it) is a conference on computer graphics, blending both the artistic and technical. At first I felt a bit out of place as a game designer (we don't normally work with graphics directly), but I found a lot of kindred spirits that are either teachers or game designers, and I wrote down a bunch of notes... again, in no particular order.

• Nowadays, some game design students are hired in large companies as Associate Producers and are given some basic production and design tasks to see what they can do. If they're really good at one or the other, they can transition into a role that fits their skills. If they suck at both, they can just get fired without too much pain.
• For educational games, align the learning goal with the core game activity / mechanics; use the peer network as a learning environment; make sure that increasing relevant skills outside of the game translates to better performance within the game. (In this case, "gaming the system" or using a "walkthrough" or "FAQ" -- normally considered cheating -- is actually a good thing... as long as doing so allows the student to meet learning outcomes.)
• There is natural tension between wanting to give the player complete agency, and wanting to give a controlled, focused (if "on rails") experience. Interesting compromise: use psychological principles (such as reciprocity, scarcity, appeal to authority, etc.) to manipulate the player towards the game's goals. The player maintains their sense of agency, while still doing what the designer wants them to.
• Consumer psychology research is useful when making persuasive games, since marketing to consumers is essentially persuasion.
• In cooperative games, think of communication as the core mechanic. If passing information to your fellow players has an in-game cost, that makes things interesting (and also solves the "expert player" problem identified earlier).
• I used to assume that a game with intentionally incomplete mechanics -- that is, games where the rules MUST be interpreted or invented by players and cannot be 100% standardized -- could not be faithfully represented as video games. After all, video games require programming code, and programs can only follow instructions, not make value judgments or rules interpretations. But I missed something. You can do this in a limited sense, by putting certain parts of the game under manual player control. As an example, there used to be a client called Apprentice that let you play Magic: the Gathering online with your friends. This program didn't implement any of the rules of the game at all; it just let you click and drag cards and tokens around a virtual game board, and displayed your cards to your opponent. It was up to the players themselves to actually play the game by the rules, without using the computer as a rules mediator. A similar thing could be done for other games, such as tabletop RPGs (or games where one of the rules is essentially "the players decide on a rule").
• Girl Scouts and Boy Scouts have offered "Merit Badges" as a reward system since, like, forever. It only took the video game industry about 35 years to figure out how compelling this was. What else can we learn from the systemic psychological indoctrination of kids, in terms of how to use that to make better games? :-)
• Resource: Future Pinball is a free-to-download pinball simulator that allows players to construct their own tables out of parts, with mostly click-and-drag functionality and minimal scripting (no hardcore programming). This offers some great opportunities for game design students. For one thing, very few 18-year-olds today are intimately familiar with Pinball, so it is a level playing field. Pinball table layout is highly constrained (by both space and availability of parts), preventing projects from having scope that grows out of control. Pinball table design uses the same skills as any other level design. By tying a "create a pinball table" assignment to an intellectual property (such as a recent popular movie or TV show), students can be challenged to take an existing narrative and translate it across media... a good skill to have, and a challenging one in the case of Pinball where the player actions are highly non-linear and unscripted (and unlike video games, it's hard to put the player "on rails" in Pinball).
• One difficulty with making games with sexual content is that sex is extremely personal and different for everyone. Interestingly, I think the same is true of spirituality; if someone discovers how to make a compelling game that can bring a player closer to God, the same techniques could probably be used to make a serious game about sex. Is that ironic?
• Will Wright was quoted as not liking the term "non-digital" to describe board games and card games and the like. He prefers "matter-based" games. I am amused.
• As a teacher, convincing students to attend local industry functions (such as IGDA meetings) can be a challenge. Some students do not see the value, and approach this as "more gross-icky-disgusting-learning outside of school, and not even for a grade, so why spend my free time with that". Others see the value but are intimidated, and don't want to do anything embarrassing in front of the very people who may want to hire them later, so they just don't show out of fear. Professors may want to think of ways to work around this. Or, we could take the approach that the students that don't show are the ones that wouldn't make it in industry anyway, so it provides a useful selection/filtering process.
• When analyzing games as an art form, where is the art? It can be found in many places: the visuals (obviously)... although there may be a distinction between "game art" and "art-games"; the game mechanics to the extent that they lead to play that expresses meaning; player activity which can be artistic, but raises the problem (expressed by Roger Ebert) of authorship -- if art requires an artist, is the artist the game designer or the player? ; the game environments, as an analogy to designing the stage as opposed to writing a play; the game code itself, to the extend that it enables everything else, and also that it can push the boundaries of the technology (consider the parallel between coding on a very constrained platform like Atari 2600, versus writing a constrained poem like a Haiku).
• Currently, a lot of traditional museums are confused with how to frame interactive exhibits. Actually letting visitors touch the art is new to them and makes many of them nervous. As more artists are creating interactive works, and as more museum curators are considering ways to make the entire museum-going experience more interactive (even "game-like"), this problem is being attacked from both ends and will probably become a non-issue within our lifetimes.
• Aristotle's three-Act structure doesn't translate well to games, because Acts 1 and 3 essentially map to non-interactive cut-scenes. Almost the entire game is Act 2. (However, if you use the three-Act structure on a micro level to design quests, NPC plot arcs, individual levels, and so on, it can lead to a more robust larger story.)
• Game writing tips: don't write about what the main character does, but what they will experience (remember, the player is in control of what the main character does). Think of game fiction as told through objectives and rewards. Don't tell the story through the main character; instead, write the story through the NPCs and their own points of view.
  
• Use the game space to create memorable moments.
  

Twitter as Education Platform

Yesterday afternoon, something magical happened. A game design discussion spontaneously broke out on Twitter. The original topic of discussion was the role of narrative in games, but eventually it extended to several other topics. Some really top-tier designers were taking part in the discussions, including David Jaffe, Clint Hocking, Damion Schubert, John Romero, Harvey Smith, Brenda Brathwaite, and about a dozen others whose names you should know if you are at all interested in this industry.

The main conversation continued until past midnight. Pearls of game design brilliance dropped constantly, each in 140 characters or less. It was amazing to see. As of right now, there is still some discussion happening. There was talk of formalizing this and turning it into a regular thing, but I think the fact that it just randomly happened is part of what made it special.

Search for the tag #gamedesign on Twitter to see the whole thing, unreadable though it may be in linear format.

Why is this relevant to teaching game design? Because most practicing designers do not have the time to write a textbook, yet we teach from textbooks. Some designers have blogs, but the best we can do is reference specific entries from the past, and even then it is usually a single designer's opinion (if we're lucky, a few other designers will have a discussion in the comments on the blog). There are GDC roundtables, which are usually not audio or video recorded. There are closed-to-the-public email discussion groups, which do filter out slowly but cannot be followed in real time. But this Twitter thing -- it happened in a very public place, and just kind of emerged as an ongoing conversation. That is how developers spread information, by talking to one another and letting their experience and wisdom spread virally among the community.

I don't know if we'll see this happen again, but those rare times when it does are worth reading.

Report from Game Education Summit

I'm just catching up from the excellent Game Education Summit earlier this week. Here are my notes:

Donald Marinelli, keynote:

• Much of today's educational system is obsolete. Summer vacation exists to let young people go home and help their families with farm chores. How many K-12 students do you know that are planting wheat right now?
• If you are building a game for a class, build it for someone. Give it a purpose.
• ETC's "secret sauce" is that they let students teach each other.

Terrence Masson, on building Northeastern University's curriculum:

• Interesting way to structure a Capstone course with 10 people: first day people give their project pitches (most students pitch several alternative projects). Second day, students narrow the pitch list down to the two projects that the class will work on; students choose their teams (split into two teams of 5); each team assigns roles and chooses their project lead. Essentially, the students drive everything.
• Another interesting thing about this program is the requirement of two non-adjacent semesters in internships/co-ops. The benefit is that students keep the faculty honest: "What do you mean we don't have Zbrush on campus? That's what everyone is using now!"
• Note to prospective students: at this particular institution, the program is called "game design" but it is actually "game development". This points to the importance of schools and industry using a unified set of terminology.

Jessica Hammer, on how to teach creativity:

• First, you have to define what "creativity" is, because it is an overloaded term, and there are different kinds of creativity. She defined it as "appropriate novelty" -- something that is new, but within a given context/domain. (If you ask students to design a game and they write an essay instead, and try to define an essay as an innovative new type of linear-narrative game, this is not what we are looking for.)
• Creativity happens within a context or domain (i.e. within a set of constraints). There is a virtuous cycle within a field, where the domain influences individuals; the individuals produce creative work within the domain; and the gatekeepers who see this work then influence and redefine the boundaries of the domain to compensate. In the case of teachers, the classroom is the domain.
• One problem in practice is that we often measure creativity after the fact: we look at the final product and decide if it is creative. Unfortunately, this tells us nothing about the process used to create it... and if we want to teach creativity, we want to teach the process!
  There are three aspects to the creative process that students need to understand: the generation of novel ideas, the ability to decide what ideas to pursue (since ideas are a dime a dozen, once you learn how to generate them), and the motivation to follow through on your chosen idea and do the work to turn it into a final product. The class should focus on these.

Jessica's hints for course design:

• Begin with outcomes. "The goal of a course is not to deliver content, but to transform your students."
• Consider the length and pacing of the class. If there is not enough time to generate ideas, fail many times, and still finish, students will take fewer creative risks.
• "Personal attention is valuable currency." Keep class sizes small when possible. Group work can enable larger class sizes by having you deal with a small number of groups rather than a large number of individuals.
• Recruitment is rarely thought about, but is important. The more diverse your class (or, um, game studio), the more creative the ideas you're likely to see. When approached by a female and/or minority student, be supportive and ask if they have friends who would also be interested in taking your class. Also, consider the accessibility of your classes: if students can choose between written or verbal assignments, you will see higher enrollment among those for whom English is a second language.
• Use a lot of class time on playtesting and peer review. Professor should model appropriate feedback, to show what it looks like.
• Encourage uncertainty, in projects, classes and life. "Your game design education does not end when you leave this class. It has just started."
• Don't just have students solve problems that are handed to them, because this is not how real life works. Have them create and seek out their own problems to solve.
• There is a negative relationship between the time and emotional investment in a project, and willingness to take risks. In the middle of larger projects, consider giving smaller-scale "lightning round" design challenges that encourage creative risk-taking -- for example, email students with constraints of a challenge at noon one day, and they have 24 hours to post a short concept in an online discussion group. These are not a major component of the course grade; they are a chance for students to show off. Examples: "Design a game to be played in the waiting room of an ICU while you're waiting to see if a loved one lives or dies." / "Design a game for NASA that can keep astronauts alert and interested on a 3-year mission to Mars." / "Design a game for Obama's cabinet to help improve their effectiveness as a team."
• How do you assess creativity? Note that you get what you measure; students will game any system. If you want to reward risk, you have to give grading opportunities for it. Jessica splits the final project grade into three equal parts: the game itself (the final result of the process), the theory (students write a companion paper that shows the connections between the theory learned in class and its expression in their game), and the process (students submit a "process paper" that includes everything that was part of the project but not visible in the final form: raw data, early playtest results, early versions of the game, mechanics that were tried and abandoned... whatever the student wants the instructor to see).
• Divide larger projects into many feedback cycles / milestones. Iteration is part of the creative process, and class projects should reflect that.
• The nature of instructor feedback is important. If you just give a grade, that carries very little information. Extensive written feedback is much better, but can take a lot of time; to manage this, favor group projects or smaller numbers of submitted projects per-person.
• As the instructor, you are a strong influence on the culture of the classroom. You want students to feel comfortable taking risks, both in their projects and by raising their hand to make suggestions/comments in class. How you react when students say something "stupid" has a huge impact. Suggestion: draw from the "Yes, and..." technique of improvisational theater -- accept everything in class, refuse to shut down an idea or say that it's wrong, and instead challenge yourself to find the nugget of truth in there.
• Give students a sense of mission. People are more creative under stress when they believe in the importance of the final project. Because of this, fewer projects (reduction of workload) can paradoxically lead to students spending more time and doing more work... as long as the projects they have are the right ones.
• Self-efficacy is important: students must believe they can perform well in the class. Corollary: we as teachers must believe in our students. Research has shown that a teacher's belief in a student's ability to perform is often self-fulfilling.
• Praise students not only for their projects, but also for exhibiting personal qualities that we want them to continue: hard work, persistence, etc.

Walter Rotenberry (Wake Tech), on the challenges faced by Community Colleges:

• The ideal case for a Community College is that you are based in a "hub" of the game industry, so that your graduates have immediate local employment and internship opportunities. What if there are no game companies in a 100-mile radius?
• An alternative: focus on entrepreneurship. Require your students to take classes in business, enough that they would be comfortable building their own startups. Give students the tools to start their own local studios.
• Wake Tech's approach to a two-year program is interesting: cover a little bit of everything (at least one or two courses from programming, design, art, production, audio, business, game studies, etc.) to give a well-rounded background. This provides a foundation for transfer to any four-year school. I thought this was an interesting approach -- in my experience, usually with only two years to work with, Community Colleges focus on art or programming. I'm not sure that one approach is "better" than the other, but I can see the use of both.
• Encourage students to take courses in other relevant areas and departments: theater/drama, history, storytelling, etc. - the bonus is that in many cases there is no need to add specialized "game" classes, you can work with what is already there.
• Wake Tech got an $800K grant from NSF to develop their curriculum. This money is not allowed to go to new hires, but can be spent on curriculum development and new equipment. Other schools may be able to get similar money, so it is worth looking into.

G. Michael Youngblood on Computer Science-focused game research:

• Students can get involved through an NSF program called REU (Research Experience for Undergrads).
• It's easy to get academics involved; this is what many of us do. Biggest challenge is collaboration across departments, since games are so interdisciplinary.
• If you're working in industry and want to get involved, the easiest way is to visit. Invite some local researchers to lunch. Look at their stuff, read their papers, ask questions on what you don't understand.
• You can support students for your own benefit! If you have an idea you'd like to test out, $1100 per month for a grad stipend x 5 months = $5500 for a prototype and white paper. This is a pretty good deal if you're a large studio with an R&D budget! Note that some schools and some researchers will ask to charge overhead (to cover costs of building maintenance, utilities, etc.) that is as much as 50% of your grant. You do not have to put up with this; operations costs are not required for non-governmental grants, and you can offer the funding on a take-it-or-leave-it basis. Most universities would rather accept money than turn it down.
• Be on a university's Industry Advisory Board. Suggest that they research difficult, interesting problems.

Michael's list of things that the industry should keep in mind when dealing with academic researchers (particularly in Computer Science):

• Academics are extremely "paper-focused". If there's not a publication in it, then it doesn't matter.
• Academics are always behind and have too much to do.
• Like any programmer, academic researchers will overstate their ability to deliver for nearly everything.
• If a study involves humans in any way (such as, say, using college students in a playtest of your game), learn about the IRB process.
• The field of games research has matured quickly. Two years ago, "I'm working on a game" was good enough to get published. Today, you must also be able to show why your game research is cool or useful in some way.

Random tidbits from side conversations:

• Games and learning are both negative feedback loops: once you have learned something, you don't want to learn it again. This drives students to learn something and then stop. We need to find a way to counteract this by including a positive feedback loop, so that great students will want to keep learning and to learn more.
• I wonder if a school has ever hired an entire small development studio. Granted, not everyone has teaching skills, but you would get complete coverage of all subject areas and you'd be hiring people who already know how to work together as a team.
• Giving students a general literacy of classic games is important. One approach: have students write "reviews" of classic games. How do you get them to play older arcade or console games in the first place, when the original hardware is hard to come by? Several alternatives: first, many companies are repackaging their classic games for sale on modern systems (Atari Flashback, Midway Classic Hits, original NES games downloadable on Wii, etc.); second, with questionable legality, you can download emulators such as MAME; and third, particularly useful in class, you can find short gameplay videos of just about everything on YouTube to show what some of these games looked and played like.

Topic for Discussion: Beating a Course

Recently, someone wrote me about my book, claiming they had finished all of the challenges. I'm not sure if the person was serious (there are over 300 of them, after all), but it got me thinking about books and games, and the difference at the end of each.

It struck me that when most students finish a class, there is a sense of relief. "Finally, it's over. Now I can sell my textbook, throw away my notes, and forget all the stuff I just spend three months cramming into my brain." We approach games very differently. Maybe you just beat God of War 2 or Bioshock or Fallout 3 or whatever, and there is a sense of closure there... but there are also a bunch of locked Achievements, secret levels, more intense difficulty modes, different character classes or progressions, all kinds of other things that give the player incentive to keep going after it is "over".

What would classes be like if they had this kind of incentive system? Where students voluntarily chose to go back and read the chapters that weren't covered during the main course (the way they would explore optional levels after completing the main storyline of a game), do all of the end-of-chapter exercises that weren't assigned (like optional sidequests), write their own material summary to help other students (like writing a FAQ or Walkthrough of a game), or discuss the class and some of their ideas about the material with their friends?

"I just beat the final boss in Vector Calculus yesterday. But I was thinking of going back and collecting all the secret bonuses in each chapter, building up my Trig skill, and maybe going through the book again on Hard Mode and unlocking the bonus chapters on Differential Equations at the end. And I'm totally pre-ordering the sequel class, I hear they're releasing it in the Fall." It sounds ridiculous, but really, why not?

Student Post-Mortems

In a class I taught that just finished, I had the students make a complete, full-featured, production-quality board game from scratch over the course of a month (this was the major project in the middle of the course). At the end, I asked everyone to do a personal "post-mortem" by listing the things that they felt went right and wrong in development.

The list of things I see are astonishingly similar to the professional post-mortems that you see on Gamasutra when people make video games, and I feel echoes of previous classes I've taught where students made video games. So, I think a lot of these lessons are generally applicable, and worth sharing.

Rather than breaking it down into things that went "right" or "wrong" in this particular class, I'll list these as general points of advice that were repeated themes throughout the class. Some students listed these as things they did well and were thankful for; other students listed the same things as weaknesses that they wished they had paid more attention to. For our purposes it doesn't matter; this is the advice that my class would give you and your students.

• Playtest your game regularly, several times a week. Start as early as you possibly can. The earlier you start, the more time you have to make radical adjustments. You can never playtest too early or too much.
• Playtest with a variety of people, not just the same group of friends. Test with family, classmates, complete strangers, anyone you can think of. New playtesters offer new insights. The wider variety of testers you have, the broader the appeal of your final game.
• Start with a simple, strong core concept. If you don't know the purpose of your game or where the fun is supposed to come from, you'll have a hard time getting there. On the other hand, if you have some basic gameplay constraints that you create for yourself, a lot of gameplay will come naturally from that and it will feel like the game is making itself.
• Be wary of oversimplification. In general, it is harder to simplify a game than to make it more complex, and you should strive to make your game as simple as possible. There is a flip side to this: if you are overzealous about streamlining the rules, it is possible to accidentally remove player interaction, interesting decisions, and strategic options. When you remove rules from your game to simplify, pay attention to the play to make sure you are not removing a critical element.
• Observe people playing your game, without interfering. The learning curve of a game is critical, and the only way to gauge this is to have new players sit down and try to play without your assistance. Watch them struggle and see where they fail. This is one of the only ways to identify critical holes in your game in the end stages; as the designer, you are too close to your own creation to see the obvious flaws yourself.
• Don't neglect theme. In an effort to build the best gameplay possible, don't forget that a strong theme that fits the mechanics can make the game easier to learn, and a fun theme can generate player interest from the start. Include something that players can personally identify with in the game, to make it easier for them to feel like they're "in the game."
• Some mechanics are higher risk than others. If you are doing something that has never been done before (or has only been done rarely), the final project will take a bit more time, and you should be prepared for that. There is probably a reason why it hasn't been done before, and the reason is probably that it is hard to get it to work! If you are heading into uncharted design territory, expect to spend at least double the time on the project that you would have otherwise.
• Pay attention to readability. Some color combinations make your game difficult to read (I've seen black text on a dark blue background which was nearly impossible to read, and also yellow text on a violet background which was just painful to look at). If you haven't studied color theory, at least look at all of the text and icons in your game and make sure you and your playtesters can read them without eye strain. Test in both bright light (e.g. outside in the sun) and low light conditions.
• Leave time for "polish" at the end. When you have a month or two to make a game, it feels like you have forever. Realize that you would ideally like to have everything "done" earlier than the final deadline, so that you have plenty of time to make the game look more professional. Little details matter in the final presentation, but you will only have time for them if you don't procrastinate and if you build this expectation into your schedule. (Even then, it is often hard to do.)

There were also a couple of hints that are specific to board games:

• If you are making any custom components, do "proofs" before paying to print the whole thing. For example, if you're printing many sheets of cards, print a single sheet to make sure everything lines up right and that the colors don't bleed.
• Avoid printing double-sided if you can, because it's hard to get everything lined up. If you must, add a thick border which will help mask any cutting errors.
• Allot plenty of time for creating final game components. Even if your rules are finalized and you know exactly what you need, the process of actually building everything (which might involve painting wooden pieces, printing at a local copy shop, cutting pieces, and any number of other things) takes a lot longer than you think it will, so don't leave it for the last minute.

Design versus Marketing

Students who are hardcore gamers (i.e. most of them, if you're teaching game design) are used to seeing the marketing-speak on the back of a game box (we call this "box copy"). You've seen it before: "Over 30 levels! 300 weapons! Epic, engaging storyline! Intuitive combat system!"

Most of these students have never seen an actual game design document before. This would be the document that actually describes the details. Exactly what are the contents of each level? What are the names, damage, speed, accuracy and other effects of each weapon? What happens in the story, when exactly is each bit of story revealed to the player, how much is text and how much is voice acting, what is every last line of dialogue? How, exactly, does the combat system work and what are the controls? And so on.

It is, apparently, easy to get these mixed up. Box copy is useless if you're giving it to a programmer to implement. How does a programmer write code for "intuitive combat system" exactly? The answer is that they don't -- they kick it back to the designer until they get the details.

I'm seeing this more and more with students lately, and I'll be taking additional steps in the future to warn them of the difference between design and marketing. I wonder if other teachers see this as frequently as I am... and what, if anything, they do about it.

Academic Program as MMO

On the IGDA Education list, fellow industry-vet-turned-educator Kevin O'Gorman made a great comment that I wish I'd thought of first:

There's the curriculum you roll the program out with (fingers crossed the people that pulled it together were at least aware of the Ed SIG Curriculum Framework) and then the tinkering and fine tuning that goes on from that point on. It's like an MMO -- the launch is the beginning, not the end of the process.

How far can we take this analogy? Pretty far, actually...

• Both academic programs and MMOs need hefty amounts of resources to initially develop, before either one of them sees a single paid player/student.
• Both are based on a similar pay model: pay-per-month or pay-per-semester, regardless of how many classes you take or how often you're logged in.
• Multiple sections of a course are the academic equivalent of instanced dungeons.
• Character classes are the MMO equivalent of an academic major.
• Look at a skill/tech tree for a class in a typical MMO. Looks suspiciously like a list of classes and prereqs, doesn't it? (Hint to game schools: try adding a "tech tree" diagram to your course catalog and see if it doesn't remove half the pain from your academic advising.)
• In theory, an MMO wants its players to stick around forever; in practice, it's recognized that there is regular churn (you could call this the game equivalent of "graduation"), and so the developer/school must be concerned with attracting new customers/students as well as retaining existing ones.

The analogy does break down eventually. I don't think I've ever sent my students on a "fedex quest" in exchange for grades, nor can my students buy better equipment in my classes in exchange for cash. Students could theoretically sell their work to others at an online "auction house" but it's against the TOS/EULA of a class to turn in work that isn't yours (unlike many MMOs). You can buy "pre-leveled" characters but not a "pre-completed" degree.

Still, perhaps schools could be improved in some aspects if administrators took some cues from WoW.

Career Advice for Teachers and Designers: Do, Don't Show, Don't Tell

There is something that has taken me many years to learn, after observing a number of other game designers and the systems that affect their careers. It boils down to something like this:


If you have to tell everyone how great you are, then you're not.



The best designers do not have to "self-promote" within the industry, because they have worked with other people who respect them enough to be their willing evangelists. As soon as you spend too much effort trying to build yourself up, that is precisely when the rest of the industry will gleefully tear you down. If you feel unappreciated, like you're just not getting a fair shake and you're not getting the attention and appreciation you deserve, it is because there are so many talented people out there competing for that same attention. Best move is to be patient and not overreach; yes, you will feel underappreciated for awhile, but in time your good work will come back to you.


If, by contrast, you spend a lot of time and effort convincing people that you're God's gift to game design, the worst possible outcome is that you succeed in your efforts. And then you're given a project that is beyond what you can handle. But you won't realize it, and you'll take the entire project down with you, and your co-workers will not thank you for their pink slips when the studio closes.

The same rule applies to teachers, but in a different way.

There is a temptation as a teacher to drum up attention for your classes. You want students to know that you're teaching all these cool classes about video games. You want enough students taking your classes that it proves to the higher-ups that there is demand and that they need to throw more resources at your program. You (and probably your boss and boss's boss) want "butts in the seats" under the assumption that if only enough people take these classes, they'll see how awesome they are and spread the word.

This leads to a similar problem as with the industry. If you promote your classes, you will get some students who either feel compelled to take them by your high-pressure tactics, or you will get students who are largely unmotivated and assume that "game class" equals an easy A. Neither of these students really wants to be in your class, nor will they try particularly hard.

In the long term, I'm thinking that the best way to promote your classes is to spend all your time making your classes a great experience. If the classes are that awesome, your students will evangelize for you, and they'll do it better than you can. Your initial class population might be lower, but it will also be more motivated and energetic because those students had to do some work just to take the class -- they had to find out that it was there, and they had to read the course description and probably talk to their advisor to see if this was for real, and they had to sign up on a leap of faith without encouragement from you. These are the students you want in your class.

In both industry and academia, this is the advice I would give:

Spend your time doing great things. Don't spend as much time showing or telling about your work. Let others discover it for themselves.

Back to basics...

A student is admiring my Ra board.
"Is that signed by Reiner Knizia?" he asks. It is. He even pronounces the name correctly.

I mention that at home, I also have a chessboard signed by Garry Kasparov.
The student asks, "who's that?"

Sigh.

Just when I think I've got this education thing down, I find out that there's more work to do.

Types of Student/Beginner Design Projects

There are many kinds of project that help someone to learn design. Some are more or less appropriate in the different stages of a student's educational experience.

Non-digital games (i.e. Eurogames). Design a complete non-digital game (such as a board game, card game, or tile-laying game) from scratch.

Advantages of Eurogames:

• These kinds of games represent game design in its purest form. The design is laid bare, and cannot be concealed by high-poly-count art or impressive technology.
• These games can be built very quickly and cheaply. To make a "first playable" version takes only a few minutes, typically using only simple components like index cards and notebook paper.
• They tend to play quickly, which gives a lot of opportunity for playtesting, iteration, and polish if extended to a longer project (1 or 2 month time frame).

Disadvantages of Eurogames:

• Does not often meet student expectations. Students starting out in a video game development curriculum may be confused or frustrated that they are not working on video games. Extra care must be taken to justify the concept.
• In America, board games have a poor reputation from our culturally-accepted "family game" fare of Monopoly, Chutes & Ladders, the Game of Life, and other children's games. Initial exposure to Settlers of Catan, Carcassonne, Puerto Rico, Bohnanza, and the like requires a massive paradigm shift on the part of most people.
• Because students have little experience with board games, many "original" ideas are actually things that have been done before, but the student is not aware. In my classes there's always at least one student who sponteneously and unintentionally re-invents some classic game that they've never heard of. These projects require a lot of guidance and game-literacy on the part of the teacher.
• Some aspects of Eurogame design do not directly apply to video games. For example, it's hard to simulate the satisfying feel of pressing a button to make Mario jump in a board game.

Recommended for:

• A student's first experience to the world of game design.

Tabletop RPGs. Design the system for an RPG, playable by one mediator ("GM") and a small group of players. I would also include LARPs and, to a lesser extent, ARGs in this category.

Advantages of RPGs:

• Most students are at least familiar with Dungeons & Dragons, so prior experience is not a problem. A fair number are enthusiasts of the form, so this will generate a fair amount of excitement.
• Most RPGs require a strong integration between gameplay and story, making them ideal for the study of both game-based storytelling and core systems design.
• As with Eurogames, the system is laid bare in the rules, making RPGs a very pure form of design (even moreso than Eurogames, as most RPGs only have a handbook and not even any board or game bits).

Disadvantages of RPGs:

• RPGs are a very specialized form of design that may not immediately carry over into some other game media or genres.
• The enjoyment of an RPG relies largely on having a good GM and a good set of players. Good play can salvage bad design (and poor play can wreck a great design), making it difficult to evaluate a game purely on its own merits.
• RPGs take a long time to play. Typical play sessions last several hours, played regularly over the course of months or years. This greatly slows the number of playtests and iterations allowed in the space of a single course.
• Take a look at a professionally-printed RPG rulebook some time. Many are in the hundreds of pages, and are too large in scope for a student project. Even if you remove a lot of the fluff and filler, something as "small" as a 15-page rule set will still seem large to a typical undergrad student.
• Since RPGs integrate story and gameplay, it's important to have a solid understanding of both before taking on this kind of project. Learning how to tell good stories is hard. Learning how to design a solid and balanced rule set is also hard. Doing both together at the same time is too hard.

Recommended for:

• A mid-level elective course, with an intro game design course and an intro storytelling course as prerequisites.

Video games. Of course, when most students are thinking of "making games" they are thinking of video games. Generally, at the student level, I would subdivide this into two types of video game projects: very small and short individual projects, and mid-sized group projects. Most students would prefer to make large AAA video games, the kind that take several years with a team of hundreds of professionals, but of course the scope is too large for a college course.

Advantages of individual video games:

• Students really get to take ownership of their project, and it is usually very exciting for them to be making their own original video game.
• A truly outstanding student project has the possibility of winning an IGF award, which is a big deal.
• This is the most practical form of experience for students who want to make video games as a career.

Disadvantages of individual video games:

• Most individuals do not have art, sound, programming, and game design expertise, so some students will be disappointed and frustrated at their inability to do certain things in their project.
• Scope control is a problem with inexperienced students, who tend to design more than they can reasonably implement in a length of time. It requires a sharp eye and quick response from the professor to get students to keep their projects manageable.
• Because it is not going to be a AAA game, some students will take a small project less seriously than they should.
• At the very least, an individual game requires both programming and game design skill (art and sound can be fudged more easily). Learning programming is hard. Learning game design is also hard. Trying to learn both at the same time is too hard, and is the reason why so many people fail when they start out trying to program their own game from scratch as their first hobby project.

Recommended for:

• High-level class with a lot of prerequisites. Concentrates on showing students how to assemble all these various component parts in order to make a complete video game.
• High-level class with several game design and programming prerequisites. Concentrates on rapid prototyping, and making games that are ugly but functional as a way to test out certain mechanics or ideas. (A lot of prototyping can be done on paper, but some things like User Interface are best done digitally.)
• Intermediate programming class, with a game design class as prerequisite. Students learn programming while applying what they already know about game design.
• Introductory programming class, where the game design is done by the professor ahead of time and students can concentrate solely on implementation.

Advantages of group video games:

• Most directly simulates the interdisciplinary team environment found in the industry.
• Students can specialize; each individual does not have to be good at everything, as long as they are very good with at least one thing.
• Allows for larger scope than individual projects (although still not as large as AAA games).
• Like individual projects, an outstanding group project is potentially IGF material.

Disadvantages of group video games:

• Most students do not have a lot of experience working in teams. Lots of things can go wrong: an individual unmotivated student that drags down the team, communication lapses between students that make integration difficult, the design team overscoping the project, personal conflicts between team members, and all of the other general chaos that happens when people try to work together.
• Since this requires students from several disciplines, you usually have to recruit from multiple departments. Setting up a cross-listed class and getting the go-ahead from outside your home department is a bureaucratic nightmare. Getting a good mix of students with varied abilities is likewise difficult.
• Students will tend to bite off more than they can chew, especially once they realize that they have so many people working on a project. Getting them to start small and add (rather than starting big and cutting) is always a challenge.

Recommended for:

• A senior-level "capstone" course, after students have already taken all of the core courses in their respective majors.

Culture Shock: Academic Freedom vs. Industry Constraints

When reading about Brenda Brathwaite's series of non-digital games (this includes games about such heavy topics as the Middle Passage, the Trail of Tears, and the Holocaust), it struck me that this kind of project would never happen in the game industry.

I don't mean that it would never get publisher funding. I mean, it wouldn't, but that's not my point. My point is, even if it were on her own time with her own money outside of work, this would never be allowed to happen.

Think about it. Suppose you were a working game developer and you casually mentioned to some co-workers that you were thinking of making an art piece and showing it at galleries, and that the topic was highly controversial and this was sure to have a lot of people cheering, and a lot of other people up in arms. How many nanoseconds would it take before your producer found you at your desk and asked you very nicely not to do this, out of fear that the Company would receive negative media backlash, and this is the last thing we need when we're courting three publishers for our next contract, so if you're interested on working on non-digital games maybe you could make something about fluffy bunnies instead? (I suppose some companies make controversy part of their business plan, but I'm talking about everyone else.)

This is a completely different paradigm than academia, where the whole concept of tenure is (at least in theory) supposed to be about the freedom to do anything, no matter how controversial. As an academic, you actually get support for things like this. You can sometimes get funding for things like this. Not everywhere, I'm sure, but it seems more likely that a random school will at least not get in your way if you want to take on a controversial product, compared to a random game company. One more point to consider if you're considering a career in either and you prefer to have total creative freedom.

Back on regular posting schedule

I've been out of commission for a while, due to GDC and then GDX. I'm just about caught up.

For what it's worth, there are video recordings of some great GDX sessions online. Mine isn't on there (maybe I used too many swear words?), but the ones posted are excellent. Highly recommend Jason Arnone's and Jon Jones's talks for any aspiring visual artists, Mark Nelson's talk for anyone interested in open-world games, and Andrew Baines for any aspiring FPS level designers out there. Jason Rohrer's talk was more conceptual than practical (as keynotes tend to be) and focuses on why games don't have the cultural legitimacy of other established media -- something that anyone in game studies would do well to consider.

And if you're ever down in the Savannah area during GDX in the future, I'd highly recommend attending. Great speakers, small and intimate/casual atmosphere, lots of great talks and great people all around.

Game Design Concepts: an Experiment

For those of you who I met at GDC and found their way here, welcome!

One thing I talked to a lot of people about is an experiment I'm doing this Summer, called "Game Design Concepts."

This is a free online class that I'm going to teach. It is not affiliated with any college or university, and not for credit. It will be taught through a combination of blog, email and wiki. It contains all of the information (and then some) in one of the game design classes that I normally teach in a classroom in exchange for tuition money. But I'm releasing it for free this Summer.

The subject of the course is, as you might expect, game design. The intended audience is:

• Students who are interested in game design, and either are at a school that doesn't teach it well or doesn't teach it at all (or maybe you just want a second opinion).


• Teachers, especially those who teach game design. You can compare my material with that of your own class. Maybe you'll find some useful resources that you didn't know about, and maybe you'll be able to offer me some hints in return.


• Game developers who aren't designers. In a lot of companies, game design is still considered something of a "dark art" and those who aren't designers are often curious about how game design is done. In a few hours a week, this whole other field can (hopefully) be demystified.


• Game designers. Do you have an interest in contributing to education? Do you want to know what it is that the next generation of designers -- the ones who are likely to report to you in 4 to 6 years -- are being taught in the classroom? This is a way to find out, and contribute your own experience in the process.


• Anyone else with an interest in learning more about game design. For example, parents or grandparents of game designers who are curious about what these kids are doing; or hardcore gamers who want greater insight into the design decisions that make their favorite games so great.

If I've got your attention and interest, the blog is at gamedesignconcepts.wordpress.com and all updates (including instructions to register) will be posted there.

Gearing up for GDC

It's that time of year again. I can't believe it starts in less than a week.

If you're going to GDC this year for the first time, here's a link to my advice for what to bring with you. And here's another link to Darius's store of GDC advice. Be prepared!

If anyone wants to meet up, there are three easy places to find me. First, I'm speaking at the Game Education Summit on Monday. Second, I'll definitely be at the blogger group gathering on Thursday. Third, it's tradition by now that I'll be up early for breakfast on 3rd floor of Moscone West each morning, at the tables right near where the escalators dump you out. Look for the guy who has board and card games.

Culture Shock: Learning Disabilities

Autism. Aspberger. OCD. ADD. ADHD. Tourette's. Bipolar. You name it, someone in the game industry has it. Probably several someones, and probably at least one someone who is incredibly successful.

For this reason, it's hard for me to even call these "disabilities" -- given that the word "disabled" literally means that the person is not able to do something, and clearly it is possible to make games regardless of what psychological label might be applied to someone. But then, I'm not a psychologist.

For the most part, people in the game industry don't care if you've been diagnosed with anything, as long as you can help them make great games. You could be criminally psychotic for all we care, as long as it doesn't impact the development schedule. (Okay, I exaggerate. But only slightly.)

So, it took me by surprise the first time a student gave me this little slip of paper from the campus office of disabilities, several years ago (I've since gotten used to this ritual; it seems there's always at least one per class, and usually more).

For those of you who have not taught before, here's how it works: the student brings you this paper that gives you (as the teacher) no practical information, except to tell you that the student requires some special privilege (commonly, extra time and privacy when taking exams). You have to sign it -- in all the places I've taught, I've never been allowed to keep a copy -- and then the student takes it back. Presumably it gets filed somewhere, I don't know.

And then, naturally, you forget about it, because you're not allowed to keep a copy. Until exam time comes, and you remember that two of your students have special requirements, but you can't remember which students (many students with so-called "disabilities" are quite high-functioning), and one of them might have dropped your class a few weeks back anyway. Oops. I've been doing this for a few years and I still manage to screw this up most of the time.

The most frustrating thing, though, is that you're given no information about how to teach more effectively. I understand and accept that we're dealing with confidential information on a need-to-know basis, and I will often be getting the bare minimum of relevant information. But this conflicts with a desire to teach properly, and if I know that (for example) talking more slowly or repeating myself will help or hurt the situation, or if making my lecture notes available is useful, or if I should avoid calling on a student in class because it would embarass them... well, it'd be good to know, but there's no way for me to find out without a confidentiality breach.

The obvious thing to do in these situations is to talk to the student directly, and simply ask if there's anything you can do... but often the student doesn't know, because they aren't a professional educator.

Best solution, I suppose, is to take matters into my own hands. Read books on as many of these disabilities as I can find, particularly any that might give clues on how to teach better, and hope for the best.

Last-Minute Begging

I see this happen from all kinds of people.

Students: "I know I haven't turned in half of the assignments and I haven't been in class for the last month and this is the last week of the term, but I'm failing the class and is there any way I can do something for extra credit?"

Professors: "I know grades for this term were due a few weeks ago, but I've been so busy with other things that I never got around to sending them in. I hope that didn't inconvenience you by preventing your graduation, or making it impossible for you to get a final transcript for that job you're applying to. I'll get it in this week, I promise!"

Professionals: "I know you asked me how I was doing on my task list every week for the entire project and I've said fine, but I realize now I'm three weeks behind and we've got a milestone due tomorrow. Can I get some help?"

For some reason, some people have a really hard time saying that they're behind until it's too late to do anything about it. And yes, I've been guilty of this in the past, which makes me quick to spot it in others.

Now if only I can find a way to convince students of the danger of this without them having to live through the hell-stress of being about to fail, before the lesson sinks in...

IDEO's Ten Tips for Teachers

Brenda pointed me at this article about creating a "21st century classroom experience." This has nothing to do with game design per se, except that just about all of these tips are restatements of basic game design principles, suggesting once again that game design is applied education (or maybe it's the other way around).

Summary of the tips and their context as a game design teacher (several points in the article are restatements of one another, so I collapsed them):

• Don't just push information. Encourage students to think critically by creating an environment where the students can (and want to) ask questions. Translation: let the player actually play in your game world. How fun would a game be if it just told the player to enter a certain code and then asked them to play it back?
• Make it relevant. Don't just explain arbitrary facts, put it in the context of how they're actually used so the students can see a connection between theory and practice. I've already written about that a couple of times.
• Soft skills are important. What will really make the difference is your students' abilities in leadership, empathy, communication, teamwork, and other things that are hard to measure on multiple choice exams. This is why games like The Sims and World of Warcraft are popular, despite them not having distinct measurable goals.
• Allow for variation. Education isn't one-size-fits-all; different students have different levels of ability and prior experience. Translation: include multiple difficulty levels in your game.
• Give practical experience, not just theory. The article goes so far as to say that teachers are "designers" so apparently I'm not the only one saying this. Translation: if it's nothing more than a series of cut scenes, it isn't a very fun game. Or, as Sid Meier has famously said, "if the designer is having more fun than the player, you have made a terrible mistake."

Teaching Iteration and Risk-Taking

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:

• My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
• All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
• For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
• On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
• Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.

Blogging on Applied Game Design

In addition to this blog, Brenda has given me the ability to post on the Applied Game Design blog, so I will occasionally make posts over there about the theory and practice of game design.

Why not just post here? I want this blog to remain a resource for students and educators about teaching game design, and my own rantings on how to actually make better games are best done elsewhere.

Any post over there by 'ai864' is me. I've already made my first post.

I will still be writing here about teaching game design, of course.

Theory of Fun back in print!

Raph Koster's A Theory of Fun for Game Design has been out of print for a few years, making it obnoxiously difficult for anyone to actually buy it for less than $200 or so.

Happily, it is now back in print for about $15.

I suspect a lot of teachers will suddenly be adding another book to their required texts next term...

Global Game Jam article on Gamasutra

For those of you who are wondering what was going on during the Global Game Jam, Stephen Jacobs wrote up a fantastic blow-by-blow account of the action. His article is on Gamasutra.

I'm even quoted a few times in the article.

Sometimes, I teach a little too well...

The other day, I met some people who are thinking of hiring a game designer, I mention that I'm available for contract work.

One of my students who was present stepped in front of me and mentioned that he's also available, and cheaper to hire than me.

I know that I always say to pay attention, be observant, be ready to pounce on an opportunity... and apparently some of them actually listen. I'm thinking that, in the long run, this is probably a good thing.

Summer Internships

The question was recently raised on the IGDA Game Educators mailing list: how can students find summer internships in games? If you're a student, this is probably on your mind; if you're a professor, students will probably ask you. I posted a response there, but I thought it's worth saying here.

First, let me say that internships in the game industry are rare. This is not about game companies being mean, or hating students. It's because game projects typically take longer than a summer, and development teams don't particularly like it when a key project member leaves in mid-project. It also takes people time to ramp up, which means just around the time the intern is finally able to contribute something to the team, they leave. Also, interns take a lot of management time that a typically-overworked producer does not have, so many studios decide that it's just not worth it.

This is not to say that internships don't exist, merely that the companies that offer them tend to be low-key about it (lest they be flooded with tens of thousands of resumes from eager college students). That means they aren't advertising, so you have to find them other ways (see below).

My advice to students seeking summer employment:

First, do your homework. Research a lot of game companies, go to their corporate websites and see if they have internship programs. Best bets are local companies, since realistically you aren't going to get housing or relocation expenses (some companies won't even consider you for an internship unless you live in the area). Be willing to look at lesser-known companies (not just the big names that you drool over), and look in related fields like serious games -- fewer students are looking there, so there's less competition.

How do you find local developers? First, check GameDevMap. Second, check if there's a local IGDA chapter. Third, check Google with a search string that implies game developers in your local area. Fourth, check with your school's career services office... but you probably won't find anything there that you couldn't have found on your own, which is why I list it last.

Some "internships" may not be listed as such; rather, they may be called "QA" positions that just happen to span the summer term.

If you can't find anything in games, consider a related industry. Programmers can do a programming internship at any software company and still gain valuable experience. Artists could work in fields like advertising or industrial design.

If you absolutely can't find any paid work, finances permitting, "hire" yourself full-time to work on your own game projects! Force yourself to work 40+ hours per week on your own game, as if you were at a full-time job. (This works even better if you have some friends you can team up with.) Keep your scope small, so that your projects are achievable. The point here isn't to "start a game company" or "make a great game and sell it" -- the point is to get valuable experience making games. If your project sucks, that's fine, as long as you learned something from the process. If your project does end up being awesome, enter it in the IGF student showcase, which is just as juicy a resume bullet-point as an internship (if you win).

Does "online" mean "automated"?

It seems to me that every school that offers online courses does things a bit differently. For the classes that I teach online, I try to have as much interactivity as I have time for. I'll post on discussion boards, I host virtual "office hours" through an online chat program, and I send out regular emails with my own personal spin on the topic. I also offer feedback through grading papers, even if it takes me longer.

I realized today that in theory, the entire thing could be automated:

• The course content is all online, so there's no reason why I need to add anything to it. Let the students read it on their own without the professor offering any extra commentary.
• The discussion boards are for students to interact with each other, not the professor. When "participation" is one of the grades of the course, there are tools where you can get post counts, average length of post, and all kinds of usage stats without ever having to actually, you know, read what one of those student people is actually saying.
• Papers can't be automated easily, but if you design the course you could go light on those assignments and heavy on multiple-choice and fill-in-the-blank quizzes which can be graded by a computer system.
• Instead of holding regular "office hours", simply post your phone number and let students call if they need help with anything. You know they never will, whether it be from feelings of politeness or intimidation.

Not that I would ever teach this way, mind you. I don't think it's really teaching if I'm not involved, it's more like a long, drawn-out certification process.

On the other hand, it's easy to "teach" a class this way, so I'm sure there are people out there who do it like that. Some might just be overwhelmed with other things in life so they fall back on something easy. Others might be greedy and want extra pay for next to no effort. Still others might think this is what online classes are supposed to be, that once you get a computer involved it somehow means humans should be removed from the equation.

I suppose the lesson here for students is: buyer beware. Make sure that you're getting your money's worth when signing up for an online class, and make sure you know what kind of instruction and personalized attention you can expect. If all you're looking for is a few quick credit hours without having to leave your dorm room that's one thing, but if you're actually looking for an education then do your due diligence. (Put at least as much effort into shopping for a class as you might into getting a high-end stereo system for your dorm, since that's probably about what you're paying.)

Interestingly, I think there's a parallel here with outsourcing in the game industry, in that many companies that think "outsourcing" really want the thing they're outsourcing to be automated (and they find out to their chagrin that game development is not so easy a process to automate).

What is the teacher's most valuable IP?

I have an ongoing discussion with several colleagues about the basic question of where a teacher's value lies. This is particularly important in a field like game design, where a new professor is likely going to be the only one in the department with any game-related expertise and will therefore be doing some curriculum development, some course content development, and of course the actual teaching.

There seem to be two schools of thought with respect to this.

The first model, I'll call "value in output." The professor is a machine that converts money and coffee into curriculum and course materials. The real value is in these secrets of the field that the professor distills into small documents like lesson plans and curriculum documents. This is valuable information that must be protected. You can tell the schools that think this way because they have something in their contracts that makes sure the school gets IP ownership of the professor's work, or (at the very least) they would be very much against a professor releasing this material to the public, or taking it to another school.

The second model, I'll call "value in person." The idea is that it is the professor who is valuable, not the work. A skilled professor can always create more classes, revise the curriculum or what have you, and it is therefore the human being that has value. An analogy would be valuing the goose more than the golden eggs. You can tell the schools that fall into this category by their willingness to release their course content online, give their professors more control over their own work output, and are generally happy to just sit back and do nothing as long as the profs are bringing glory to the school.

We have this in the game industry, too. Where is the value in a game: the IP, the code base, or the development team? Depending on a publisher's viewpoint, they will treat their developers very differently.

If you're a teacher or a developer, think for a moment about how your school (or your publisher) sees you and your contributions. Is there more focus on your work output, or your ongoing ability to produce that output? Which view is superior? If the answer is "it depends," what does it depend on?

Speaking Schedule

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)