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.

The Interview Game

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

Two-Year and Four-Year Students

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.

Culture Shock: Parking Policies

It didn't occur to me until recently that different institutions have wildly different ways to treat faculty when it comes to parking lots, of all things.

In my experience, parking for a normal job is pretty uneventful. Some buildings have private lots and you get a sticker or an assigned space or something, while smaller companies might need you to park on the street nearby. Either way, the company is paying you to come to work, so it's in their best interests to make it easy for you to actually arrive. Also, most companies aren't so huge and bureaucratic that Parking Enforcement is its own private department... especially in game development.

For colleges and universities, by contrast, parking is a huge problem. When you've got thousands of people commuting every day, you need some way to ensure that parking spaces are allotted fairly. Unfortunately, the parking office is usually not part of Human Resources, which means that a lot of places inadvertently send some pretty harsh messages. Here's three policies at three different institutions that I've observed (feel free to add your own in the comments):

• Separate parking lots. If you're a student and pay a fee, you get a sticker for the student lots. If you're faculty, you get to park in the faculty lots for free, but you're not allowed in the student ones. There are also some "seniority lots" at prime locations on campus; when someone with a space dies or retires, whoever's most senior on faculty gets the space. What this says: Students and faculty are different people, so we're putting up artificial walls to make sure they don't accidentally get to know each other. Also, no matter how great a teacher or researcher you are, what really matters is that you stay here for a long time.
• Separate parking spaces within many lots. Each lot has some student and some faculty spaces, and if you pay a fee you get a sticker that gets you in to the right kinds of spaces in each lot. You have to pay even if you're faculty. What this says: This institution doesn't care who you are. You are nothing to us, a mere insect. If you don't like it here, there's a line of people out the door waiting to replace you, so put up and shut up.
• Common lots. There are a variety of parking lots and every space is exactly the same. Students pay for a parking pass, faculty get one for free, but everyone is fighting for the same spaces (and they're a bit scarce at certain times during the day). I haven't had a space stolen in front of me by one of my own students before, but I'm sure it happens occasionally. What this says: We're all in this together... or, every man for himself... depending on how you look at it.

Slowing Down

In my Analysis class today, I was asked to speak a little more slowly than I normally do.

To my surprise, consciously slowing down my speaking made the entire experience an order of magnitude better. My brain had spare cycles to actually consider what I was saying and how I was saying it. I never spoke so fast as to get ahead of my own thoughts (which then ends in a characteristic uncomfortable pause). My speaking was clear, and the students were all paying close attention. I think it made me easier to understand. It was also a lot easier on my vocal chords. And it made it easier for students to ask questions or add to the discussion because there were more pauses. I was afraid that speaking too slowly would make me sound stupid, but really it just made me sound confident.

I'll probably continue to speak slower in every class from now on, not just this one.

What really surprised me was that I never really thought before about how fast I speak. When I get excited about a topic (which is pretty much always, if I'm talking about game development) I talk faster; this is true of most people I know. And when I'm talking with other developers, we can get away with this because we're already familiar with all the basic concepts and we've done this for so long, that our minds work as fast as our mouths. With students who are just getting past the concept of "oh, you mean I can't just come up with an idea for a game and sell it?"... well, maybe not so much.

So, I may have accidentally stumbled onto a little secret that makes it easier to teach. I bet this also works well for presentations. I also bet it's something that's obvious to anyone who's been doing this for any length of time.

System Analysis

What do game designers do? They make the blueprints, termed design documents, that describe the nature of the software that the rest of the team will build. Writing and maintaining this documentation is itself a full-time job in most large projects. It's necessary; a game without a designer is likely to be difficult to use and not much fun.

These same tasks are useful for any large software project, not just games. So where are all the "game designers" in the greater software industry?

These people do exist, but it's hard to find them. Not all companies have them; some companies still operate under the antiquated assumption that anyone who can program in Java is fully qualified to design the software architecture. The companies that do have "designers" call them many different names. Microsoft calls them program managers. Other places call them system analysts. Some companies with highly technical systems require their "designers" to write some code, so they call them programmer/analysts. Still other places hire from outside, and they're simply called consultants. For my purposes, I think system analyst is the most descriptive, so I'll conveniently go with that term.

And so it comes to pass that I find myself teaching a course called Systems Analysis. While it has nothing overtly to do with the game industry, the topics overlap with game design a great deal. We talk about the iterative method of development, rapid prototyping, user interfaces, focus groups and research into the subject area of the software. It's the same thing, except with all the fun apparently sucked out of it.

And this, ironically, is why I'm so excited about teaching the class. It lets me put into practice everything that I've been preaching about using game-like techniques to teach a non-game class, and the evils of multiple choice. If I can take this class and make it fun, it validates everything I've been doing as a game-designer-turned-teacher. And if not... well, I can always go back to my game classes with their inherently fun content.

IGF Student Showcase Winners Announced

A list (with most games available for download) is here. If you're going to GDC, be sure to stop by the IGF booth and play for yourself anything that you can't play now.


Students wishing to win the IGF some day should take a good, hard look. This is the bar you need to meet or exceed as a student project.


Note that you do not need to be brilliant at all aspects of game development. Crayon Physics and Poesysteme have rudimentary graphics at best. The Misadventures of P.B.Winterbottom was done using some very simple scripting in Flash. Mayhem Intergalactic isn't particularly original game design (it's basically a "mod" of the board game RISK).


I do not point this out to put down this year's winners. All twelve are outstanding games (and I judged some outstanding games that did not make the list), especially considering that they are student projects. Rather, I say this as a word of encouragement to those students who are intimidated. Yes, the bar is high. But if you can truly excel in one or two areas of game development, even if you are lacking in the others, you've got a shot. Design and create the kind of game that really shows off your strengths, rather than complaining about your weaknesses.

What Teachers Need to Know about Game Design (Part 2 of 2)

Last time, I talked about why games are fun, and why classes aren't. How can we apply the lessons learned from game design to make classes more exciting and engaging? (Presumably you already see the benefit of this, but just to spell it out for the rest of you: if students pay more attention in class, they'll learn more.)


