Friday, November 30, 2007

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

Tuesday, November 27, 2007

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.

Friday, November 23, 2007

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

Monday, November 19, 2007

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.

Friday, November 16, 2007

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.

Monday, November 12, 2007


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

Monday, November 05, 2007

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.

Saturday, November 03, 2007

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:

Welcome to the blogosphere, Brenda!