Giving Great Game Demos

Alex Yeager of Mayfair gave a great seminar at Origins called The 2-2-2 Demo. What follows are my notes. There are several applications:

• If you regularly introduce your students or colleagues to new games, it helps if you can explain the rules succinctly. This is the direct application.
• Explaining the rules of a game is no different than teaching any other course material. If you can explain how to play a game, you could use the same basic framework to explain your course material.
• The process of creating a game demo has similarities to the process of designing an actual game.
• You'll probably see other parallels as you read on.

What is a "game demo"?

In this particular context, it means a way of introducing someone else to a game they haven't played before. There are many reasons you might want to do this: to simply familiarize them with the game for educational or historical purposes, to get them interested in the game enough to play it, to convince them to buy it, etc.

There are many types of demos, but Alex gave three types: Two-sentence, Two-minute and To-play (hence, "2-2-2").

The Two-Sentence demo

In the game industry, we would call this an "elevator pitch." In just a couple sentences, state the basic theme and goal of the game. The purpose here is not to explain the rules, but to gauge and generate interest. It gives the other person an opportunity to bow out without you wasting ten minutes on a full rules explanation before saying they're not interested. If they are interested, this provides a context for everything that follows.

The Two-Minute demo

Discuss the type/genre of game, general flow of gameplay, win conditions and other important core mechanics. Take the two-sentence demo and add detail. Emphasize the important decisions that players are making.

Again, the purpose here isn't to give the other person everything they need to play, but it makes a full explanation of the rules go much faster if they already have a mental framework to put things in context. The purpose is still to generate enough interest to proceed to a full demo.

The two-minute demo has another purpose. People who have played the game, like it and want to evangelize it can use a version of your two-minute demo when they show the game to their peers. This provides a way for you to "deputize" players so that they can generate interest in the game from their friends, who can all them come back to you. (Think about this. Do you teach any courses where your students are actively recruiting on your behalf for next semester?)

It's worth mentioning that some games do this for you automatically. If a game has neat-looking components that make players go "wow... what's that? Can we play that one?" then you can safely skip the short version and leap into the rules. Not many games have that kind of "curb appeal" but a few do.

The To-Play demo

When game enthusiasts want to demo a game, many of them leap immediately into a full explanation of the rules. For some people (e.g. other hardcore gamers who have already agreed to play) this is fine. Other people (especially non-gamers) may still be tentatively deciding whether they want to play at all, and launching into a full-blown rules description can quickly overwhelm them.

Use this demo to teach the game to people who have already decided to play. They are actively engaged and they've got the time and opportunity. Otherwise, start with something simpler.

The best to-play demos are things you've practiced before. Become intimately familiar with the rules yourself before teaching them, ideally. Think of ways to present the rules so that they're easy to understand, flow well and can be explained in a minimum amount of time.

Personally, I've found that for most board games, the following framework tends to work well:

• First, state the object of the game, unless it's really obscure or needs other information to be understood. It provides the context for why the player should care about other rules. Frame all other rules in terms of "how can you use this to win?"
• Then, talk about the progression of play. How do turns work? What can you do on your turn? Start with the things you do most of the time, and just briefly touch on exceptions that only come up once in awhile.
• Next, mention the game end condition. What causes the game to end, and how (if at all) do players have control over causing the game to end or continue?
• If you can just set up the game yourself without having to explain initial setup as a series of rules, do so. Otherwise, explain the first part of the game last, after the players already understand the general flow of play and can make intelligent decisions during setup.

Implications for playing games

When explaining games to people who aren't gamers (like friends or family), start with very simple explanations. Don't continue into something more complex until you see the other person's interest, or else you may bore or overwhelm them.

Implications for teaching

Start each course topic with a general "why should I care?" / "why is this cool?" overview, then layer on some basic details and the overall flow of what you're about to learn, and then go into the gory details once you've got the class interested. Once your students see why the stuff you're teaching is important, they'll pay a lot more attention.

Implications for game design

Don't create a game (either digital or non-digital) where your players must understand and master all of the mechanics before they make their first move. Try to create play situations where the player is slowly and gently introduced to new mechanics, allowed to feel through the general flow of the game in a relatively safe environment. Then, add the details once the player is hooked.

Bonus insight: Implications for curriculum design

According to Alex, there's a pattern when introducing Eurogames to kids who are unfamiliar with them:

• When you teach one game, that's all they want to play. "I played Settlers of Catan before, it was fun, I want to play it again." There are, apparently, no other games worth playing.
• When you teach a second game, there's a choice: play X or play Y. "We played Carcassonne last time, let's try Settlers again."
• But when you teach a third game, something magical happens. The players start seeing connections and comparisons that go beyond simple either/or choices. "Let's see... I'm in the mood for a trading/auction game, and Joe says he has to be somewhere in an hour so it can't be more than that, and Sarah hasn't played before and wants something easy to learn... how about Modern Art?"

I think education may work like this in general. Take a Biology 101 class where they force you to memorize all of the structures of the cell, and you assume that the entire field is just memorization. Take Genetics and you might think that the field is part memorization, part math. Take a microbiology course... and suddenly you realize that it's actually a really diverse field, and all those other courses aren't just repeats of the same stuff you've taken already, they're starting with some basic concepts and taking them in a whole new direction, and how cool is that? But only the people in the major get to see this. Implication: the "101" or "Survey" courses, especially those aimed at non-majors or prospective majors, should be designed to expose them to at least three different areas of the field. In these classes, focus less on laying a foundation for the major, and more on the diversity and overarching patterns and common problems that they will see in the field.

Back on regular posting schedule

First there was Origins. Then I came back to find that I had a week to finish up final review for my first book. Then I got some short-term industry contract work. So, things have kept me busy, but I'm now back. In the coming weeks I'll follow up with what I learned at Origins this year in terms of teaching, game design and more.

One thing I've been thinking about for a little while now is the similarity between education and game design. I'm starting to actually read some books on education, and an awful lot of concepts are identical, they just have different names. I heard this from several teachers at Origins as well -- after seeing my presentation, they remarked that some general concepts of game design are the same as in the professional literature for education, except that they are perhaps easier to understand in the context of games (if the teacher happens to be a gamer, at any rate).

For example, one of the concepts most game designers are familiar with is the MDA Framework, which says (among other things) that there are many different kinds of fun, that different games offer different combinations of these kinds of fun, and that different players find some kinds of fun more or less engaging than others. There's a parallel to different kinds of learners in a classroom environment: audio learners, visual learners, kinesthetic learners and so on, where each student is engaged by a particular type of activity. It's not much of a stretch to find links between the kinds of classroom activities and the kinds of fun in game that people find engaging.

A more interesting example is rubrics. I'd never heard the term 'rubric' before becoming a teacher. Essentially it means making a list of skills, and then grouping and classifying them. For example, a grading rubric for a class would list all of the things students are expected to be able to do after taking the class, and then what skills the students must build in order to do those things, and then what the students must demonstrate (and at what level) in order to achieve an A, B, C, etc.

Most teachers I know hate developing rubrics. It's a chore that involves tons of paperwork, and defining all these tiny details about a class and the concepts that you're teaching and how they all relate to each other and how you plan to measure everything. It's something that teachers do only when forced at gunpoint.

And yet, there are designers of computer/console role-playing games that do essentially the same thing. What are the capabilities that I want the players to be able to take advantage of in and out of combat? What are the skills, abilities and magic spells that I can make available to the players to allow them to accomplish these feats? How should I group these skills and abilities and spells -- by function, by elemental sphere, by character class? How do players gain access to these skills -- leveling up, completing quests, finding items? And this is the kind of content design that RPG designers absolutely love. It's the really fun part. It's a hoot. They'll go back and design more of these skills for fun, on their own time, rather than doing the important work like testing the combat system for balance.

Somehow, there has got to be a way to make rubrics as exciting as RPG design. I haven't figured out how yet. But it's the same freaking task.

Origins 2008

It's that time of year again.

I'll be speaking twice:

• Friday 6/27 @ 9am, room C215: "Game Design for Teachers" - basically a repeat of last year's presentation (I posted a two-part summary here and here). Last year I ran out of time, so I streamlined the content a bit for this year, concentrating on the theory more than the practical.
• Saturday 6/28 @ 9am, room C215: "Advanced Game Design for Teachers" - new this year, includes the practical aspects (some case studies that I wouldn't have time to present in the other session) and a short workshop where we'll take some content from the attendees and find ways to present it to the class in a more game-like way.

I'll also be taking a lot of photos and meeting with some game publishers for the book, so I expect this year to be a bit different in that I'll be spending as much time doing work as I will be playing games.

This year will also be different in that I know some of my students will actually be there. (It helps when my students from this last year live in the same city, as opposed to 80 miles away.)

If anyone out there is in the area, feel free to find me and say hi. And if anyone out there happens to be a teacher in the area (this includes anything from homeschooling to K-12 to grad student TA to college professor), bring your credentials and you get in the door for free.

Why You Hated Your College Teachers

Okay, there were probably a handful of professors that were incredibly inspirational to you, but these stood out in a sea of instructors that you've long since forgotten. (Even if you're currently a student.)

