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.

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.

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.

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.

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.

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

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.

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

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.

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.

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!

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.

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

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?"

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.

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.

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.

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.

Last year, I had several occasions where a student would come up to me, nearly freaking out: "OMG, I have an interview with a game company! What do I do to not screw this up?" (Yes, they actually pronounce "oh-em-gee" when they're sufficiently panicked.)


What follows, then, is my own advice and observations on the interview process. It should be primarily of interest to students, or to educators who get these kinds of questions from their students (especially educators who have not been through a game industry interview before). It may also be of some use to industry people looking to conduct an interview; usually, you don't get any training in how to interview a candidate, so maybe you'll get some ideas about how to make the most of your time.

First, let's get some common questions out of the way.

What do I wear to the interview? Dress policy varies from company to company. Most are casual, but that doesn't mean that ripped jeans and a t-shirt is appropriate everywhere. Best thing to do is ask, when the company calls you up to offer you the interview in the first place: "By the way, I know this is different at each company. How do you prefer candidates to dress for interviews?" If you miss your chance then, you shouldn't lose any points for calling back ahead of time; if you have an interview, you've already been given the phone number of HR, if nothing else. If you left this until the last minute and you have to make a snap judgment, business casual is a decent bet... or, go for a business suit on the theory that you can't be overdressed.

Personally, I've always worn a suit to the interview, with the understanding that I'll never be seen wearing it again. In one interview, someone who shall go unnamed hired me, but told me that if I was ever seen wearing a suit again I'd be fired.

What do I bring to the interview? First, bring anything you're asked to. If you're hiring for a programmer position and they tell you to bring some code samples to your interview, by all means do what you're told. That's the easy part.

Bring a copy of everything you've sent to them, including resume, cover letter and any other samples or portfolio materials. If the person sitting across from you starts reading directly from your resume and asks you questions line-by-line, you can follow along.

Bring a notebook and something to write with. This avoids the embarassment of having to ask for a pen if you're asked to sign something, and you should be taking notes as you go (see below) -- you can bet they'll be taking notes on you.

What questions will I be asked, and how do I answer them? Ah, this is the heart of the matter, and the reason why I call this an interview "game." Because it is a game. For the company, the goal is to find the best candidate. For you, the goal is to get a job offer, and to figure out if this is an offer you'd accept. It's a turn-based game, where the interviewer asks a question and then you answer it. Here's the secret, though: the game is stacked in favor of the interviewee!

Here's why. For every question asked, the interviewer is giving away information about the company: its values, its culture and the kinds of things it's looking for in a candidate. And they speak first, so you always have the information advantage. You win the game by deducing, in realtime, what each question really means. Then you give an answer that also works to your advantage, and you're ahead with each question and each answer.

Here's some examples of interview questions and what they really mean. You'll notice that I don't give any answers here. That's because there is no "right" answer; each answer you give is an expression of who you are. If I gave you answers, you'd be expressing who I am, but I'm not the one in that interview room. Also keep in mind that these are just examples. The trick here isn't to memorize these questions, it's to get used to the process of understanding what a question really means so that you're giving the interviewer the information they're looking for! As you can see, most questions are not 100% straightforward:

Question: How do you feel about working overtime?
Meaning: You will be working overtime. Lots and lots of overtime. Do you think you'll enjoy this job so much that you won't mind when it takes control of your entire life?
What they really want to know: Are you passionate about this line of work, or are you looking for some cushy 40-hour-a-week desk job?

Question: What's your biggest weakness? (Variant: If I hire you, what will be my greatest regret after six months of working with you?)
Meaning: We know that no one's perfect, and that's okay. We just want to know that you're willing to become aware of your own imperfections, and that you can improve them or work around them.
What they really want to know: Are you capable of reflecting on your past experiences and finding your own faults? Also, can you take criticism well (you probably can if you spend time criticizing yourself)?
Worst possible answers: "My biggest weakness is that I'm totally incompetent and will single-handedly run your company into the ground." (Honest, perhaps, but doesn't tell them what they want to know.) "My biggest weakness is that I work too hard." (Total BS and we know it, and implies that you're unwilling to give yourself serious critique.)


There are technical questions that vary by field, that also sound very strange unless you realize what it is they're really looking for. Some examples:


Design question: Pretend you're an architect. Design me a house.
Meaning: How do you approach a totally open-ended project?
Worst possible answers: Jump in and start drawing floorplans (you're willing to design a game without doing any research ahead of time). Complain that you're not an architect and it's an unfair question (you're unwilling to learn something new, or stray outside your comfort zone, and you don't understand enough of game design to see the parallels with architecture).

QA question: Explain how to use a telephone. (Variant: explain to a space alien who's never seen one.)
Meaning: How do you describe the steps to reproduce a simple bug to someone who's never seen it?
Worst possible answers: Complain that everyone already knows how to use one, so the question is pointless (you don't understand enough about QA to see the parallel between explaining something obvious and explaining "obvious" repro steps for a bug). Be condescending or patronizing in your explanation (implies you'll treat programmers the same way if they can't follow your written repro steps).

Programming question: Explain the concept of class inheritance in terms that my technophobic grandmother could understand.

Meaning: Communication skills are important for programmers, particularly being able to explain technical ideas to nontechnical people (such as designers, artists and producers).
Worst possible answers: Give an explanation right out of your Computer Science textbook (you only know how to communicate with other programmers). Say that you don't know what class inheritance is (you were sleeping through your core curriculum). Say that it's impossible to explain such a technical thing to someone who has no programming experience, so it's an unfair question (not only can't you communicate with nontechnical people, but you're not even going to try).

Having now worked in both a four-year university and a two-year community college, my first impressions of the students are not what the stereotypes would suggest.

The community college, ironically, has less of a sense of community. Most students taking my classes are taking them alone, not with a large group of friends. I think this is partly because of the lack of dorms and other 24/7 student activity on campus, and partly because a large percentage of students are only taking classes part-time.

The community college is far more diverse. Between my two classes I have people from five or six different countries, with an age range that varies from "working professionals with 20 years experience" down to "high-school students taking advanced classes that their school doesn't offer". In a four-year school you're seeing mostly college-age students, with a disproportionate number of locals (or at least, that's what I've seen). I must say, I've grown used to being the oldest person in my classes, and it feels strange when that's not the case anymore.

Community college students seem, generally, to be more prepared before taking a class. More than half of my game industry students knew who Shigeru Miyamoto is (one even recognized Gunpei Yokoi's name), and most had heard common industry terms like AAA and ROI and LOD. In my four-year classrooms, it's usually more in the 10-20% range. If I had to guess, I'd say this is because community college students tend to be older (and therefore more experienced) and also more self-directed. Not every student is a superstar, but there seem to be a greater proportion that are above the curve. (If you were in my classes last year and you're reading this, I'm obviously not talking about you as being anything other than spectacular, of course.)

Most of my community college students are not planning on just getting a two-year degree and stopping. The majority either already have a Bachelor's (or higher) and are branching out into a new field, or they're just getting their general education credits out of the way (where the tuition is cheap) and then they'll transfer to a four-year institution.

I was expecting to have to deal with a lower caliber of student at a community college, but I've been pleasantly surprised.