Three ways to use games in class:

• Play games as a classroom activity. This is obvious and it's effective, but it has several limitations. Games are great at teaching concepts, especially system models, processes and cause-and-effect relationships. They're terrible at teaching content, making them unsuitable for content-heavy classes. Also, most games are made for 1 to 4 players, and don't scale well to a 25-student class. Lastly, these require a good deal of "game literacy" on the part of the teacher, making it not suitable for all teachers; most classroom games are some crude form of Jeopardy!, only because the teachers lack the game experience to go beyond.


• Discuss the games that students have played in relation to the course content. This is easy: ask "has anyone played a game that has ____?" and then compare and contrast between the content in the game versus that in the class. This also has limitations. Not all students are avid gamers, so the comparisons will only be useful to a subset of the class. It also requires game literacy on the part of the teacher, to provide examples when the students can't think of any.


• Modify your teaching style to be more game-like. Add elements to your class that make them just as engaging and interesting as a game (for the same reasons). This is the hardest way to use games, but by far the most rewarding and least limited.

Game-Like Teaching:

• Games are interactive, not passive. It is the interesting player decisions that make the game. Include interesting decisions in class. This includes classroom discussions, a choice of topics or homework problems (with varying tradeoffs so that the more interesting ones are also harder or contain other "fun" rewards), and asking the class questions (either to individuals or by having everyone "vote").


• Applying flow theory (making the content at an appropriate level of challenge) is not obvious, because different students have different skill levels. One way to do this is to include multiple layers of depth to your topics; explain first what's going on conceptually at a fundamental level, then go into the details every student needs, and then offer additional insights for the advanced students. Another great place to do this is homeworks and exams, offering a variety of basic, intermediate and advanced problems so that all students can find their own level of challenge.


• Use as many different kinds of fun as you can think of in your classes...


• Exploration fun is difficult when you're stuck in a classroom, but field trips (especially open-ended ones where students are free to explore the area rather than being herded like cattle) can tap into this. If you have computers in the classroom, you can ask students to search the Web for information relating to a topic, providing a kind of exploration as they navigate from one page to another.


• Social fun is easy: group assignments, class discussions, and other collaborative exercises.


• Collection fun is something that happens mostly at the K-6 level, where teachers hand out gold stars and stickers. If you're teaching at a more advanced educational level, you may have to be inventive.


• Physical fun: include various physical objects that can be passed around the room in your discussions. Include "eye candy" -- neat-looking photos or illustrations that you can show around. Try including some music or other interesting sounds if you can tie them to class topics. Get the senses involved! I once had a physics teacher who would bring "props" to just about every class, such as throwing around a super-bouncy-ball when talking about elastic collisions; I know another professor who would make the entire class get up and stretch when she noticed students nodding off.


• Puzzle solving fun: ask open-ended questions, especially those that students really have to think about before answering. Group discussions and case studies fit this nicely. Some classes have content that is inherently a kind of logic puzzle (especially in the maths and sciences). In these cases, it helps to approach these as puzzles or mysteries, rather than as problems or exercises. Who ever heard of having a "problem" that was fun? What percentage of your students enjoy "exercise" as a recreational activity? Why do we use such not fun words to describe a fun process?