Having compared three different schools that I've worked at, I think I know why.

A full-time teaching instructor is expected to teach four classes at a time. From my experience, teaching a class takes about ten hours a week (this includes about 4 hours in class, plus extra time for prep work and grading). So far, that's a 40-hour work week, which is expected.

But then you have office hours, typically anywhere from 4 to 10 additional hours per week. If your students don't show up then you can use this time for grading, but it seems to me that if you're counting on your students never visiting you then that's a greater problem... but it's certainly not something you should be encouraging as a teacher.

Then there's academic advising, which is nothing most of the time but makes for a week of hell somewhere near the end of each class, as you get a flood of students with paperwork. So far I haven't been involved in this process enough to say what the time commitment is, but I think I can reasonably say that it's not zero.

There are department meetings, which is an extra hour or two every week or two. Already we're somewhere around 50 hours per week. If you want to do anything extracurricular, such as be the sponsor of a student club or perform community outreach to local high schools or offer seminars to your faculty colleagues or what have you, that's extra. Some schools mandate that you put in a minimum number of these kinds of extra hours, others don't.

Now, those of you in the game industry are scoffing at me here. I'm concerned about a mere 50 hours, when it's not unheard of in game development to pull 90+ for extended periods? Ah, but here's the rub: game developers are, by and large, a passionate bunch. We got into the game industry specifically because we love games and want to make them. I'd say that of the professional developers I've worked with, somewhere around 90% of them have a passion for their work and are more than willing to put some extra time in if it'll improve their project, or if it'll give them a chance to improve their own skills and hone their craft.

Teaching is different. Of all the professors I've met, maybe 5% are passionate about teaching, so very few are going to willingly put in the extra time unless forced at gunpoint. And the thing is, with both teaching and game dev, the quality of the final product is proportional to the amount of work you put in.

There are other things that modify a teacher's workload:

• Studio/practical classes take significantly less time than lectures. You just have to design assignments, so the amount of prep work before class is minimal. Strangely, it counts as the same, so loading up on studio classes is a way to game the system. Of course, someone has to teach the lecture-based classes, so you're just reducing your workload at the expense of your colleagues (who are probably not as passionate about teaching as you).
• Online classes are insidious. They seem like they should take less time because there is no lecture, but I think they actually take slightly more time because you have to log in, check email and contribute to discussions on an almost-daily basis. Think about how much time you spend just checking your email, RSS feeds and discussion forums in the morning and you'll see what I mean. The time flies by so it doesn't feel that bad, but the total time per week is a little more than a typical lecture class, so you have to be careful. Some schools recognize this and actually pay a slight premium to online instructors; others treat online as equivalent to a "normal" class.
• For lecture classes, my above figure of 10 hours per week depends on two major factors: amount/intensity of grading, and amount of previous course prep. If your assignments are easier to grade (e.g. multiple-choice as opposed to essay questions) that will reduce your time commitment, at the expense of having assignments that are meaningful -- the Real World rarely gives you multiple choices, after all. As for course prep, a class requires more time the first time you teach it. Some schools give you a break if one of your courses is brand-new and developed by you (say, only teaching 3 classes instead of 4), while others make no such allowances.

There's a common theme here. Almost everything that a teacher can do to make their own life easier, does so only at the cost to the quality of their students' education. Which means that the teachers who are passionate about teaching and really care are the ones who spend 60+ hours per week, and everyone else is going to do whatever they can to bring their hours worked as close to 40 as possible.

From Gamer to Designer

Most of the people I knew in the game industry who were game designers, were that way from a very young age (myself included). We would make games, even if they weren't very good. When we played games, we would think about the rules. We would write design documents in crayon. It's just something we did naturally, without having to be prompted.

I'm sure that in the game industry, that made game designers easy to screen out. If you ask a question like "what's your favorite game" and then start analyzing that game -- what were the design mistakes (no game is perfect, even your favorite), what would you have done differently, what elements of the game make it so compelling -- the discussion flows naturally with the right candidate. For the people who are more gamer than game designer, though, this kind of question is anathema. "What do you mean, critique my favorite game of all time? It's awesome, it's great, what more is there to say?"

Because that's clearly helpful in a design document, saying that the game should be "great" and "awesome."

Now, I'm in the position of teaching people to be game designers, and it's just occurred to me that my classes have a high proportion of gamers in them, and not everyone sees the distinction. I didn't notice the dividing line in my classes either, until just now when grading the final exam. One of the questions goes something like this: "Write a one-paragraph game concept for a video game that has the following constraints: blah blah blah." And the answers that I get fall into a few different categories:

• "My game will be just like a combination of this game and this other game." Great, but what if I haven't played those games? And how do you plan on being innovative if all of your ideas are based on earlier video games?
• "My game has this story..." Okay, maybe you have a future as a story writer, but my class is in game design, specifically core mechanics. What does the player do?
• A full paragraph with all sorts of things describing how great and fun it will be, with maybe two words to give some clue as to the actual gameplay. These are the fanboys (or fangirls, I suppose, but in my experience it's always the guys that do this). It makes me sad to see that after ten full weeks of learning about how to speak critically about games, as soon as I ask someone to apply it then it all goes out the window and they revert to their earlier fanboy status. I suppose there are some kinds of people that I haven't figured out how to reach yet.
• And every now and then, I see a student who writes a concept that includes a description of mechanics and gameplay. Apparently, it doesn't occur to them that the question would be asking for anything else (and they're right).

Generally, the students who answer in the latter category are the ones who tend to do well in the class overall. It's making me wonder if this is something of a litmus test for game designers: ask an open-ended question that involves designing a simple game concept, and see what people do. Maybe I'll try that on the first day of class next time, as opposed to on the final exam...

And then for the students who aren't getting it on Day One, I need to work out some strategy to get them to abandon their lifelong gamer mentality for long enough to start thinking like a designer.

Spelling Lesson

Game designers have to do a lot of writing. As a teacher of game design, this means I see a lot of student writing. I don't know what they do over in the English department, but whatever students learn over there, it seems like it doesn't always stick. Maybe it's because no one ever draws the parallel between writing in English class and writing for other classes, that you use the same skills. I don't know.

There are a few errors in particular that I see more frequently than others in game writing. Given the importance of writing to a game designer, I think it's fair to say that these are the kinds of errors that could lose a job opportunity if they appear in a cover letter. (Programmers probably get slightly more leniency.)

This is my list of Most Frequent Student Mistakes. If you're a student, learn these, because you might not get marked off in your game design classes but you certainly will in your job application. If you're a teacher of game design, feel free to add your own frequent student mistakes in the comments.

• Bored vs. Board. If you're doing a dull task, you're bored. If you're playing a game like Chess, you are playing on a game board. If you say that you're "board" it means that you feel like a non-digital game component. If you call something a "bored game" it is an insult to the game's designer.


• Lose vs. Loose. If you fail to win a game, you lose. If something isn't tight, it's loose. There is no such thing as "loosing" a game, and you never "loose" a life.


• Roll vs. Role. If you want to throw a pair of dice to get a random result, you roll them. If you are acting in character, you are playing a role. If you "role" dice it means you're trying to behave as if you were one of them. If you are playing a "roll-playing" game you're implying that you do more die-rolling than actual role-playing, which is generally considered an insult.


• Suit vs. Suite. Each card in a standard poker deck belongs to a suit. Hotels and office buildings have large rooms called suites. If you refer to Clubs as a "suite" you had better be talking about a swanky dance club and not a deck of cards.


• To vs. Too. If you could substitute the word "also," use too. Otherwise, use to. Not specific to games but a lot of students seem to have a problem with this and use "to" for everything.


• Affect vs. Effect. For the purposes of describing gameplay affect is almost always a verb, and effect is a noun. A special ability in a game may have an effect on the game, and it may affect your chances of winning. There are rare exceptions to this which can generally be ignored if you're writing about games.


• Know vs. No. If you understand a piece of information, you know it. The opposite of yes is no. If you say that you "no the rules of the game" then... um... well, I'm not really sure what you're saying, but it's not what you think you're saying.

