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