• Character advancement fun: is automatic in any class that builds on its own content over time (the kinds of classes where the final doesn't have to be "cumulative" because you need all the previous stuff to solve the latest questions anyway). At the beginning of the class, try showing the skills and concepts as a "tech tree" -- the same as you'd see in World of Warcraft or Diablo 2 or Civilization.


• Competition fun: here's where we see the old quiz-show standby. Formal debates can trigger this kind of fun too, as can informal debates that emerge spontaneously during class discussions on controversial topics.

As a parting shot, notice that most successful games are made with the players first in mind... not the creators, and not the content. Approach your classes the same way: design your classes around the students first, not the content and certainly not the teacher!

What Teachers Need to Know about Game Design (Part 1 of 2)

This is a summary of my talk at Origins this year. (Okay, I'm a bit late.) This information is targeted at teachers, although students may find it interesting as well because it explains why you'd rather play World of Warcraft than do your homework.

Games are fun. Most classes are not. You may notice students sitting at the back of your lecture hall playing with their DS rather than paying attention. It's worth asking the question: what does that silly little video game have that the lecturer doesn't? After all, it's just a game, but this class is important. Why shouldn't the lecture be getting students' undivided attention? And more importantly -- is there anything we can do as educators to change that?

To answer these questions, we first start by asking what makes games fun (and what makes classes less fun).

What makes games fun?

• Well, if we knew that, we wouldn't be a "hit-driven" industry (a nice way of saying that 90% of commercial games lose money). Still, the game development community has a better understanding of this than the teaching community, and there are a few useful theories that most game designers are familiar with. What follows is a small sample of a much greater body of work.
• Csikszentmihalyi's theory of "flow": you get deeply engaged in a task (any task, including "work") when it provides a challenge in line with your skills. Too hard and it's frustrating, too easy and it's boring... but if it's just right, it's magic.
• Corollary: as you perform a task more, your skills improve. If the task stays the same, you will eventually become bored. The tasks that keep you in the flow longer are those that increase in difficulty.
• Raph Koster's Theory of Fun: Games are fun because they're really good at keeping the player in the flow. Also, flow is fun because you're learning. (You may or may not be learning useful things from playing games, but you are learning something, and the brain finds that pleasurable.)
• Noah Falstein's Natural Funativity: Learning is probably fun because it's evolutionarily beneficial. The things that helped our ancestors when they lived in caves and trees are the same kinds of things that we find "fun" today.
• LeBlanc et al's MDA Framework: The word "fun" is not terribly useful because it isn't descriptive, and doesn't suggest how you create it. There are actually many kinds of fun: exploration, physical sensation, social experience, competition, advancement, collection, puzzle solving, and many others. These are all present to greater or lesser degrees in games; we're talking about a continuum, not a binary either/or composition of fun.
• Note that all of these kinds of fun can be traced back to hunter/gatherer survival skills. Social skills are important because we can work together to hunt animals that are too large or powerful for a single one of us. Exploration is important so that we can have larger areas of territory to find food in. Collection is simply the "gatherer" half of hunter/gatherer.

If learning is the source of fun, then, it actually seems strange that classroom lectures aren't inherently engaging. I believe the reason for the disconnect is that lectures are so far removed from the kinds of "learning" that ancient humans had to do for survival, that it does not trigger our play-instinct. Our pedagogy has outpaced our biological evolution.

Now you know the basics of what fun is and where it comes from. Next time I'll talk about how to apply this knowledge directly to the classroom. In the mean time, think about it yourself...

GDC: When it rains, it pours

From zero speaking engagements for the past two years, to two of them this year. I'm also on a panel ("Industry Veterans as Educators") at the Education SIG Summit.

I swear, leaving the industry was the best thing that ever happened to my game development career. Oh, the irony.

Pittsburgh Game Jam games available for download

As I've mentioned a couple times before, I participated in the 2007 Pittsburgh Game Jam. The games themselves are posted here.

In spite of the fact that the only constraints were technological (design for the XO platform, using Python and Pygame), and there was not a single mention of experimental gameplay or innovation in game design, a surprising number of games were highly experimental in nature (though sad to say, not mine). What follows is a rundown of, in my opinion, the most important games of the Jam and why students, teachers and professional developers alike should pay attention.

XO Maze (by Team Thailand), the winner of the jam, was a four-player cooperative maze game (if you've never heard of the "maze game" genre, think Pac-Man) with fog of war. Design lessons: Whenever a new innovation in gameplay is added to a genre (like fog of war in RTS games), someone should revisit all older games of all genres and see if the new mechanic will work with old games. In this case, it works beautifully. Another interesting thing: the developers originally wanted network play but it was broken, so they "settled" for having four-player on a single computer. The result was actually better than if they had network play -- it turns out, four players crowded around a single keyboard gives a uniquely satisfying experience when playing co-op. With all of the rush for modern consoles to have games that are all network-enabled, we must not forget the joy of sitting next to your friend and playing games on the same couch.

Caketown (by Team Argentina) is a puzzle game where you click on stuff to make other stuff happen; the object is to get the strangely cute zombie-animals to find each other, which lets them eat cake (don't ask, just see for yourself). Only two levels created during the Jam, but after playing them you can see the potential. Design lessons: This is a great experiment in UI. There aren't really any printed instructions or text, but the visual clues are still there to tell you what to do, and if you can't figure out the iconic signs you can figure things out experimentally by clicking on the stuff that obviously looks like it can be clicked on. If you're working on a game that requires the player to go through an hour-long tutorial just to figure out the basic rules of the game, try taking a look at this and seeing how the graphics and art (even environmental art) can do wonders to teach the gameplay.

Head Cat (by Team Brazil) is my personal favorite game of the Jam; the only reason it didn't win is that the judges were mostly 8 to 12 year olds, and the creators of this game admitted that they ignored the judging and just made the game that they wanted to make (it's clearly targeted at a slightly older audience). The gameplay is something between Lemmings and The Incredible Machine. The goal is to get your programmable robot to the cat; the cat then happily goes to sleep on the robot's head (anyone who has ever owned a cat will instantly understand this). Design lessons: This is a great example of what I unsuccessfully tried to teach my Capstone class last year -- namely, to attempt depth of mechanics instead of breadth (especially when working on a time-limited project, such as a Game Jam game or a semester-long class project). There are only a few player verbs in Head Cat: the drill (breaks blocks beneath you), the balloon (slows your rate of falling), the magnet (pulls you up if there's another magnet overhead), and the ability to detect running into walls and floors and reverse direction. Each of these was clearly easy to implement, and yet look at the variety of levels and challenges! The developers even had time to include a full level editor, and I imagine you could make 50 or 100 levels with just the mechanics that exist in the game, alone. Incidentally, it's also an example of how a cute theme can take a decent game and make it instantly memorable.

Honestly, all of the games were impressive for some reason or another. Fruitix (Team Ethiopia) is something like a retro-arcade version of Harvest Moon. Red Bird (Team Tibet) is a timing-based puzzle game, something like a Match-3 game where all panels are the same color and their position matters rather than their color. Star Catcher (Team Peru) had some very satisfying 2D physics and a full level editor (remember that these games were made in about 36 hours). Tumble Boy (Team Libya) did what I tried and failed to do: get scrolling to work on the XO at a reasonable framerate -- and it not only included a level editor, but made it accessible as a plaintext file that you could edit in notepad. Light Ball (Team Nigeria) was another impressive physics game, with the interesting mechanic that you're trying to prevent the sun from going out -- so you have to balance your limited ammunition with the limited time that the sun has left, and in the mean time the screen starts going dark (making gameplay more difficult). I guess what I'm saying is, download and play all the games; you'll be happy you did.

And play with the sound on. All of the games have sound; sometimes it's critical to gameplay, other times it's just amusing, but I can't think of any game that had actively horrible sound. Except perhaps my own, as I explained.

IGF Student Showcase 2008

So, I'm a judge for this year's IGF student division. (Due to an email mixup, I found out about this two days ago, so I've been frantically playing since.)

Some of the entries I've seen are so amazing that I can't believe it's a student team and not a commercial product. Others are so bad that I wonder why they even bothered submitting. Still others, I never even got to see because they crashed before starting. With this in mind, I present some advice to future IGF entrants (student and otherwise) based on the common mistakes I've seen this year.

Find the fun in the first 30 seconds. I was given 21 games that I had to judge. That means realistically, each game is not getting ten hours of play. If the really cool stuff is on the last level, I might never see it. If the really cool stuff isn't even in the game (say, you're making a demo for an RPG and all you've got is the first dungeon where you have to kill 50 rats), you fail -- make one of the later, more fun levels for your demo instead.

Include level select and other cheats. Suppose I'm playing through your five-level demo, and my machine crashes near the end of level 4. Do you think I'm going to replay everything just to see level 5, or do you think I'm going to assume I've seen enough and move on? If I can jump immediately to level 5 with a level select, maybe I'll give it another try; if I have to replay the entire game, forget it. Likewise, if the first level is so difficult that I lack the skills to make it past, give me "god mode" so I can at least see the rest of your content.

Include single-player mode. Not everyone has a gaming group they can play with. If I'm judging on my own, and you require 4 or 8 player simultaneous, I won't be able to review your game at all. If you add AI opponents that allow single-person play, this at least lets me play around with the mechanics somewhat. If you don't have the time or skills to implement a full AI, have the opponents sit there and do nothing and call it a one-player "tutorial". Either way, at least let me play.

Avoid mods. Just like not everyone has a group of gaming buddies, not everyone owns a copy of Unreal or Half-Life. If your game is a mod that requires judges to have software other than your game itself, it might not get judged by as many people. If you must make a mod, be very clear about it in the requirements list when you submit your entry; this is just courtesy, so that judges lacking the ability to play don't waste time on it.

Avoid crashes. It should seem obvious, but I saw some games that actually crashed on startup! Test your installer on a few "virgin" machines before submitting. These last three points can actually be summarized as one: let me play your game!

Don't overhype in your description. Each game has a brief text description. I read it when I'm waiting for the game itself to download. Some people are really full of themselves, telling me all about how original their game is or how great their graphics are or how fun the game is. Don't insult me; I should be competent enough to judge your game on its own merits, not on your opinions of your own game. This actually has the opposite effect for me; if you tell me how original your game is, it just makes me think really hard about what other game(s) yours is derived from. Unless your name is Peter Molyneux, leave the hype to the marketing people.

Make sure the player is having fun, not the computer. Sid Meier's immortal advice rings true in a surprising number of student games. Your game might have an amazing AI or some really complicated mechanics under the surface, but if I can't see, predict and understand them then I'm not really having fun as the player. Try giving your game to someone who knows nothing about it and has never seen it before, and after they play ask them what's going on. Anything they can't tell you is something you need to work on.

Grow a thick skin. Judges can submit anonymous feedback, and we're told that it's perfectly okay if we're harsh (as long as we're also constructive). No game is perfect, especially a student game, so expect everything you've put your soul into to be ripped to shreds. (If it makes you feel any better, you'll get to go through this again once you get into the industry, when some reviewer for IGN trashes the game that you put the last three years of your life into.)

Communicating With Students

I ran into a friend after the game jam, and we got to talking about (among other things) how teachers throw up red flags to students when they see project scope spiralling out of control.

Instructors say things like:

• "This looks like an ambitious project."
• "That's an aggressive schedule."
• "I think you're being very optimistic."

What students hear, respectively:

• "You're an ambitious student. You've got tons of initiative. You're a real self-starter. That's a valuable thing to have in the world."
• "You've got the guts to do what it takes, without letting obstacles get in your way. Go get 'em, you aggressive tiger you!"
• "You never lose hope or let things get you down, and you've got a positive attitude. I value your optimism."

What the professor actually means, in all three cases:

• "You don't have a snowball's chance in Hell of completing this project. It's way too much work and/or way too advanced for the time you've got available, and if you attempt it you're going to fail miserably... if you don't kill yourself in the process. Reduce your scope and bring things back to something remotely reasonable. But... if you insist on trying and failing anyway, in spite of my repeated warnings, it is your right and privilege to try. But don't say I didn't warn you."

I think we professors need to be a bit more clear. Next time I see an overly "aggressive" student project, I'll be a bit more direct when I say so.

The Life Cycle of Course Content

A "news" article today (I hesitate to call this journalism without adding quotation marks) suggests that few people understand how universities change their content to keep up with industry. In particular:

And that's what makes Qantm unique - we're not a university, because what people don't realise is that with a university it takes at least three years to change a course. If a lecturer now sees that companies are using a new language to program in, it'll take him three years to implement it in the course.

This is simply not true. There is a subtle but important difference between the content of a course, the course listings in the catalog, and the course curriculum. I will explain.

Course content is the stuff that actually gets taught within a single course. In my Game Industry Survey course, I have modified the content in minor ways on a day-to-day basis; for example, if the Activision/Vivendi merger happened the day before my talk about game publishers and how EA is by far the largest, you can bet I'd be modifying that content the same day. I certainly wouldn't be waiting three years before I started talking about it in class! Minor stuff like this gets incorporated all the time.

Granted, minor content changes like that aren't quite as drastic as, say, switching from Java to C# in an intro programming class. In that case, the instructor might have to wait until the next quarter/semester before changing the language around, but it can certainly be done. And even if the game industry suddenly decides tomorrow that every programmer absolutely must know C# from now on and it's the last week before finals, an instructor could still modify the last lecture of the quarter by talking a little about this newfangled C#, and how it's similar to the language we learned during this course and how it's different, and that all of the students should learn it on their own over winter break if they want to get jobs, or whatever. There's still no three-year delay.

Course listings, i.e. what courses are available for students to take, can obviously not be modified in the middle of a semester. However, they can (and frequently are) modified on a semesterly basis in the form of "Special Topics" courses. Special Topics is this wonderful catch-all that lets professors offer whatever the heck they want. Sometimes it involves the professor talking about their (very narrow) area of research; sometimes it's a brand-new course that should be added to the curriculum, but the professor wants to try it out just to make sure; sometimes it's a course that's important but offered so infrequently that it never got its own dedicated course number; and sometimes it's just an off-the-wall experimental course idea that a professor has just been dying to try out one of these days.

At any rate, there's always a selection of Special Topics in each department, and they change on a regular basis. Again, no three-year lag time here.

The course curriculum is what changes every 3 years (an approximation -- I'd assume that at a four-year institution it would change every 4+ years, while a two-year community college could modify their curriculum every 2+ years). These numbers are not set in stone, by the way: they are a practical consideration. How can an established university build a reputation for producing quality graduates if the core curriculum of this year's graduating class is different from last year's? This is not (entirely) about universities being slow, bloated bureaucracies... I mean, they are, but that's beside the point... this is about universities not kowtowing to every little whim and fad of the industry, and waiting for trends to become established before they force them on the unsuspecting student population.

So, let's suppose a new programming language becomes popular. C# is so 2005, today it's all about Ruby (not really, this is just a contrived example). Starting next quarter, a Programing in Ruby special topics course magically appears. Academic advisors let their students know that Ruby is the next big thing in the game industry, and they'd better learn it before they graduate if they want even so much as a job in QA or the mail room or something, and they're highly encouraged to take the special topics course if they don't just learn it themselves over winter break. Unfortunately, it only counts as an elective, but creative advisors might be able to substitute the special topics for the Programming in C# course that used to be a core requirement; for students who took that already, at least it's a programming elective. A few years later when it's time to revamp the curriculum, the Ruby course displaces the C# course, and all is well.

Until two years later when the industry suddenly decides that Ruby is so 2008, and the thing that everyone really needs to know is this newfangled C+@#$ (where you program by shouting profanities at the computer, with voice-to-text support in the IDE), and the cycle begins again.

Oh, and one other quote from that stupid article that I feel the need to correct:
Initially there was no master plan for SAE, for colleges and things, but it turned out that I invented practical education, because nobody before me was doing that. In a way I formalised education.

I'm supposed to believe that it never occurred to anyone in the thousands of years that humans have inhabited the planet, to have education that's actually practical? If David Braben invented practical education, then I invented the internet.

Bah.

Reinventing the Syllabus

It occurred to me the other day that my classes aren't traditional in any other way, so why do I keep handing out a formulaic syllabus? Here's the cover sheet I came up with for my class on the game industry; it remains to be seen whether I can get away with actually using it, but it was a fun exercise regardless... (click to enlarge, or download, or something to take a closer look at all the text.)

Culture Shock: Assumed knowledge and skills

Everyone thinks they're a great game designer. Even if they have no experience. Even if their idea of a great game is "the game I want to play, even though no one else will want to." If you tell people you're a game designer, one of the two typical reactions is "hey, I have this great idea for a game..." (the other reaction is "what's a game designer?"). Basically, it doesn't matter if you're a Junior Designer on your first gig or if you've got twenty years experience; everyone you meet thinks they're a better designer than you. This is something you get used to pretty quickly.


Strangely, I didn't see this much when I became a teacher. I don't think I ever had a single student who felt that they knew more about game design than I did. The student/teacher social dynamic is apparently stronger than the "everyone's a game designer" thought process. I have no explanation for this. (It's not just that I have the power of assigning grades; students who didn't even take my classes treated me with a respect that I'm totally not used to.)

Why GPA is Important (and why it isn't)

I have a confession to make. I gave the incorrect GPA on my resume, back when I included it at all. (Getting numbers wrong is an occupational hazard of being part math major.)

Here's what happened: For my first summer internship, I listed the most current GPA that I had at the time. For subsequent positions when I updated my resume, I never got around to updating my GPA. My actual GPA was about three tenths of a point lower than what I reported. This wasn't out of any malicious intent to deceive, it's just one of those things that fell through the cracks. I didn't even notice that I did this until just today when (for the first time ever) I managed to get my hands on my own unofficial transcript.

Now, here's the funny thing. In all the time I've been working, no one ever called me on this, which probably means that no one ever checked. It's possible that no one ever could check, that GPA is confidential and the most a university can do is to verify that so-and-so attended in such-and-such a year. When you apply for a university position, at least, some of them require you to send an unofficial transcript as part of the application package -- which is how I came to notice my own transgression.

This would seem to imply that I managed to get by in the industry on the strength of my experience and my interview skills, and little details like grades didn't matter much. To which some students will say "Great! Then I can stop spending all of my time studying, and just play more Halo 3, since it doesn't matter anyway!" and other students will say "You mean I can just put that I got a 4.0 on my resume and they'll believe it?"

I would say no to both.

Why not to falsify your resume: even if the odds are low that it will be checked, if you apply to the one company that asks for a transcript, you're in trouble -- it's a small industry, and people will talk. I at least had plausible deniability; if you're a C student pretending to be on honor roll, it's hard for you to say it was an accidental typo.

Note to people in industry: check references of new junior hires! Seriously. Some people will lie. Even if they don't, when I offer to be a reference for one of my students, it means I want to be contacted so I can give the honest dirt (and, honestly, so that I can then contact that student and let them know that this company checks references, which is a good sign that they might make fewer bad hires than average). You may not be able to verify their GPA, but at least verify what you can.

Why not to slack off and stop caring: because your education might not end when you get your Bachelor's degree. Maybe you'll want to head directly to graduate school, where your GPA is most certainly a factor in which places you can get into. Maybe you'll delay awhile and decide to go back to school later; even if you're burned out on school now and don't think you'd ever want to do that to yourself, time might change your mind. Maybe after your requisite 5.5 years in the industry you'll decide to go into teaching (like I did), where your previous degree(s) and your GPA are a factor. And yes, being able to put a big number on your resume might be the one last excuse a game company needs to hire you.

Oh, and I should add that the stuff you're learning in college is actually useful (even if you can't see why right now, since most teachers suck at showing the context of their subjects) and the same actions that get you an A are those actions that actually help you learn. Most of the time.

The Fairness versus Usefulness Tradeoff

Game designers love tradeoffs. Tradeoffs are one kind of "interesting decision". Life is full of all kinds of tradeoffs (it has in fact been argued that life is simply a massively-multiplayer game... with extremely realistic graphics). Teaching has its fair share as well.

Here's one that I'm discovering: the more useful an experience that some exercise (an in-class presentation, homework problem or project) is, the more subjective the grading is.

It's very easy to create a multiple-choice exam where each question has exactly one, clearly correct answer. The grading is easy and the grades themselves are inherently fair. But students don't actually learn anything by taking the exam, they merely show you what they've memorized. The same is true for homework questions that are direct enough to have exactly correct answers.

By contrast, essay questions, open-ended student projects and creative exercises all lend themselves to both student and teacher interpretation. Even if you think you know what you're looking for in order to grade objectively, some students will surprise you with unexpected answers and you'll have to revise your grading methods. Sometimes a student answer will, on reflection, be better than your own. Sometimes you will simply not understand what a student is saying, and they will be completely correct and it's your own fault for misinterpreting their answer (you can weasel out of this by saying "if I didn't understand it then it was poorly written" but I would consider that the height of arrogance in most cases).

And yet, these subjectively-graded exercises are the most valuable because they force the students to actually design something.

In terms of teacher evaluations, this means that any class where I score well on "relevance to the real world" is probably also a class where I score poorly on "fairness of grading"...

I Came, I Saw, I Jammed

Participating in a game jam is a very different experience than coordinating it. Each game really is like a full AAA development cycle, time-compressed down to less than 48 hours; spending a weekend on this can practically give you as much experience as working on a full game, so I highly recommend it to students and professionals alike. We even had a fair population of people who have never made a game before at all, so I would recommend this for instructors as well.

In true Post-Mortem fashion, here's how it went for my team:

What Went Right:

• Multiclass Developers. On a small team with such a short deadline, having people who only know how to do one thing can lead to some precious time wasted; designers must sit on their hands while waiting for the programmer to implement their designs, while programmers and artists have to wait at the start until they know what they're supposed to make. Since team size is constant over the project (you can't scale up after "pre-production" like you can in industry) you need to make sure everyone is occupied constantly. I was a programmer/designer for my team, along with two artist/designers and a designer/audio guy. We all collaborated to get a basic concept quickly, and then everyone had some content to work on once we were done. Lesson for industry: The value of generalists with multiple skills increases in proportion to the rigidity of team size.
• Research. The goal was to make a game for kids age 8-12, which none of us had done before. I took the liberty of scouring Gamasutra for relevant articles, and talking to colleagues about what kinds of design rules are different when designing for this age group. I'm glad I did; we did not have the benefit of anyone sharing tips on this at the start of the event, nor did we have the opportunity (or the time) to focus test. Lesson for industry: If your project involves targeting a demographic that doesn't exist on your development staff, make an extra effort to remedy this.
• Constantly Shippable Code. We had something playable within a few hours of starting. It wasn't complete but it did run. This gave us the advantage of flexibility; no matter when we ran out of time, we knew that we would at least have something to show for it. Lesson for industry: Always have something to show. I think this is even more important in a world where deadlines can change, and publishers can unexpectedly drop by and ask to see how far along you are.
• Concept and Technology. We first asked ourselves how we could keep the control scheme so simple and obvious that we wouldn't need any text to explain it; we came up with the idea that you controlled a paper airplane by "blowing" on it, using a flicking motion on the touch pad to blow wind that would cause the plane to move in that direction. I think we got that part of the game feeling pretty good. In the process we also managed some things that Python and Pygame (the required language for this hardware) were never intended to do: smooth-scrolling backgrounds, and adaptive background music that would gradually get more frantic and intense the faster you scrolled.

What Went Wrong:

• Scope. We designed a game that we knew we could finish within the allotted time. Unfortunately, it took exactly the alotted time, so we had no time remaining at the end for polishing the graphics, sound or gameplay. As a result, our final project was one of the least compelling games of the jam. Lesson for industry: Design games that can be made in far less time than you have, and then use the extra time in the schedule to polish what you have in an extreme fashion.
• ...And More Scope. Our audio designer went AWOL on the last day of the jam, with his work left unfinished. As a result, we had to divert some resources away from art just so that we had at least some background music, and what we ended up with was just thrown in at the last minute. The final game sounds horrible, even though it has the capability of sounding amazing. Lesson for industry: Avoid having people on your team who are irreplaceable, in case they get hit by the proverbial bus (ours might have been hit by an actual bus for all we know). Thank goodness we didn't have a multi-million dollar development project at stake!
• ...And Even More Scope. We originally expected to have 14 regions in the final game, because the artists were able to finish the first region in only an hour or so, and at that rate that left them plenty of time. But the artists couldn't sustain such a high rate of work after sleep deprivation set in, and cut down to 7 regions... and four of those were thrown in at the last minute, so we should have cut down to only three or four (and just made those look really good). We also lost a lot of time to an undocumented technical limitation: Pygame blows up if any sprite is more than 14400 pixels wide, so instead of having one massively wide background we had to break it up into several regions, with one screen-length overlapping from each region to the next. This forced the artists to re-work a lot of their original files, costing valuable time that wasn't accounted for in the original schedule. Lesson for industry: Design your core mechanics to have scalable content. If your game needs a large number of levels to be playable, and you run into scheduling difficulties, you're in trouble. If your game can support a short play experience but becomes boring and repetitive if you try to add an extra 20 hours of gameplay time, you're also in trouble. Best case is a game that works no matter how much content you have, so that you can add exactly as much as time allows and know that it will be fine.
• Concept is Nothing; Execution is Everything. Our execution was okay (especially considering we only had a couple of days) but not spectacular. A lot of great ideas were simply not implemented in a way that made them realize their potential. I tell this to my students over and over again, but saying it is one thing and experiencing it is another. The winning games were all very simple concepts with relatively little content, elegant mechanics and a high "fun" factor. Lesson for industry: Maybe the lesson here should be, make all of your mistakes in Game Jams rather than on big-budget projects. If you ever want to try a new development methodology (maybe you've always worked in Agile development and wonder what could possibly go wrong if you try to design everything up-front in a comprehensive design doc, or you've never done Rapid Prototyping, or you want to see the effect of a lengthy preproduction, or something), try it in Game Jam form, with the understanding that an hour of a Game Jam is roughly equivalent to a month on a large project if you're trying to compare schedules. You'll probably learn a lot about what works and what doesn't work, without wasting huge development resources.

I'll update this post with a link to the games, as soon as it's online.

Teaching Game Design in the Middle of Nowhere

Columbus, Ohio is not exactly a hotbed of developer activity, but we do have an official IGDA chapter. Michigan is in a similar state, and they sent a very interesting meeting summary to IGDA's Game_Edu list a few weeks back. The results of their meeting are relevant to teachers and students alike. To paraphrase:

• Students living in locations with few (or no) developers should accept that they will need to move out of state in order to find work. (I would add: even students living in big game dev areas may need to move out of state from time to time, if they have trouble finding local work or if they get offered a dream job at a studio halfway across the country.)


• Finding qualified teachers is difficult everywhere, but especially in out-of-the-way areas (most professional developers who want to become teachers would not like to move to the middle of Michigan for the privilege, especially when there are perfectly good universities local to you no matter where you are). Universities in out-of-the-way areas can offset this somewhat by paying to fly guest lecturers in on a regular basis, but this can get expensive. Many universities require their professors to have at least a Master's degree, which is rare in the industry, and just makes a difficult thing harder.


• The industry can change quickly, obsoleting course material and even entire courses in the curriculum... but universities tend to move slowly when it comes to curriculum adjustments, which can be problematic in the medium term. Suggested way to deal with this: make course titles and descriptions general in nature so that the content can be modified on a per-semester basis as needed.


• The often-asked question: is it more important for art students to know fundamentals or tools? (I would add that the same question applies to programmers and designers.) The unhelpful but still correct answer: both!


• Game development is incredibly interdisciplinary, but most universities have these huge walls between departments. How do you overcome this obstacle? No easy answer, other than "design the program to address this issue from the beginning" -- suggesting that incremental additions (start with one game-related course, add a couple more courses next year, eventually expand into a full program) is doomed to be restricted to a single department and will not capture the interdisciplinary nature of real-life development.


• As university programs get established, we want to start thinking about ways to push this further down the education chain into high school. Several universities reported success with offering one-week summer camps: they serve the triple purpose of community outreach, exposure of the field, and recruitment.


• One of the hardest things when dealing with students is to convince them to work on small games and complete them, rather than working on a single huge sprawling mess that dies under its own weight. It's also hard to convey the 80/20 rule, that 20% of the work gets you the first 80% of the game... but getting that last 20% of the game (which is the polish factor) takes a lot of time after the game already feels like it "should" be done, and pressing on when you're sick of working on the game already is what separates the developers from the wannabes.


• Interestingly, the bar for entry into the industry is getting higher because of the high quality of university-level instruction. Ten years ago, some modding experience and/or a single completed game was enough to set a student apart from the rest of the pack. Today, it's more like 2 to 3 games. I see this as a good thing (it means that at least some of the universities out there are doing their job). I also see it as implication that we should start requiring some business courses integrated into any game development curriculum... because we'll need more students to start their own game studios to make more jobs to soak up the excess supply of talented individuals.


• Schools should give all of the rights to student-created work to the students themselves (sadly, not all universities do this). Schools should also have policies in place to determine IP ownership if a professor makes a game (or collaborates with a game studio in some way); ideally this policy should be very friendly to the individuals in question, to encourage industry/academic relations. In any case, work this out first, before it becomes an issue that must be solved on the fly.

Creativity

I was thinking the other day about the question that is the tagline of this blog: can you teach creativity?

I'm afraid to say that the question may itself be flawed. There's a deeper question here: do we even need to teach creativity?

Everyone in Hollywood, even the janitors, has their own idea for a movie script. Everyone in the game industry, down to the lowliest of the QA staff, has a game idea. Yes, most of these ideas aren't worth the paper that they'd be printed on, but that's not the point. The point is that each idea is creative. Maybe not particularly innovative, maybe not fun... but creativity, it would seem, is an ability that all humans are born with.

I have precious few traditional art skills. I can't draw, sketch or paint to save my life. But I still can form images in my head that I think would make great pictures -- I just lack the technical skills to express them. Technical skills can be learned. They can also be taught.

I think that game design is the same. Maybe you have a great idea for a game, or a lousy idea... but it's an idea. All you need are the tools to express it. In my case, the tools are not paints or pencils or canvas; they are Word and Excel. My technical skills do not require an understanding of perspective or vanishing points or character rigging; rather, I need to understand the fundamentals of pacing, flow and game balance. All of these are skills that can be taught, and then it is up to the designer with those skills to go forth and design a game worth playing.

Of course, this all leads to the question: how does one know if a game is worth playing while they're designing it? The same question could be asked of the painter: how do you know this painting will be any good once you've finished it? That is much harder to teach (although it does come with experience)... but that's not creativity, that's craftsmanship.

So, perhaps I should rename the tagline of the blog. Is it possible to teach craftsmanship (without a ten-year one-on-one master/apprentice relationship)?

Speaking at GDC

In news that I'm sure will be completely unsurprising to any who read this blog, I'll be holding a roundtable entitled Breaking In to Academia. Session info is here.

This is a huge honor for me. Five years ago, if you'd asked me how I would know when I finally "made it" in the industry, I'd have said "when I'm a speaker at GDC." Ironically, I get my 15 minutes of fame after I stop working full-time in the industry (arguably, I get my 15 minutes because I left the industry). Life is strange that way, sometimes.

Anyway, I hope I'll get to see at least a few of you there.

New Teaching/Design Blog

Another one joins the field.

Brenda Brathwaite, a former co-worker who headed from industry to teaching about half a year before I did, just started a blog about her adventures in the strange land of academia:

bbrathwaite.wordpress.com

Welcome to the blogosphere, Brenda!