Note that a spelling/grammer checker will often not help you with these, so proofread your own stuff even if Microsoft Word says everything is fine.

I also see some common misspellings, which surprise me in their frequency given that they would be caught by a spell checker:

• Obstacle. Not "obsticle."
• Strategy. Not "stragety" or "stratagy." And learn to pronounce it correctly. I blame Bugs Bunny for this one.
• Ridiculous. Not "rediculous."
• Sense. Not "sence."
• Experience. Not "experiance."
• Explanation. Not "explination."
• Definitely. Not "definately."

Culture Shock: Retention and Turnover

In the game industry (and in fact, in any professional industry), employee turnover is expensive. If someone leaves the company and you have to replace them, there's the expense of interviews (which take a lot of time away from senior people) and then the extra time it takes the new hire to get productive. Companies that realize this do what they can to retain their employees. Indefinitely.

Being a professor is different. In my case, "turnover" means that a student has graduated. It means I'm doing my job correctly. It also means fighting against the instinct of "gotta keep our best people around" that I'm used to from being in the industry.

Choosing a School: Focus on Games

Question: Can I see a syllabus for some of the game classes this school offers?

What to look for: In the syllabus, see if the topics are specific to games, or more generalized to other media. If you want to make games, specifically, then you'll want classes that have readings and homeworks that involve games -- not movies, not literature, and not the World Wide Web. Of course, the reverse is true if you want game development to be only one option of many.

What to do: Look through the syllabi that you receive, paying close attention to the assignments (readings and projects). If there is a textbook, find it at your local library or book store and skim through it. If a syllabus is not available, ask some students who have taken the classes if they might have an old one; at the very least, ask them if the class is about video games or if that's only part of it. Also search the public website; occasionally you'll find that certain parts of a course are unrestricted access.

What to watch out for: A lot of classes (and majors!) have titles that sound like they focus on games, but then you find out that they don't. A few examples (feel free to post others in the comments):

• Nonlinear Storytelling. This might be a class about interactive stories in video games. Or, it might deal with stories in other media that are told out of order, like the movies Memento and Pulp Fiction.
• Digital Media Production. Could mean game production, in the sense of actually creating a video game. Or it could be game production in the sense of teaching you how to be a producer (dealing with scheduling and budgets). Or it could be either of those things for other media, like movie production. Or it could be special effects, like audio/video post-production for movies.
• Introduction to Interactive Multimedia. This might be an obfuscated way to say "intro to video games" or it might be a class in Web page design or Flash programming.

In short, if you know exactly what you want from your program of study, make sure you're going to get it!

Choosing a School: Diversity

Question: How diverse is the student game developer population in this school, overall? How about the top 10% or so?

What to look for: Ideally, you'd like to see a wide range of socioeconomic backgrounds and demographics, but in most cases you won't. At least shoot for more diverse than the game industry.

What to do: Schools generally know the demographics of their student body. They also know who the top students are. Not all schools put the two together to see how they overlap, so you might have to do some detective work on your own. Grades of individual students are confidential (as well they should be), but you can see if the Dean's List is public, and then take a guess based on names and any other information that happens to be there. When you visit campus (you are going to see the place for yourself before you commit to spending four years of your life there, aren't you?), you can also get qualitative information from existing students.

What to watch out for: If all of the students in the program look like they were all cloned from the same genetic material, it could mean several things. It could be that the school is actively selecting people that fit specific criteria, which could signal that they're more interested in being a factory that churns out degrees than actually caring about you as an individual. It could be that the school has difficulty attracting women and minorities, which means you'll be less sensitive to diversity issues than you should be if you're white/male/straight, and you'll be feeling slightly uncomfortable (at best!) if you're not. If the student body within game development is diverse as a whole, but the top students are all white/male/straight, then that suggests the program is set up to reward certain types of students -- likely because the faculty look like clones, even if the students aren't.

In general, a diverse population means that a wide variety of people can succeed at the school. Without it, the implication is that exactly one type of student succeeds, the one who can Fit In Here And Be Just Like Everyone Else. If you feel like you'll fit right in, this might be okay... but take a Women's Studies or Minority Studies course anyway, will ya?

Choosing a School: Why Question At All?

Students choose schools for all kinds of reasons. At the community college level, it's often based on proximity to home more than anything else. With four-year schools, it could be anything from geographic location to campus size to how pretty the campus looks to which school one's boyfriend/girlfriend is attending. It's easy to ignore the quality of the school.

Complicating things further, schools have a process set up where you have to apply to attend there, which immediately puts the prospective student in a position of perceived weakness. After all, you can't attend at all unless they say you can. If you are accepted, you should thank your lucky stars (because there's a line out the door and around the block of people waiting to take your place) and not ask any questions. Interviews for game industry jobs can feel similar to first-timers.

If you're a student looking at game schools, it's worth remembering a few things:

• You're paying an extreme cost in time (4+ years) and money (more than a new car, unless you have really expensive taste in cars). It's one of the largest expenses you'll have in your lifetime.
• You wouldn't buy a new car without at least kicking the tires and taking a test drive. You wouldn't buy a house without taking a tour and getting it professionally inspected. Do your due diligence the same way you would for any other big-ticket item.
• Screw this up and you'll graduate with a degree that makes you unemployable. Or you'll drop out and owe tens of thousands of dollars in exchange for no degree. Think about your next steps after you're done with school, and realize that your options change based on your school experience. It's worth taking the time up front to make sure you'll get what you're looking for.

Choosing a School: Student Projects

I've already given a few things for you to consider when choosing a school, but I think it's worth including some things you should not consider too much. One of the common themes of recruiters is to show off cool-looking student projects.

Be wary of student projects. At the DDAF, almost every presenter on the Education Panel showed a lot of work from their past and present students. The work looks impressive, and the implication is "we'll show you how to make something cool like this." But when I thought about it, it didn't really tell me anything about the school itself.

Every school has a few brilliant students who will produce phenomenal work, on their own, with or without faculty assistance. The work certainly reflects on the quality of that particular student, but may or may not have any correlation to the quality of the academic program.

It's also easy to get distracted by quantity. Some schools have large programs and lots of students, so they will likely have more student work to show than a smaller school. Take the size of the program into account.

Also be wary if the most impressive student work is more than a year or two old. Schools with quality programs and a steady stream of incoming students should be producing cool stuff every year. Showing one or two works from four years ago is an indication that the school just had a handful of outstanding students that year, not that they have a great program now.

Lastly, if the student work isn't similar to your area of interest, that should be a red flag. For example, if you want to be a game designer or a programmer and the only student work available is animated video clips (not playable games), you're probably dealing with an art/animation program that doesn't focus on games.

I'm not saying you should ignore student work entirely. But treat it the way a hiring manager at a company would treat personal references for a job. The applicant chose their best references so of course they're all going to say great things, so this shouldn't really persuade you. But if someone applying for a position can't even find a decent friend or two that can say something nice without reservations, maybe that's a signal you should be looking elsewhere.

Choosing a School: Job Placement

Question: What is your job placement rate out of all incoming freshmen? (This is tricky, and you might have to do the math yourself. Figure out the percentage of incoming freshmen make it all the way through the program and graduate, and multiply by the percentage of graduates who get jobs.)

What to look for: High numbers. What's good? I actually don't know. It's relative.

What to do: Compare the numbers of several schools.

What to watch out for: Schools that boast abnormally high job placement rate of their graduates... but only because their program is so obscenely difficult that only a tiny fraction of incoming students actually make it through. Or, schools that have low placement rates in the industry (indicating they aren't taken seriously by people who know how to judge talent and ability). Or, schools that can't tell you their placement rate because they don't track those numbers (indicating that the school might not care about you in the long term, as long as they get your tuition money today). Or, schools that inflate their job placement rate by encouraging students to start their own studios fresh out of college -- make sure their people are being hired by someone else, not themselves (I have nothing against starting your own studio, but if it happens too often at a particular school that's an indication that a lot of their graduating class couldn't get jobs at established companies that were hiring).

Choosing a School: Faculty

Question: Who are your faculty?

What to look for: Industry experience, doing work that is related to the classes they are teaching. Preferably at least one teacher who did the job that you want to get yourself some day.
What to do: Again, verify. Look up credits on Mobygames for games that were published. If a professor can't explain to you exactly what work they did on each title they worked on, find out yourself if you can, and view with extreme suspicion if you can't. Ditto if the school (or a particular professor) says they worked on "lots of games" but can't tell you which ones.

What to watch out for: There are a lot of "teachers" out there who are supposed to teach you how to make games even though they've never made one themselves. Would you want to learn how to cook from someone who's never been in a kitchen (no matter how many cookbooks they've read)? Would you pay money to take music lessons from someone who's never picked up an instrument? Would you take a skydiving course from someone who has never been in a plane? Someone with no experience can teach you the theory from a textbook, but they won't be able to guide you any further... and with so many bad textbooks out there, how would they know that what they're teaching is even valid?

Choosing a School

At the DDAF this week, I saw a lot of high school and community college students who were interested in studying games. I was actually a bit disappointed with the Education panel; great representation from six schools that have game development programs, but it basically amounted to each school giving a 15-minute recruitment pitch, with no one actually commenting on what to look for in a school or how to find the program that's right for you.

In fairness, "how to choose a school" isn't necessarily what the panel was supposed to be. But it struck me that a lot of students in the audience were skipping a few steps in the process, and would benefit from some more basic information, like what criteria are important in school selection, and even how to know if they should be considering a game school in the first place.

So, I was inspired to start writing a series of questions that are worth asking. If you're a student, I hope these will help you in selecting the best academic program to fit your needs. If you're an educator, give some thought to how you'd answer these questions, and if your program would stack up favorably. If you're in the industry... well, this might not be of much use unless you're on an advisory board for some college or university, but if you ever get asked by a father's brother's nephew's cousin's former roommate about what's the best school to go to, you'll have at least one URL to send back.

To start things off:

Question: What degree do you offer, what classes do you offer in that degree, and what jobs will that qualify me for?

What to look for: You should see a lot of classes, not just a traditional Art or Computer Science curriculum with a couple of "game" courses tacked on (this is assuming you're looking for a game-focused curriculum). You should see at least one course where you're working with people outside your major -- if you're an artist, you should be working with programmers. Obviously, the courses should be in your area of interest.

What to do: Verify that the school is giving good information. Check out the IGDA Curriculum Framework and see if the school's curriculum is in the general ballpark. Read the IGDA Breaking In website, and see if the courses you'd take are related in any way to the job you'd be doing.

What to watch out for: Some schools call their course of study "game design" even though it is actually a programming or game art curriculum. If the school does not know the simple difference between the various fields of game development, how valid is your education really going to be? Also, a lot of students haven't yet discovered their area of interest; they equate game development with playing games, or at least they haven't figured out that there are many fields of study. Know your own passion before you go to school for it.

The Joys and Frustrations of Grading

Having just graded another midterm, I realized something.

My favorite part of grading is when I ask a question that I know is difficult (but meaningful), and I see a student just totally nail the right answer on the head. It makes me feel... validated, like here's someone who was paying attention, here's something that I was able to teach.

My least favorite part is when I see an answer that's totally unintelligible, like the student was answering a question that I didn't ask, and it's clear that they either misunderstood the question or else that I'm misunderstanding their answer. On the one hand, I teach game design, not communication, so if the student understands the question and has the right answer and just has difficulty communicating then I feel bad about taking off too many points for it. On the other hand, I can't justify giving points for an answer that I don't think is right. So, I have to dock the points and hope that if I'm wrong, the student has the guts to call me on it (which actually happens a lot less often than I imagined it would). But I just hate the uncertainty.

Speaking next week: DDAF

For once, I've got a speaking engagement at an event that I don't have to travel to. The event in question is the Downtown Digital Arts Festival in Columbus, taking place May 7-9, right on the campus where I teach.

In particular, I'll be co-hosting a workshop called Game Design Improv with colleague Brenda Brathwaite. I'll post a report on it here when it's done.

If you're in the area, stop by. And if you're a student, also check out the panel discussions about the game industry as well. I don't think we've ever had so many game developers in Ohio at the same time before, so take advantage of this opportunity while you can!

Amusing Student Quote

It's the little things like this that I'd never anywhere else, that remind me why I like teaching so much. Paraphrasing a couple of students:

A: "So, from your definition of the word 'game,' real life would be a game."
B: "Yes, I think life is a game."
A: "Then, is death Game Over or just a checkpoint?"

The Industry Veteran vs. The Karate Kid

Matt Sakey says:
One of the challenges for a games-based classroom is transitioning learners from their onscreen experiences to real world applications. A game that teaches algebra should keep that fact well-hidden. Kids immediately get suspicious when threatened with something that seems too much like a learning tool. Instead, conceal the algebra training inside an economic or management sim along the lines of Zoo Tycoon (which conveniently would also teach about animals, basic geometry, problem solving, etc.), and ramp it up gently. But at some point you have to help the learner make the mental connection, the “oh wow” moment… to realize, essentially, that skills learned in interactive zoo management work in life as well.

That "oh wow" moment is key for learning, but not just for game-based learning as Matt suggests. It's critical to draw the parallels between what you're doing in a classroom and how it's actually used in the Real World, whether you use games or not. Without that connection, you run into all sorts of problems:

• Students learn rote facts and methods without understanding them in a broader context. When it comes time to apply their classroom knowledge, they'll have to go back and learn it again, because they never thought before of how to actually use it.
• Humans are inherently good at understanding and remembering stories, moreso than random factoids. Course content is the latter; showing how it's used is the former. Without the context, it's harder and more inefficient for students to learn the material.
• More to the point, a lot of students won't even pay attention if they don't see the value. If your class is perceived as just being an arbitrary hoop to jump through so your students can get a piece of paper, let's just say that you're not going to have your students passionately learning your subject.

And honestly, students are hungry for this understanding. If you teach a class, try this, if you don't already. One day, just take two minutes at the start of class to tell a story about how the stuff you're learning in class today was actually used to do, well, anything useful or cool. See if your students don't pay a whole lot more attention for the entire day.

And this is a problem with a lot of college classes. Many professors have no idea how their course material is used in practice (career academics are especially vulnerable to this), or they know but they aren't telling. When I first took Linear Algebra, we learned everything except practical application, so I did the familiar cram-for-the-exam-then-forget-everything method of study. Then I took Computer Graphics, which was really cool, and I realized that maybe I should have paid more attention since we were using scaling, rotation and translation matrices on a regular basis. And then I took another neat course where we learned about the math behind sending a space shuttle into orbit, which required a whole lot of dealing with vectors and matrices. And then I worked in the industry as a game designer of all things, and found that you could use matrices to solve certain types of game balance problems. This would have been nice to know when I was taking the course!

It's like a lot of professors out there imagine themselves as Mr. Miyagi from The Karate Kid. Wax on, wax off. Do that a few thousand times. After you're done, then I'll tell you how to kick the other guy's face in. That makes for great storytelling, but lousy pedagogy.

So, I see this as a huge advantage for professors who have actual, honest-to-goodness industry experience: we can share that experience with our classes. Why am I spending perfectly good class time talking about something abstract and obscure like positive feedback loops? Glad you asked, let me tell you about a game I worked on that had game balance issues because of a feedback loop that was unintentionally embedded in the core mechanics, and here's what we did to fix it. I'm not teaching you this stuff because the IGDA Curriculum Framework says I should, I'm teaching you the stuff that I've actually used myself on the job. So pay attention. (And they do, most of the time.)

Now, there is a danger here: you have to have the context but also the content. There is a perception in academic circles that the only thing an industry person does is come into the classroom and tell a bunch of entertaining war stories. You've gotta deliver the goods, too, so your students actually have the knowledge and skills that they're supposed to apply. But in my own experience as a student and as a teacher, there's more danger of too little context than too much.

The Paradox of Student Failure

Reading over my notes from GDC, I just realized that I commonly hear two pieces of advice for teaching:

• Encourage students to fail early and often. Being in school is the one time where you can do this without losing millions of publisher dollars in the process. BUT,
• Punish students harshly for failure. It's a tough industry, and classes should reflect that.

These aren't necessarily mutually exclusive, although it seems like it at first glance. The former is primarily concerned with taking creative risks: trying forms of gameplay that have never been done before. The latter mostly involves setting and achieving reasonable goals: controlling the scope of a project, keeping to a schedule and meeting deadlines.

However, the two viewpoints collide when you're teaching a studio class where the output is a complete game -- if the students try hard, but end up making a game that is just not fun or interesting (in spite of their efforts). As a teacher, do you grade them harshly, because a comparable professional project would mean that their studio would be out of business and they'd all be looking for new work? Or do you grade them generously for their ability to try hard, stick with a process and complete the project? Either way would seem to send the wrong message.

Teaching Portfolios?

One common mistake I warn students about (especially art and audio students, and to a lesser extent game design students) is to never include substandard work in a portfolio just to show how much you've improved. Game companies don't care about how much you've improved, they care about how good you are now, and whether you can help them make a great game now. If you put mediocre work in your portfolio, the message you send is that this is the best you can do.

It occurred to me the other day that this might not be the case for teachers. I've never heard of an instructor putting together a portfolio of their own students' work to show how much their students have improved under their tutelage, but I don't see why something like that wouldn't be valuable if you're marketing yourself as a first-rate teacher.

Likewise, a university might consider this for its promotional materials, the same way that the beauty industry likes to show lots of before/after photos so you can see how much of a change their products can make. Again, I've never seen this before, but at the moment I'm having a hard time thinking why not.

Report from GDX

So, I'm just heading home from GDX 2008. My talk was about what a nontechnical game designer can do to get a better understanding of programming; I'll post a link to the slides as soon as I figure out where to host them.

The conference itself was great; it was small (about 700 people, compared to the ~30,000 at GDC) which meant that you actually have the time to have real conversations with people, without having to leave to say a quick 'hi' to twenty more people. You have time to actually play games with other game developers. You get to meet the people for the first time who you've previously passed a dozen times in the hallways of GDC, like ships in the night.

Some quick thoughts that I wrote down from all of my various side discussions with people, in no particular order:

• There's a common pattern in teaching game design: many students start out wanting to make a copy of their favorite big-budget game; as students, they have this huge gift that is the academic freedom to innovate, and they just want to make Something of War-something. After they get in the industry and the novelty wears off, then they want the freedom to create and innovate that they no longer have. The professors from industry are already at the point where they value creative freedom and we're setting up our classes to provide what we wish we had when we were students, but we forget for a moment that we didn't appreciate what we had at the time. I'm not sure if there's a way to fix this, other than to treasure the few students who are exceptions and set them up as examples for everyone else.


• The term "independent" (or "indie") as applied to game development is vague, because it can mean any combination of three different things: business model (not owned by a publisher), money (low-budget, not AAA), or experimental gameplay (not just a derivative clone). It might be better to abolish the term "indie" from our vocabulary, and be more specific about what we're talking about.


• Women and minorities are still being horribly marginalized in the mainstream game industry (okay, no news there). But, most of the efforts to fix this so far have focused on attracting more of them to the industry. I'm thinking that an equally important piece of the puzzle is raising awareness within the existing industry that this is a major problem. In the past, I've suggested that every game designer should take Women's Studies as a class; I should add Minority Studies to the list. And I should specify that these would not be electives or suggestions, but required coursework for anyone seeking a game degree.


• Since the beginning of time, some games have been designed with technical constraints first. Today, it's something like "point-and-click is easy to implement in Flash, so what games can we make where the only player action is point-and-click?" A couple hundred years ago, it was "we have all these maps, what games can we play that use maps?" Three thousand years ago, it was "we have all this wood and rocks and pebbles, so what games can we play with wood and rocks and pebbles?"

Cheating at Community College

I won't say that students never cheat, either at a two-year or four-year institution. It's one of those things that a teacher has to watch out for. (In my case, I try to make my assignments enjoyable enough that no one would want to cheat... and when that fails, at least making assignments where it would be impossible to get someone else to do your work for you, like giving an in-class presentation.)

However, the methods of cheating differ between community college and a more typical four-year university. Honestly, policing a class at community college is much easier.

At a four-year school, there are student dorms, and fraternities and sororities and student clubs, all places where students can save old assignments and tests to form a study bank (which forces professors to vary their test questions, or else have some students who suspiciously seem to know every answer as if it were memorized...). Most students have a social network of friends and they typically study together, which opens the door to having them do each other's assignments.


At a community college, ironically, there is no community; it's a day campus only. Students may have friends, but a lot of those friends aren't fellow students, so there's less group study. Most students don't stay around longer than two years, either, which limits the amount of old tests they can pass on to the next "generation" of students (since this generation is only one year behind them).

The net result is that it's easier to repeat test questions at a community college, without fear that my students are going to walk in with a study sheet cribbed from last year's exam. It's also easier to request that homework assignments be done on an individual basis, because a lot of students don't have the means to work in groups anyway.

Of course, the down side to this is that assignments that require work in a team outside of class are much harder. As with everything in life, there are tradeoffs.

The Irony of Teaching a New Course

Suppose you develop a new course, one that has never been taught before anywhere else. I'm not sure if any of the classes I've taught are entirely original, but a couple of them might be.

It occurs to me that my students get course credit for taking my classes, but I don't get course credit for teaching it! Some day it might be nice to, you know, have a Bachelor's degree in game design from all the courses I've taught. But it's never going to happen, because I don't actually get course credit for teaching my courses.

In some ways it shouldn't matter. In theory, if I'm qualified to teach a course, it may as well be on my transcript anyway. In other ways it most certainly matters; if I teach a class at the graduate level when I don't have a graduate degree (yes, this can happen), it would be nice to get some credit hours towards my own graduate degree!

Students Modify the Teacher's Reputation

I was talking with Brenda recently (we do that a lot) and she gave me something new to worry about.

Whenever a student of mine gets a job in the industry, it reflects on me, personally (because most of the time, I'm the only person from industry they've had direct contact with in a classroom). In other words, my students may affect my ability to get industry contract work at some point.

The assumption is that if I taught them everything they know, then their skills and abilities are a reflection of my own. This isn't entirely true, of course, but it doesn't matter. A lot of people believe it's true, therefore it influences their perception, and perception is everything when it comes to reputation. I say "my" here, but this really applies to any industry-based teacher, especially at a school where they're the only one of their kind.

Sometimes this works in my favor. Last year I had two absolutely brilliant students who made it into the industry, and they're making me look good, through no fault of my own.

Sometimes this works against me. Maybe some day I'll have an absolutely horrible student, who somehow blunders into an industry job and screws things up horribly. If I'm asked to provide a recommendation I can be reserved about it, but beyond that, I have no defense against this. But it's still a potential black mark on my record.

I suppose if one is really paranoid, the best defense is to work for a university that has overly selective admission requirements, and get oneself installed on the admissions board. For the rest of us... I suppose we just have to cross our fingers and hope that we get more good than bad (and that maybe we can be enough of an influence on enough of our students to make the difference).

Terminal Degrees

Every field has its jargon. Game designers will happily talk about HUDs and avatars and positive feedback loops, oblivious to the fact that most people who haven't been doing this for the last few years of their career might have no idea what they're talking about. This is a particular danger when teaching, by the way, that you lapse into "designer-speak" without defining your terms, only to be met with blank stares.

People in academia do this too, and it can sometimes be confusing for the new designer-turned-teacher to keep up. A recent discussion on the IGDA game educators mailing list reminded me that one of the new terms an industry person is likely to run into is the terminal degree.

(Disclaimer: since I've only been doing this the last couple of years, I might get some details wrong. If you see any errors, feel free to post in the comments and I'll fix the post. Thank you.)

What is a terminal degree? The best description I can think of is a degree higher than Bachelor's, which is the highest degree offered, at the institution you received it, at the time you received it. Normally this means a Ph.D., but some fields don't offer one (the best-known are probably MFA and MBA) so those are referred to as terminal Master's degrees. Typically, a non-terminal Master's takes less time than a terminal Master's, which takes less time than a Ph.D. (in case you're trying to get an advanced degree as fast as possible).
Edit: Looks like I was wrong about this, it's just the highest degree offered in a field -- still, usually a Ph.D. but in some fields an MFA, or other degree. I'm not sure what happens at boundary conditions, such as if you get an MFA in Game Design (the highest degree offered today) and then one school decides to offer a Ph.D. in Game Design. Does that invalidate the 'terminality' of these other degrees?

Note that this means that if a new Ph.D. is offered at a university that previously only offered a Master's, whether the Master's is terminal or not is based on when the student enrolled; if you started before the Ph.D. was available, it's terminal. Timing matters.

Why should you care? Terminal degrees are important if you're planning to make a career of teaching. Having one means that you get paid more; at some places it's even a requirement for certain positions. If you don't have one already, think about getting one. Unfortunately, leaving a full-time career in industry to go back to graduate school is difficult for most people. Fortunately, once you do have a full-time job at a university, one of the more common benefits is being able to take classes for free or almost-free; if it's not practical to get your terminal degree first, it's quite possible to get it second.

From seeing a number of people going through graduate school, I also secretly suspect that it's called a "terminal degree" because it has a good chance of killing you.

Breaking Out of Silos

One problem that a lot of universities have is that each department is walled off from the others, and communication across departments is hard. (As you might imagine, communicationg with other schools is even harder.)

I think I may have accidentally discovered a way around this.

In my case, I teach game design classes that are typically dropped in some kind of multimedia department along with all the artists and animators, and finding an actual programmer in the bunch is like finding the needle in the proverbial haystack.

This quarter, I taught a class to programmers in their own department. (I did this for entirely selfish reasons: as an adjunct, taking on another course meant more pay. The fact that it let me speak to a room full of programming students so I could pimp my game design courses for next quarter was a nice bonus.)

The funny thing is, through the process of teaching this class, I met a lot of other faculty in the department, and they now see me as one of their own. I suspect the see me as "the guy who teaches Systems Analysis... oh, and he also does something with video games" rather than the other way around, and when they have students interested in games they know where to send them. This is not something that could have been done at the departmental level; it happened one-on-one, with me being right there in the trenches with the other faculty in a department that isn't my "home". I think I've built some bridges that just weren't there before, and I may try it again in the future.

By this time next year, I'll have taught classes at three different schools. It remains to be seen whether I can forge connections between them, but I'd like to. (This is especially important since my "main" employer right now is a community college, and we want to send our students to four-year schools when they're done here!)

Incidentally, this has another implication: if you're a professional developer considering a full-time switch to academia, having multiple skills (programming and game design, for example) is a huge benefit. It may or may not get you hired, but once you're in it might give you a foot in the door to teach one class in "that other department" -- and from there, maybe you can pull in a steady supply of interdisciplinary action right under everyone's nose.

Administering Exams as Game Strategy

I had my interactive final today in my Game Industry class, this being the fourth time I've given it. Nearly everything went wrong -- I couldn't connect the SNES's RF adaptor to the overhead projector, my PS2 suddenly died mid-exam with the dreaded Disc Read Error, and I forgot my Wii-mote at home which killed the idea of using that console at all. And yet, it ended up being a great experience, probably the best of any of the four times I've run the thing. What's behind this mystery?

I think the reason for this is familiarity: the same way that you learn a game at deeper levels by playing it multiple times. When you first start playing a game, you're dealing with very broad strategies: I want to go for the longest road bonus, I want to build a Necropotence deck, I want to play a Wizard. Or in this case, I want a collaborative final exam that feels somewhere between a game demo at the old E3 and a live game show.

As you play more, you start to see subtler variations in strategy and the tactics that support it: I should make my initial placement on Wood and Clay squares, I should tweak my deck, I should take the Toughness feat to make the early levels more survivable. In the case of the final exam, I notice that certain questions are frequenly misunderstood (and can be modified or eliminated), some questions can be asked of several games (so if I accidentally skip a question, I may be able to come back to it later), and some game demos can be simulated by finding a video on YouTube.

And that's what happened today, for the first time. I've given this exam enough that I'm now used to it, and I can make adjustments on the fly. I knew from experience that I need a few hours to set up all the equipment, so I arrived early. I knew to test everything beforehand, so I had enough advance warning to find gameplay videos online. I didn't expect a console to suddenly die in mid-exam, but I was able to adapt by eliminating one question and rewriting a couple of others in real-time. Small tweaks here and there, much the same as tweaking a Magic deck, or an RPG character, or a strategy.

Love is in the air...

So, two of my former students got married today. This was not a surprise; I don't think I ever saw one of them without the other for as long as I'd known them. (You can tell they were my students, because the bride walked down the aisle to the theme of Aerith. And the two figures on the top of the wedding cake were Tidus and Yuna.)

It was a strange feeling, being part of that. I certainly never would have dreamed of inviting any of my professors to meet my family when I was an undergrad. (My wife, who tried to get to know some of her professors outside of class, was repeatedly told that it was somehow "wrong" or "inappropriate" or "unprofessional" for reasons that I've yet to understand.) Yet, the whole thing doesn't make me feel weird or freaky. It makes me feel pretty special, actually.

I think this kind of thing might be specific to game professors, and maybe a few other professions. I'm teaching people how to go after their dream jobs, and part of that is learning about what their dreams actually are. Students don't typically seek game jobs for the fame or prestige or high pay; goals and hopes and dreams are always on the surface, and these things are very personal. So, I suppose it's much easier to know students on a personal level if you're teaching in this field, as opposed to teaching calculus, or quantum physics, or signals and systems.

At the same time, there was another strange thing I didn't expect: I didn't actually know anyone in the room. I saw these two students outside of class a lot of the time, so I figured I'd spot at least a few of the people I saw them hang out with. Instead I was in a room with a hundred strangers, and it made me realize just how much I didn't know about them. And I realized I'd felt this way before when I was a student, when I'd see one of my professors in the bathroom or the grocery store or something, and it was like "whoa, they're an actual human being with a life outside of the lecture hall?" And now I see the same thing in reverse -- whoa, my students have actual lives outside of my classes that I don't actually know about! (I used to think this was because there were all these formal barriers between students and professors that the professors put in the way intentionally; now I think it's just a by-product of seeing a person on a regular basis for only a few hours a week, so that you "know" them but only in a narrow context.)

So, for those of you in the industry who are considering teaching, this is the kind of stuff that I hope you have to look forward to. And yes, since I know you'll ask, the cake was delicious and moist.

Good luck, you crazy kids.

Random Tidbits from GDC 2008 for Students

To add to my notes from last year, here are some random bits of conversations I had this year that students may find interesting:

• Game projects that actually solve a social problem rather than merely being fun will get you more press, because most student game projects don't have any practical value to the player. If you provide some, you will stand out. Note that in the case of a game that raises awareness of an issue, the call to action can be the reward for beating the game!


• Evaluate lots of game authoring tools, from Game Maker to DarkBasic to Torque. Reviews listing the strengths and limitations of each would make for an excellent post on your blog if you have one, and could be of great help to professors who might be considering some or all of them but who have no time to evaluate them. This will also give you great practice at getting up to speed with a new tool, something you will probably have to do from time to time in the industry.


• If you go to GDC, don't drink. I know there are tons of great parties with open bars, but just don't do it. Think: how much did you pay to go to GDC? Probably $1000 or more. How many free drinks would you need in order to make the cost worthwhile? Too many. So, use your time at parties productively: network, meet people, find out who's hiring. Once you have a full-time job, you can buy your own drinks.


• Tip from Brenda: a great way to get promoted at a game company is to find a stressed-out lead and ask what you can do to help. This is also a great way to get noticed as a student if you find a stressed-out professor who used to work in industry.

I also found some interesting advice specific to student game projects, courtesy of the games that won this year's IGF Student Showcase:

• For student projects, keeping the scope small and focused should be your number one priority. Nearly all of the student IGF winners this year only showcase a single game mechanic; then they build the entire game to support it. If your proposed game is large enough that it requires the inclusion of mini-games, it is too big for you to finish. If your proposed student project is a mini-game, you're probably on the right track.


• You can make a better student project if you learn and use good tools. This year's IGF students used a wide variety of tools: Anim8or, Photoshop, Cubase LE, XNA, Adventure Game Studio, Aftereffects, Source, Visual Studio, 3DSMax, SVN, MS Project, Excel, Panda 3D, Python... you name it. These can save huge amounts of time. Learn at least a few of them early on in your college career, so you'll have the time to use them on projects during your final year.


• Rapid prototyping with iteration is your best friend. If you can't have your student game project up and running in some form in a week or two, it's too big. Use a steady stream of testers who have never played your game before, and keep modifying to make the new-player experience as solid as possible.


• If at all possible, work on team projects rather than working alone. The game industry really cares about whether you can fit in to a team, and if you can only create projects on your own it will be much more difficult for you to get hired... no matter how brilliant your projects are.


• Enter your project in lots of competitions. Many students reported that the pressure of competition forced them to keep their scope small and their quality high while still making regular progress.


• When coming up with a name for your game, make it something pronouncable. It just annoys people when they have to say "Narbacular" or "Poesysteme" or "Synaestheste"...


• Make your game extensible. If your game ends up being really great, you may want to continue working on it after graduation to make it into a full, commercial game.


• If working on a project for a class, do as much preproduction work as possible before the semester begins. If your team enters the class already knowing what the concept is, you'll have that much more time for iteration.


• Some game concepts are not particularly challenging for programmers or artists. If you are working on one of those teams, you may be tempted to make things more complicated just so you can show off your skills. Don't do this. Do what's best for the game, not what's best for the developers.


• The best Producer for a student project is someone who's really good at details. When the game has a thousand small tasks (and reasons why half of them need to be there), it's great to have someone on your team who can keep track of all this stuff, and it's even better if that person is the producer.


• The best game designers for student projects aren't the ones with the best game design skills, but the best people skills. Game designers are going to be telling everyone else on the team what to do, and being able to order your peers around in a way that encourages buy-in and good feedback and communication is absolutely critical if you want stuff to get done. If your "best designer" is a programmer, he or she can still contribute to the design (and will happily do so).


• If you finish your student project and it's something you're happy with, consider incorporating as an LLC. It's cheap, it's easy, and it means you all now have a shipped title at a professional game studio.

The Progression of a Student Developer

Most students start in the same place: "I love playing games and I think making them would be really cool, but I don't know anything about the industry and I don't know where to begin if I wanted to do it myself." (Let's call this Experience Level 0.)

Students level up the first time when they learn the reason why they didn't know where to start: games are made by teams of specialists these days, and knowing programming and art and design and production and audio is just too much for a single person unless the scope of the game is really small. This is around the time they realize there is a community of game developers, and that there are resources like Gamasutra and GDC. At this level, they can try to make their own game, or team up with a few other students on a small project.

The second time students level up is when they actually attend their first GDC. There is a shift in thinking, from "game developers are these legendary people who make these amazing games and I could never hope to be a part of that" to "wow, these developers are real people, just like me." And then the students are suddenly able to talk to professional developers without making fools of themselves. (I do my best to prepare my students for this before it happens, to varying degrees of success.)

The final level-up happens when students have been through a complete development cycle on a game (either at a professional studio as an intern, or on their own student project). At this point they can talk with professional developers at an equal level, contributing to conversations with their own experiences. And then they are truly ready for industry.

As you might expect, one of the joys of teaching is seeing this progression (which, naturally, sometimes doesn't happen at all... and sometimes happens out of order).

Teaching on the Fly

I suppose it had to happen eventually, and the miracle is that I've been teaching for a year and a half before this happened to me. I'd be horrified if this had happened, say, a couple weeks after I'd originally started.

I'm talking about forgetting my class notes, not realizing it until five minutes before class starts, and having to run a two-hour lecture entirely from memory.

I'm one of those people who likes to plan stuff in advance. I'm more comfortable when speaking to a crowd if I've already written down and rehearsed what I'm about to say. I'm much more comfortable if I have my notes in front of me, in case I get lost (which I often do). From talking with other teachers, this is something of a rite of passage. (Some day, perhaps, I'll take this to the next level: showing up for class without having prepared a lecture in advance at all, and just saying whatever occurs to me at the time. But that day will not come any time soon if I can help it -- I was never all that great at improv.)

I realize that not all teachers are like this. Some don't do any planning in advance at any rate, so this is the norm. Others rehearse things so many times that they've got it memorized, so they don't need any notes. I'm somewhere between the extremes, and for me it was really scary.

The thing is, I survived. And I'm not even sure my students noticed. I suppose it helps that I've taught this particular class three times already, so I had a pretty good idea of the general topics. After I got home, I reviewed my notes and found that I covered most of the major points, and I mentioned the rest in the following class as an aside. So, no harm done.

But I'm not going to try it again any time soon, all the same.

GDC: Breaking In to Academia notes

This year at GDC, I hosted a roundtable entitled Breaking In to Academia. Brenda has been kind enough to post notes of the session, for anyone in the industry who might be curious what it's like to teach (or anyone in academia who would like some additional insight on the mindset of those in industry who would like to teach).

Crediting Standards on Student Projects

Getting proper credit in a game matters. As a professional developer, a large part of your ability to get hired is the list of projects you've previously worked on; if you aren't in the credits, it becomes much harder for future employers to verify.

Many professional developers don't realize how important it is (until they get burned by it). This makes it rather important to at least mention it briefly to game development students, so that they're aware before getting burned.

As of just recently, the IGDA Credit Standards Committee released a beta version of a standards document. Several very large teams are putting this through its paces on real projects, to see where the problems are. (The document itself can be found at the link above.)

For those of you teaching a class in game development, especially one such as a "capstone" that involves students working on teams to make working games, consider making your students comply with the credit standards. If you have a student working in the role of Producer (or else Project Lead), you can make that an assignment for the student to ensure proper crediting of everyone on the team.

If you do so, be sure to let the Credit Standards Committee know how it goes. I don't think they've got anyone testing out the standards on a small-team project yet, and it'd be nice to know if the standards scale down properly.

I've been quoted

Brenda writes an interesting piece for The Escapist on how game design is frighteningly similar to game play. A quote from me appears in the sidebar on page 2. I assume this doesn't count as an academic publication, but thankfully I'm not in a "publish or perish" environment.

Note to schools: Remove obstacles!

One thing that came across loud and clear to me at GDC is that there are many developers who would like to teach, but they don't know where to begin... and there are many schools who would like to hire people with industry experience to teach their classes, but every time they try to recruit they don't get any applicants. This is strange. What's going on here?

The solution to this mystery lies in the obstacles that prevent developers from applying. Here are some examples:

• Accreditation boards require that all professors must have a terminal degree.
• All applications must go through Human Resources. HR writes the job description and also screens applicants, even though they don't know the first thing about game development.
• The school is located in a place where there are no professional game developers anywhere nearby.

There are plenty of schools that have found ways to remove these obstacles, and they are the ones who have no problems filling faculty positions. There are other schools that throw up their hands, assuming that these are just forces of nature that can't be worked around, and then they complain that they can't find anyone qualified to teach their classes. If you are at a school where you just can't seem to attract experienced people to teach there, I'm here to tell you that these problems are not insurmoutable if you are sufficiently dedicated. Here are some examples:

Accreditation:

• Talk to your accreditation board to see if any exceptions can be made. Game development (especially game design) is a field where terminal degrees don't exist, so finding someone who is both educated and knows what they're talking about is effectively impossible. See if it's possible to substitute experience for formal education in specific cases.
• Some accreditation requirements don't force all faculty to hold terminal degrees, just a certain percentage. Hire industry people into departments that are already above the threshold.
• Accreditation requirements may not apply to certain kinds of positions, like adjuncts or visiting faculty. (I ran into one developer who has happily been a full-time "visiting" professor for the last four years.)
• Some schools allow provisional hires, where they bring in someone with industry experience to teach now, and it is expected that the person will work on their own time to earn an advanced degree within a certain amount of time. Plenty of industry people are more than willing to do this, we just aren't willing to leave the industry to become a full-time grad student first.
• I ran into one school that offers online classes, claiming it must meet accreditation requirements in all fifty states. I wondered, if there are only a few states with super-strict requirements, why not hire an industry prof and only offer their classes in (say) 47 states?

Human Resources:

• I remember a certain job posting where a school was trying to hire an art/animation faculty under the job title of game design. I talked with some people at that school at GDC, who expressed equal frustration at the whole thing. Apparently they had not been consulted to write the job description, and of course anyone from industry contacting the school to inquire about the position would be talking to HR and not them. This is a communication breakdown that could be fixed in a few ways...
• Open a dialogue with HR to make sure the job postings say what you want them to say.
• Put contact information in the job posting for someone who actually knows what they're talking about, in case anyone from industry seeks additional information. HR is not capable of answering technical questions about game development, and they will probably not forward these things on in a timely manner, so prevent them from getting these questions in the first place.
• Don't just post a job opening on your school's website and think you're done, because the number of game developers that regularly search there is pretty much zero. Make postings on places game developers are likely to read, such as Gamasutra and Game_Edu. Attend GDC and go to events and sessions where you're likely to find interested candidates. Spread the word, because it isn't going to spread itself.

Schools located somewhere other than California:

• First, are you absolutely sure there's no game developers in your area? I had always assumed I was the only professional game developer in the entire state of Ohio, until I received email from a casual game studio just a few miles from where I live. And then another email from a publisher about as far away. And then I met someone from EA at a local IGDA meeting. And then I encountered a local game audio professional on the plane back from GDC, who then told me about another game studio that I've yet to meet. Columbus may not have the developer population of San Francisco, but it's certainly not vacant. Of course, it took a bit of digging (and a bit of luck) for me to find this out. Maybe you're in the same situation and you just don't know it.
• Does your school offer online courses? If a professor can teach from their living room, you can open your search to the entire world; it doesn't matter where your physical campus is, if all your game courses are online.
• Do you have teleconferencing? I met a few industry professionals who would be happy to give a guest lecture to my class, as long as they don't have to travel.
• Develop and maintain ties to the industry. Conferences like GDC are ideal for this. I even met one school that hired a full-time employee whose entire job is to research and contact game development companies. How do these ties help you? For one thing, it makes it much easier to have guest speakers from industry; even if no one lives in (say) Nebraska, maybe a few people have family there, and they'd be happy to drop by for an hour the next time they're visiting. Maybe someone at that company knows someone else who happens to live in your area, and a couple of phone calls to a friend of a friend gets your position filled (it's a small industry). And even if you don't have any faculty with industry experience, you can at least run your course content and curriculum through an industry advisory board, and get additional feedback from any of your students who happen to land summer internships.

In short: stop whining and start recruiting!

Welcome, newcomers

It seems I met about a billion people this year at GDC, and I'm sure at least a few of you have found this blog by following the URL on my business card (if only out of morbid curiosity).

Some of the more popular areas of this blog (based on emails I've received):

• My proposed game design curriculum
• Reviews for textbooks on game design
• A series of articles on the differences between industry and academia (I'll retrofit with a "Culture Shock" tag at some later point)
• A two-part description of an interactive final exam
• A list of analogies to explain the field of game design
• A two-part article on what all teachers should know about game design

Or, just start from the beginning and read forward, and I apologize in advance if doing so makes your productivity drop for a few days.

Think student games don't matter? Think again.

The Game Developers Choice Awards is an annual show where developers themselves honor the best games of the previous year (much like the Academy Awards for film).

At the GDCA, the winner for Game of the Year was Portal, beating out Bioshock, Call of Duty 4, Rock Band and Super Mario Galaxy. Additionally, Portal received several other awards (Innovation and Game Design) and was tied with Bioshock for most nominations overall.

In case the implications of this are not clear, let me say it straight: A seven-person student team made a game that, in the opinion of the professional industry, is better than four other games with teams of 100+ experienced industry professionals each.

The Independent Games Festival went much the same, with four-person student project World of Goo walking away with the grand prize (along with the other two things was nominated for).

Okay, so these aren't technically "students" anymore since they all graduated last year. And yes, the people involved in these games are absolutely brilliant, and I wouldn't expect this to be achievable by just anyone. But at the same time, I think it says something that small teams lacking industry experience are capable of this kind of success. If you are working on a student project, take it seriously...

At GDC, students are Pikmin

If you've never played the game, Pikmin are these strange little creatures that follow you around and follow your orders. Among game professors here at GDC, to Pikmin is now a verb, referring to the act of a student following the professor around everywhere in the hopes of being introduced to some cool industry people (instead of just networking and finding people themselves). My thanks to Brenda for introducing me to this amusing word.

There is an up side to this. The students that respect you will do pretty much anything you tell them. I could tell my students to form a human pyramid, and they'd probably do it. If I were a little more playful than I actually am, I could probably have a lot of fun with this.

In reality, it means that I can coordinate with students. This year there are some time slots (I'm looking at you, Wed 2:30-3:30 and Fri 4:00-5:00) where they've got five or six really great sessions going on simultaneously. With seven students at the ready, I can coordinate things so that each session is covered by someone who takes notes, and we can all type them up and send them to each other later. This frees me up to go to the more obscure sessions, secure in knowing that I've got some spare eyes in the high-profile ones. It also frees up the students: if all of the sessions are taken care of, any excess students can hit the Career Pavillion at a time when they'll be practically the only ones there, which greatly helps their chances of being remembered.

In an ideal world, I'll also make sure the students are not just networking for themselves but for each other. As an example, suppose one of my students is a brilliant game designer, and another student is looking to be an environmental artist. If the designer finds a company looking for environment artists, instead of just saying "sorry, not interested" they can add "...but, I know someone who would be perfect for this, can I give them your card?"

Is this what leveling up feels like?

Last night was the first time at GDC when someone walked up to me, called me by name, was clearly happy to see me again... and I absolutely didn't recognize this person at all. So, I'm apparently part of a community that's larger than my close circle of personal friends, and they know who I am. It's a bit scary.

GDC Checklist

I've answered the same question ("This is my first year at GDC, what do I need to know?") several times lately, both for students and fellow educators, so it seemed worthwhile to post it here.

This is my checklist of stuff to bring:

• Business cards, at least 250 of them (you had one out to pretty much everyone you meet, which is a lot of people in the space of a few days; better to have too many than to run out). In one of the classes I teach, I require students to purchase their own business cards on the pretense of using them for a game design exercise, but the real reason is so they'll have them on hand when they go to GDC.
• Clothes. Casual is fine, most developers will be. If you're allergic to denim or something, business casual is acceptable. Avoid either extreme (suit and tie makes you stand out, and not always in a good way; ditto ripped jeans and a t-shirt with M-rated content).
• Resumes, if you're looking for work. Do not hand these out to anyone, or offer them, or even mention that you have them; it's considered rude. But if (and only if) someone asks you, it's good to be prepared. Likewise, if you're entering a profession that expects a portfolio, making a few CDs to hand out with your resume can't hurt (but if you're on a budget, at least put it on your own thumbdrive and take it with you). If you're a game audio person, it's easier: put your portfolio on your iPod.
• Physical notebook (you know, with actual paper made from trees) and plenty of things to write with. It's easier to take notes during sessions if you don't have to jockey for outlet positioning, and if someone asks you for some information that they can take with them you can write it down on paper and give it to them. You can't do this with a laptop.
• Cell phone. If you meet someone that you want to meet up with again later in the week, the only elegant way to do this is to swap cell numbers. If you don't own one, consider renting one for the week, or buying one of those pre-paid ones (and write your phone number down somewhere easy to access, like on the phone itself, so you'll know it when asked). Oh, and make sure you turn off your phone before entering any session. In two years I don't think I've ever made it through a session without someone's phone embarassing them; don't let that person be you.
• Laptop is optional (unless you're carrying your portfolio on it). Take an extra battery if you have one, just in case you can't sit near an outlet, and turn off the sound.
• Sleep. Okay, it's not something you pack in your luggage, but be sure to get plenty before you go. You can count on having next to no sleep as long as you're there.

Everything I Need to Know about Teaching Game Design, I Learned in Kindergarten

In a Gamasutra article, Nick Burton of Rare urges developers to take an active role in shaping game education. I feel Nick's frustration; in spite of the great long-term rewards of getting involved with the local colleges and universities, very few game developers take the time to do so.

It reminds me of a story I read when I was young. It goes something like this:

The educator goes among the industry and asks, "who would like to help me craft a curriculum to take talented and eager high-school students and teach them how to make games?"

And Loosey Goosey says "not I, for I have to do the schedules for next milestone."

So the educator does it herself, and then returns to ask, "who would like to help me find talented high-school students so that I may educate them in our game development program?"

And Henny Penny says "not I, for I'm busy making textures for our models."

So the educator does it herself, and then returns to ask, "who would like to teach classes to these students, to show them how to make games?"

And Foxy Loxy says "not I, for I have to write some concept docs for this publisher RFP."

So the educator does it herself, and then returns to ask, "who would like to mentor these students, to show them what it's like in the industry and talk to them about breaking in?"

And Piggy Wiggy says "not I, for I've got to finish this code for alpha."

So the educator does it herself, and finally returns to ask, "who would like to hire these brilliant students who know how to make games?"

And everyone says "I do, send them to our HR department right away!"

Okay, maybe the original story was about baking a cake or something, but you get the idea.

Culture Shock: Professional Humility

If you're a game designer for long enough, eventually you'll work on a game that ends up just not being all that fun. (No matter how great you are, everyone has their mediocre projects.)

As a teacher, there are analogous cases. Eventually you'll meet a student who you know is capable of grasping the course material, and they genuinely try hard, but for whatever reason they just don't seem to get it. Or, eventually you'll create an exam or assign a homework and half the class completely bombs it.

In either case, there are two types of people. There are the ones that look at the tiny amount of positive feedback (the one glowing game review, the one student who gets everything perfect) and decides that if this tiny minority understands what they were trying to do, then everyone could, and it's just that the others aren't trying hard enough. It's certainly not their fault if these people just don't put in the effort to see their obvious brilliance. They feel better, but they don't actually get any better.

Then there are the ones who learn humility. Yes, others may have made mistakes along the way, but something in your own work went wrong as well -- enough that it was unable to save everything else. By figuring out what you did wrong, you become stronger.

In games, this is actually pretty easy. Reviewers will quite happily lay your game on the table and dissect each of its flaws, for all to see. Post-mortems, likewise, show us that most development teams are painfully aware of their issues; if you as a designer have made mistakes, even if you don't know what they are, someone else on your project team certainly does.

In teaching, it's much harder. There is no "project team" -- in fact, it's rare to have even a single other education professional observe your work and offer any constructive feedback at all. Students can help you identify weak points, but they can't tell you what to do about them. Teaching, then, forces one to go beyond humility into the realm of self-reflection in a way that game development does not.