Monday, February 02, 2009

Running for IGDA Board

The IGDA elections are underway, with four board seats open. I've thrown my hat into the ring.

If my personal statement sounds like something that resonates with you, I'd appreciate your vote. And if you're not a member of the IGDA... well, this is as good an excuse as any to join.

Thanks for your support.

Wednesday, January 28, 2009

Global Game Jam this weekend

After many months of planning, site wrangling and organizing, the Global Game Jam will take place this weekend. We have 54 host sites in 51 different cities, 24 countries and 14 time zones. We're currently looking at somewhere in the neighborhood of 2000 participants. It's pretty amazing how big it's grown in just the last few months.

I'll be providing realtime support to the sites for the entire weekend (minus the time when I'm sleeping) from my home office in Columbus.

If you're not already signed up, see if there's a location near you.

Tuesday, January 20, 2009

Awkward Moments

A short collection of social awkwardness as experienced by a game-designer-turned-educator, in no particular order:
  • Having several students admit that they played a game you worked on, when you know the game in question wasn't particularly good. (Additional awkwardness: when the game in question is M-rated, and you know that the students were underage when they played it.)

  • Giving a game design constraint for an in-class exercise, and repeatedly being asked questions about the exact boundaries of the constraint... and realizing simultaneously that my students are trying to weasel out of the constraint (and that I should be annoyed), and also that my students are trying to precisely define the constraint (which is an important skill for game designers, and something I should be proud of).

  • Witnessing a student fall asleep in class, and hoping that it's because the student got no sleep and not because I've really become that boring. (Additional awkwardness: waking the student up, and hoping that I done it in a way that I haven't cruelly humiliated them.)

  • Assigning a homework that's not only easy but actually fun, and seeing that half the class didn't bother to complete it. And then wondering if my definition of "fun" has changed.

  • Writing something out (an assignment, a syllabus, an email, etc.) that I thought was clear as could be, and having students not understand it. This either means I'm not as good a writer as I thought, or that my students aren't functionally literate, or that my students are lazy... and no matter which it is, there's nothing I can be happy about.

Wednesday, January 14, 2009

Book Writing: Tips, Tricks, Cheat Codes

Because we're both game developers, Brenda and I conducted a post-mortem of the book we wrote. Because many professors write their own textbook eventually, I thought it might be nice to share what we learned with you. (After securing the go-ahead from Brenda, of course.)

To protect the innocent, I won't say what we got "right" or "wrong"... but this is what we learned, for better or worse.
  • Write with a co-author that you already know you work well with. I really can't stress this enough. Aside from halving the amount of work you have to do, it's great to have someone to bounce ideas off of, and it's kind of like having an extra technical editor for free. It's also a lot harder for the project to stall when you know that someone else is counting on you (a friend and colleague, not just some monolithic book publisher).
  • Use some kind of version control system. It doesn't have to be as elaborate as Visual SourceSafe or CVS, but you will be making many changes and revisions to documents, and you will want to have a history in case you need to reference that paragraph that you deleted three months ago and now you want to use it in a different chapter. We found that simply numbering the documents (Chapter01_v1.doc) was sufficient.
  • Use the Track Changes functionality in Word. It's great. It's like a version history built-in. Use the comments to communicate with your editor and other authors.
  • If you're working with another author, use Google Docs for preliminary work. It's a free, convenient way to share chapters, and if you're on an instant messaging program (or on the phone) you can even edit the same document at the same time. You can always add any special formatting later, after importing into Word.
  • Keep track of the current status of each chapter (not started, rough draft complete, final draft complete, submitted to publisher, accepted by publisher) in an Excel document. Update it whenever you finish anything. This is especially important if working with another author, so you know who is currently editing what (you run into a lot of "did you finish this chapter and it's waiting for me to review, or were you still working on it?" questions).
  • Choose your book topic carefully, and whenever possible write about what you already know. Everything that you have to research takes extra time, and a book where you have to research everything will take a lot of time.
  • When you're working with the publisher on the initial schedule, build time in the schedule for iteration. There are a lot of tasks that affect the entire book (consistent formatting, terminology, overall structure and other things) that you'll want to change several times as you write, and the easiest way to do this is just to make one final pass over everything at the end... rather than making these changes several times over the course of the project. But you only get to do this if there's time, and if you're rushing to meet the deadline then the whole thing can look a bit sloppy.
  • As a corollary, keep a list of open issues for the book, so that nothing falls through the cracks. Keep it updated whenever you run into a problem that you want to defer until later, and reference it when you're doing revisions.
  • Find people to review different parts of your book (friends, colleagues, grad students... anyone who you think would give you good feedback for any particular chapter) and start that process early. If you're writing a textbook intended for classroom use, teach a class from an early version to see how it will actually function (think of it as a "beta test").
  • Get constraints from your publisher early on regarding number of chapters and pages, and find out the approximate ratio of pages in Word to printed pages in the book (a ten-page Word document might be twice as many pages in the book because of extra whitespace added to sections so the paragraphs aren't split between multiple pages, or to allow extra space around figures and photo images). This prevents you from finding at the end of the project that you suddenly have to add or cut a bunch of content.
  • While I'm on the subject of images, get your images early. Securing the rights to photos of people, screenshots of games, company logos, and so on takes a lot of time.
  • Develop a system for references to other parts of the book (for example, "See Chapter X, Page Y" when you don't know what the final chapter and page numbers will be). If you use actual numbers, you'll just have to end up changing them later... and woe to you if you accidentally miss one.
  • Create a core statement for the book up front. Do you want to write in a professional or casual tone? Do you want to focus more on content or concepts? What is the underlying theme, the one thing you really want the reader to understand when they're done -- the common thread that ties everything together? Revisit your core statement when you're reviewing or revising your chapters.
  • Clear your schedule if at all possible. Writing a book takes a lot of time, and if you're trying to balance that with teaching classes, doing freelance work and remodeling your kitchen, you are just not going to have the energy. If you minimize your downtime and interruptions, things will go more smoothly.
  • Do your due diligence with publishers. If you've got a great idea for a book, then it should be a great idea no matter who the publisher is. Seek publishers who have a line of successful books in your field, so that you can get some decent cross-pollination with readers of other books in the same series. Look for publishers with wide distribution networks. Think of whether your publisher has the means and understanding to promote your book (or, whether they're willing to let you do some self-promotion). Find out who your editor(s) will be, and how much experience they have (if any) in your field; if you've written a book before, you may be able to request a specific editor for your book. At any rate, there's no reason why you should just take the first offer that comes along and accept all terms without negotiation... any more than you would with a job offer.
  • Keep backups of everything. If all of your work is on your home computer hard drive and that hard drive crashes five days before the next scheduled milestone submission to the publisher... well, I'm sure you can imagine.
  • And lastly, don't expect to get rich as a book author, any more than you would as a game developer. The advance you can expect as an author is not very much when you compare to the amount of time you're going to spend on the project. Yes, you can make a lot of money if your book sells well enough to earn you royalties, but that is the exception and not the rule. This doesn't mean you shouldn't write a book... but if you write one, do it for reasons other than money.

If there are any other textbook authors in the audience, please comment and share your own tips.

Thursday, January 08, 2009

One Easy Step Towards Interactive Teaching

I've said before that classes are more interesting to students if you can make them more game-like, i.e. to give the students some interactivity (if not actual decision-making) rather than just lecturing at them.

If you're a teacher who is used to just speaking at your students and want to break yourself of the habit, here's an easy experiment for you to try in your next class:

1) Look over your lesson plan, and pick out one thing that is ambiguous, unknown, open to interpretation, or otherwise has no "right" side or answer. (Example in a biology class: the definition of the term "life".)
2) Design an open-ended question about the thing you chose. (Continuing the above example: "How would you define the term life?")
3) At some point in your lecture, ask the question to your class, and wait for the students to try to answer. If it takes a few seconds before you see any raised hands, that means they're actually thinking about your question, which is a good sign (or it means they're asleep, which is a sign that you've been lecturing for too long). Sometimes students will raise their hand to elaborate on (or even disagree with) a previous student's answer; encourage this, as you're creating an interactive dialogue among your students. If one student gives an answer and no one else feels like adding to it, challenge it yourself; play devil's advocate. But if at all possible, confine yourself to a role as moderator; if you chose a good question, your students will do your work for you.

You might notice a few things about this method:
  • It gives your own voice a much-needed rest in the middle of a long lecture :-)
  • Your students will actually be paying close attention.
  • Your students will actually be thinking. In class, no less.
  • As often as not, one of your students will say something particularly insightful that makes you think.

If you try it and like the results, increase the number of questions. Personally, my classes are usually about two hours, and I shoot for a goal of at least three discussion-questions per class. But if you're not used to it, you can work up to this one question at a time.

Tuesday, December 30, 2008

One Myth About Teaching

I was confronted with the opinion the other day that teachers are overpaid because they only have to work 9 months out of the year but get paid for a full year. I'm pretty sure the person who expressed this opinion has never actually met a teacher before, but it seemed like a thought that a lot of people might have. So, I thought I'd set the record straight.

First, a teacher in any field typically gets paid a bit less than a working professional in that field, even though they have to know just as much (if not more). This is why a lot of teachers feel underpaid for their work -- because with their qualifications, they could make more if they weren't teaching.

As for being underworked, I know of very few teachers who sit idle on summer/winter break. In my own experience, the time fills up fast:
  • There's a lot of prep work to do for classes before they start: revising syllabi and course content, evaluating new textbooks, and keeping current with industry trends all take time.
  • If you're teaching any brand new courses, you have to develop everything from scratch, which typically takes about as much time as teaching the course itself (i.e. one new course = two old courses, in terms of time commitment).
  • Keeping professional skills sharp is important. Over breaks I usually end up doing some kind of freelance contract work.
  • Ever heard of summer and winter classes? A lot of teachers hold classes over these supposed "break" periods.
  • And of course, during the academic year teaching is a lot more than just a 9-to-5 job. In theory you're supposed to have a 40-hour work week, which is 4 or 5 classes if you're full time (that includes face time in lecture or lab, and also out-of-class time spent grading). But in addition to that, you have other duties: academic advising, office hours, faculty meetings, and (if you're really unlucky) being on a committee.

In reality, teaching is more than a full-time job.

Does that mean that these thoughts of "lazy" teachers who only work "30 weeks out of the year" are completely inaccurate? Unfortunately, no. It is possible to reduce the workload. You can hold office hours for your classes simultaneously, and then use the time to get other work done if no students show up (although this means you'll end up treating students like they're interrupting you when they show up for scheduled office hours). You can just copy your course notes from earlier classes without updating them, which reduces prep time to almost zero (but then you cheat your students out of a modern education). You can set up your assignments so that they're easy to grade (but anything easy to grade is usually not that meaningful -- for example, you can tell a lot more about a student's understanding by reading an essay than you can get from a multiple-choice question, but multiple-choice is easier to grade).

So, it is possible to have lots of time off, work 40 (or fewer) hours per week for 30 weeks a year, and have the rest of the time free to... um... do whatever teachers do when they're not working. But so far, the only way I've found to do that is to cheat your students. If you want to be a good teacher, forget any thoughts you had of annual three-month vacations...

Monday, December 22, 2008

About youth being wasted on the young

It may be too early to tell, but already I see a cycle emerging:
  • At first, many bright-eyed hopeful students want nothing more than to make the next generation of AAA games. In their spare time, they play certain games obsessively, and it is these games in particular (or others just like them) that they'd like to make.
  • Some of these students graduate, get into industry and enjoy it for a time, but eventually get frustrated. They're a small cog in a huge machine, going from one crunch period to another, with no end in sight. In their spare time, they play short games because that's all they have time for, and they secretly wish they were Jason Rohrer or Rod Humble or Jenova Chen.
  • Some of these frustrated developers leave the industry for academia, and are frankly amazed at how much of an opportunity the next generation of students has. Why, they could use their talents to make the next big art game that has all of the professional developers collectively salivating at its brilliance! These students have the time, they have the skills, they've got the drive... but all they want to do is make a clone of their favorite AAA titles. Oh, the tragedy of wasted opportunity!

And then the cycle repeats.

I do my best to describe this to my students. In a few cases, they get it. Most of the time, it's like trying to describe working in an office job to a second-grader: the life experience necessary for total comprehension just isn't there yet.

I see other teachers forcing the issue. I hear at GDC of class assignments that involve having students create games that teach, games that inform, games that enlighten, games that have a positive social impact, games that make the world a better place, games that express an emotion (other than power fantasy or adrenaline rush), and so on. These kinds of assignments are a reflection of the instructor's agenda: these are the kinds of games that the teacher wants to make.

If you're a student, looking at the game design assignments heaped on you will give you a clue as to the kinds of things you might really want to make yourself in five to ten years (even if they seem arbitrary or meaningless right now). If nothing else, it shows you how your instructor -- the same person who wanted to make nothing but AAA games back when they were your age, if you can believe it -- has changed over time.

But it is a real shame that a lot of students today won't figure all of this out until it's too late. George Bernard Shaw's quote about youth being wasted on the young is ringing true.

Tuesday, December 16, 2008

Emergent Design: Paper Prototyping of Aiming/Hit Mechanics

Just a quick tip today from one of my earlier game design classes (we actually came up with this as a group in the middle of class while critiquing a student project):

If you're designing a paper prototype for a digital game and one of the core mechanics involves accurate positioning (examples include aiming in an FPS, positioning a paddle in a ball-and-paddle game, or maneuvering an avatar through an obstacle course), flicking a coin on a flat surface towards a target gives a reasonable approximation.

In our particular case, the student was designing a ball-and-paddle game. We discovered that if the coin was the paddle and a single flick was your allotted movement (then you repositioned the ball), it had the realistic property that it was much easier to hit a ball coming right at you than one that was landing halfway across the screen.

For an excellent example of this mechanic in action, see the non-digital game Pitch Car. Okay, so it's not Gran Turismo... but it could easily be the basis for a non-digital version of Mario Kart.

Saturday, December 13, 2008

Where Do Game Ideas Come From?

A recent article by fellow teacher/designer Lewis Pulsipher got me thinking about game ideas. A lot of students appear to assume all core concepts start like this:
"It's just like this other game that I like, only with these other elements added that I also like!"

In the real world, games are rarely made that way. There are all kinds of constraints that get a designer started. Some examples:
  • A publisher issues an RFP for a sequel to an earlier game, now that the original developers are out of business.
  • A publisher acquires the rights to a licensed IP and asks for concepts using that IP.
  • A publisher notices there are no announced titles in a certain popular genre within a certain fiscal quarter a couple years from now. You start with a genre, timeline and budget which are all written in stone, but you're free to be original otherwise.
  • A publisher notices a fast-growing, underserved player demographic and asks you to make a game to specifically attract that demographic (such as the notorious "games for girls" phase that the industry seems determined to screw up about once every ten years).
  • An educational/training company approaches you, asking you to make a game to teach a given set of content more effectively than traditional classroom study.
  • A political organization commissions a persuasive game to push a specific agenda or raise awareness of an important issue.
  • An indie developer wants to make an "art game" to express their own emotional struggle through gameplay.

I've found the best way to break students of their habit is to introduce them to a variety of real-world constraints, giving them practice in designing games to those imposed constraints. Because game ideas may come from all over, but the ones that get made into AAA games usually come from constraints imposed from above.

Sunday, December 07, 2008

Required Playing

A recent conversation I had reminded me of something, which I share with you now.

Students of any artistic medium should are expected to study the more famous/important works within that medium. A graduate of a film school who had never heard of Citizen Kane, a graduate of an art school who couldn't recognize the work of Van Gogh, or a graduate of a creative writing program who never read Shakespeare would all be considered rather embarassing to their schools. So, it's up to the school to make sure their students get exposure to the great works of their field. So it should be with the study of video game design.

Let's assume for the purpose of this exercise that a teacher can find some way to gain access to any game, regardless of technical constraints. Let's also assume that there are no time constraints, and "how do I fit all of this in the core curriculum?" is someone else's problem.

The question: if you were to make a list of games that all students of game design should know about, what games would be on that list? This should mostly involve games that did at least one thing really well or poorly with respect to game design (not technology or art), i.e. those games that we should be able to learn something from. The games that, intentionally or not, made some contribution to the field of game design.

Here's my own list, so far:

Classic Non-digital: Chess, Go, and at least one card game featuring trick-taking and trump (Spades, Bridge, Whist, etc.)

Modern Non-digital: Settlers of Catan, Carcassonne, Puerto Rico, Magic: the Gathering, Dungeons & Dragons (at least read the Player's Handbook and Dungeon Master Guide)

Arcade: at least one ball-and-paddle game (Pong, Breakout, Arkanoid), at least one LaserDisc game (Dragon's Lair, Space Ace, etc.), Pac Man, Gauntlet, Super Mario Bros., Street Fighter 2, at least one side-scrolling shooter (Gradius, R-Type, etc.), Tetris

PC: at least one Roguelike (Rogue, Nethack, Angband), Archon, any game from the Civilization series, Warcraft 2, Where in the World is Carmen Sandiego, Star Control 2, Ultima IV

Console: Chrono Trigger, Legend of Zelda: Link to the Past, any game from the Pokemon series, any game from the Harvest Moon series, any cart-racing game (Mario Kart, etc.), any realistic racing game (Gran Turismo, etc.), at least one side-scrolling adventure game (Super Metroid, Castlevania: Symphony of the Night, etc.), any tactical RPG (Final Fantasy Tactics, Disgaea, etc.), any modern Western RPG (Knights of the Old Republic, Oblivion, etc.), any modern Eastern RPG (Final Fantasy, etc.), any modern 3D platformer (Ratchet & Clank, Sly Cooper, etc.)



Feel free to post arguments against any from the above list, or any games not on the list that you'd add.

Tuesday, December 02, 2008

What comes first, theory or practice?

The first year I taught game design, I taught two game design courses: a fully practical one where students were given realistic game design problems (e.g. "Develop a core concept and one-page concept doc with brief description, genre, target audience, target platform, and feature list for a given IP") and a fully theoretical one where students read about the leading thoughts in the field and discuss them.

Because of administrative snafus, the practical course was taught first. Students loved the challenge, but once they got to the theory course the (predictable) reaction was: this is great, why couldn't you have told us this stuff before when we could have actually used it?

The next year, I vowed to teach the theory first, and then the students could use this strong foundational understanding of the field to go on and make excellent game projects in a practical class that followed. I ran into a different problem: without the practice of making real games, the students weren't nearly as interested. Sure, I can talk about MDA or flow theory or positive feedback loops all day long and not get tired, but the students had no easy way to contextualize all of this. Yes, I can give practical examples from real games, and that is part of it... but without having done a lot of design work themselves, the students had a lot more trouble seeing it.

Chicken. Egg. Gah! I can't win! Or can I?

This Winter, I'll be trying a third approach: combining the two into one course, alternating the theory with the practice so that we first go over a small bit of theory and then immediately apply it in a real design situation. I look forward to seeing how this goes.

It occurs to me there is a potential fourth approach: also a combined course, but with the practice first... then followed by discussion. This has the downside that students are less likely to produce anything of value (after all, I'm not teaching them how until after each assignment is over) but it should make the discussions much more valuable: we can talk about what went right or wrong on each project, and then comment on how current theories play into it all. I may try that in a future iteration.

Monday, November 17, 2008

Topic for Discussion: Who is the Thomas Kinkade of Game Design?

This came up in discussion with another designer the other day (after a comment along the lines of more game design students these days being familiar with Thomas Kinkade than Reiner Knizia). I thought it would be an interesting open question to repost here.

If you're unfamiliar with Thomas Kinkade, he is one of the more (in)famous painters alive today. You might want to read his Wikipedia entry here to put yourself in the right frame of mind to consider this question.

The question: to the extent that game design is an art form, what game designer is the equivalent of Thomas Kinkade? Or, more succinctly:

Painting : Thomas Kinkade :: Game Design : ???

Some people might consider the label "Kinkade of Games" to be a great compliment. Others might consider it a grave insult. For this reason, I won't hold it against anyone if they choose to comment anonymously.

Thursday, November 13, 2008

Art Critics

I recently had occasion to go back and read Roger Ebert's claim that video games could never be art due to the inherent limitations in the medium, his further rebuttal to Clive Barker, and the resulting article from game designer Clint Hocking.

At the time, I thought this was a relatively new argument. Games are a new medium, after all. Today, I realize that all of this haggling over what is or isn't "art" (or "high art" or "fine art" if you prefer) is nearly a century old. At least.

Ebert's arguments essentially boil down to this:
  • I am going to make a list of criteria by which art should be judged.
  • Games cannot be judged by this criteria, due to the nature of the medium.
  • Ergo, games are not and can never be art.
Here's the thing: there was an art critic named Clement Greenberg who was highly influential in the art world in the 1930s and 40s, who basically did exactly the same thing for modern art. He wrote some highly influential essays that essentially gave a list of criteria for judging art. And for awhile, his ideas were followed almost religiously to decide what was good or bad art, and even what was and wasn't art in the first place.


Then, the so-called Postmodern movement came along and basically said "screw this, art can be more than Greenberg's one narrow slice of representation." All of a sudden, there was a trickle and then an explosion of art that looked absolutely nothing like Greenberg's ideal modern art. But the new stuff was still, clearly, art. The Postmodern charge was led by another art critic, Harold Rosenberg.

So, two artist critics already figured out the correct argument for why games can be art... about half a century ago. A few years ago we re-enacted the old debate, with Ebert playing the part of Greenberg and Hocking playing Rosenberg, but the arguments are essentially the same.

If I had known this back in 2005, I could have written an influential essay on the subject. Today, there are so many art games that I think such an essay is unnecessary. But I still find it interesting how we retread old ground without realizing.

Wednesday, November 05, 2008

What Happens After Graduation?

Having encountered a few former students recently, I was reminded of something that I think every student should know:

This is a hard industry to find your first job. There's a reason it's called "breaking in."

This usually hits home about 3 to 6 months after graduation. The student (well, no longer a student) applies to a bunch of game companies, only to either get rejections or dead silence. And then comes the self-doubt: am I not finding a job because there's something wrong with me? Am I not as qualified as I thought I was? If I'll make such a great game developer, why won't anyone hire me? Maybe I should've listened to Uncle Roy and gone into insurance.

Making it through that period is important. Once you're through, there comes a redoubling of effort: I just have to try harder. I'll apply to more places, and start looking for new opportunities that I might have missed. I'll call back those places I haven't heard from, just to check on things. I'll go back to the websites of the companies I was interested in and see if any new positions opened up since a few months ago.

And then on some idle Thursday, you get that call. And maybe it's your dream position that you thought was lost, and maybe it's QA at some local no-name casual games company, but at that point you've got what you were after: your first industry job.

Granted, it doesn't happen like this for everyone. Some students are lucky enough to line up employment before they even graduate. But I've seen the scenario above more often than not (and not just with my students, either), and it's worth a reminder that this is not a poor reflection on the student... it's part of the process.

So...

If you're a student about to graduate (or recently graduated): bookmark this post, and return to it when you're looking for that first job and everything seems so elusive. Remind yourself that it's not you, it's the industry. So buckle down and try harder, and keep trying until you get a job.

If you're a student who won't graduate for awhile: remember that this can happen, and plan accordingly. Make sure you've got some way to support yourself for awhile after you graduate, if you have trouble finding a job making games. Take care of food/water/shelter first, and realize that finding game-related work can sometimes take awhile.

If you're a teacher: remind your students of this every now and then. It's easy to forget, but it's important to remember.

Friday, October 31, 2008

Fighting Designer's Block

I recently attended an online seminar called "Creativity Coaching" (sorry, I can't find a link to it), billed as, essentially, a method for overcoming creative blocks -- whether you're a writer, artist, game designer, or some other creative type.

The practical upshot is this: it's easy to be creative when you're passionate about what you do, but it gets harder when the creativity is forced or mandated on a project that you're not particularly excited about. You might come up with dozens of story ideas for a fantasy RPG every day, but that doesn't mean you can churn out a bunch of help text for Career Mode in Madden 2009 with the same gusto.

If you're in a situation where you feel like you have to do a task rather than wanting to do it, you're at risk for becoming creatively blocked. (This is true for students as much as professionals. In both cases you're often asked to do something that feels arbitrary or tedious to you.)


The solution is to find that passion again. Remember the reason why you love your field in the first place, and go do that for a bit. If you're a game designer, spend a weekend making a short game, as in a Game Jam. If you're an artist doing commercial work, do a personal art project on the side. Basically, do something creative for yourself and not for money or a job, on your own time. I realize that if you're in the middle of crunch, this isn't always the easiest thing to do. But perhaps that's just one more reason for companies to avoid crunch in the first place, if they want to keep their people in top creative form.

Sunday, October 19, 2008

Students who Know Everything

If you're teaching a class on rocket science or brain surgery, your students are probably not going to enter your classroom thinking that your class is a waste of time, or that they know more than you about your subject.

Mostly, this is true for game design as well (as long as you, as the teacher, have enough credentials to convince your students that you really do know more than them). But game design is one of those fields that everyone thinks they can do, because it looks so easy... so eventually, if you teach game design, you'll encounter a student who is convinced they know something you don't. You say something in class, and they contradict you, right there in front of the rest of the class. They insist that you're wrong, they tell you exactly why. You state your case for why you're saying what you are, but they aren't swayed. The class polarizes, with you on one side and this student on the other, and neither of you apparently willing to compromise.

And of course, game design is a living field, with varying opinions on all sides of just about any topic. So who's to say that you are right? But then, if you're not, how can you be teaching a class where you don't know the right answers... or where there might even be no right answers?

How do you deal with that?

If the point you're arguing about is actually interesting and you can think of any value in continuing, involve the rest of the class. Ask for opinions. Get a discussion going. Some of my best class moments were completely unplanned: a student once asked which was better, save points or save-anywhere, which launched the whole class into a wonderful hour-long digression that was far more valuable than the stuff written in my lesson plans. In addition to the topic itself, your students also learn how designers discuss problems in the field, whether it's in a classroom or a GDC roundtable.

If the student is hung up on some pointless minutiae like the exact definition of a positive feedback loop, exit the discussion. Defer: "I'd be happy to talk with you more about that after class today or during my office hours, but I don't want to get too caught on this one detail. We have a lot of other things to cover today, so how about you give me the benefit of the doubt and pretend that what I've just said is right, just so we can continue to talk about the other topics in class today, and we can look it up later. Does that sound reasonable?" (Bonus tip: If you ask "does that sound reasonable?" about anything, no matter how unreasonable, the other person will probably agree. Most people find it really hard to tell you to your face that you're being unreasonable when you ask.)

Warning: If you defer, make sure to follow up. Otherwise, you give the impression that you're just trying to silence anyone who disagrees with you, and ideally it's better if your class is your partner in education rather than your antagonist.

If the student still keeps disagreeing, as a last resort you can pull rank. You have the authority to send a disruptive student out of the room (worst case, by calling campus security to escort them out), if the student is getting in the way of everyone else learning. I've never had things come remotely close to that extreme, though.


Whatever you do, stay calm. Remember: if a student is arguing with you about anything, it means they're passionate about your subject (enough so that they're able to overcome the intimidation of speaking out in front of a group, and speaking contrary to a teacher!). Passion is a good thing. This student's passion might be misdirected, but it's still there, and I'd say that's infinitely better than a student who is bored, doesn't care about your subject at all, and just sits in the back quietly (or doesn't even bother to show up to class). So, consider it a victory if your students are confrontational... it means you're reaching them.

Thursday, October 16, 2008

One important difference between Game Design and Contemporary Art

I have a confession to make. Having gone on record as saying that all game designers should study art, I've never actually taken a course on studying art until just now. (I did take a course as an undergrad where we created art using a computer, but I'd never heard of Jackson Pollock or Mark Rothko or Robert Mapplethorpe until recently. This is the point at which any artists in the audience are rolling their eyes, wondering how I got as far as I did... and everyone else is wondering what the heck I'm talking about.)

Now that I'm studying contemporary art, I'm seeing a lot of similarities between art and game design. In particular, the art world has already encountered a number of issues in the past 100 years that video games are only beginning to struggle with today. I'm sure I'll post more about that in the future.

Today, though, I want to talk about one of the few big differences between art and games. It has to do with accessibility.

When most people today see a piece in a contemporary art museum or gallery, their first reaction is: "huh? I don't get it." The reason is that a lot of art isn't trying to talk directly to laypeople; it's artists talking to other artists. If you're an artist and you want to say something about the quality or nature or meaning of art, you don't give a lecture at an art convention, nor do you write an article for an online magazine about art; you create a piece of art that states your viewpoint. And other artists and critics who are already familiar with the current issues and discussions in the field (and who are already familiar with you and your background, culture, and viewpoints) will immediately see your piece and understand what you're saying. It's a very efficient way to communicate, actually. You just do your work and it explains itself.

Game designers don't have this luxury. For us, improving our understanding of our craft is a separate activity from actually making games. We talk about how to make better games through articles on Gamasutra and Game Developer, we give lectures at GDC, or we just talk to people in local IGDA meetings or the like. And then when we're done talking, we go off into our own respective worlds and try to apply what we've learned.

And maybe it's because of the complexity of video games, or maybe it's because a lot of video games hide their underlying mechanics from the player, or maybe it's just that a lot of designers aren't that good at game analysis, but we don't learn much from just playing each others' games... at least, not compared with how much artists get from looking at their contemporaries' works.

Here's an example: suppose you're making a CCG and you want to know the relationship between drawing an extra card and having the opponent discard a card (both of which give the player a one-card advantage). I can tell you from experience that the discard is usually more powerful (by a factor of about 1.5x), unless your game has really weird mechanics. But if you just looked at a variety of CCGs, this isn't something that you'd see plainly. Sometimes it's downright obscure, because cards often have different cost structures, or combine things like drawing and discarding with other effects (which makes for more interesting cards, but also obscures the basic costs and benefits and relative values of the simple things). So, unlike an artist, I can't just stare at the work of fellow game designers to learn how they do what they do. And unlike an artist, I can't just make a great game and have it speak for itself, to the point that other designers will just universally "get it" and be able to make their own games better.

But then, this limitation is also a strength of games when it comes to the mass market. If you haven't studied games, if you've never taken a game criticism or game analysis course, you can still sit down and play a game and have a good time with it (even if you don't understand why you enjoy it so much). But if you haven't studied art, and you go to an art museum, most of the stuff in there will likely go over your head. So, the communication between game designers may not be as efficient as that of painters or sculptors... but on the other hand, more people can appreciate and interact with a game than a painting or sculpture.

Sunday, October 12, 2008

Using Games in Homework Assignments

A lot of my assignments involve either the study of games (sometimes within certain constraints, like games from a certain time period or genre or platform). There are a lot of challenges here. A few pitfalls I've run into and my solutions:

Assignment: Analyze a game from a particular genre.
Problem: Students unfamiliar with the genre will have a difficult time, since they have to research not only the game but the genre as well; this is often accompanied by a perception of unfairness or bias.
Solution: Cover a variety of genres over the course, so that every student will have a few assignments that are easier and others that are harder. Students who aren't hardcore gamers may still feel at a disadvantage. Another solution is to give links or documents that explain the basics of the genre for the uninitiated; you may have to put these together yourself, which is more work.

Assignment: Analyze a game of your choice.
Problem: Even with my pretty extensive knowledge of video-game trivia, about half of the assignments will involve games I'm not familiar with. I then need to research all these games, which is fascinating and educational but also takes time that I often don't have.
Solution: Give a list of a dozen or so games that you're personally familiar with. Choose a variety that are well-known, so that the vast majority of students will have at least one that they already know. For students who complain that they don't know any of the games, you can negotiate with them after class to find a game that both of you know.

Assignment: Analyze this specific game.
Problem: Students unfamiliar with the game will complain, as with a specific genre.
Solution: Choose a game that is sufficiently obscure that none of your students have played it. This is relatively easy if you're studying classic games from before 1985 or so, as most of your students were not alive then :). It's also possible with more modern niche games. In this case, researching the game is considered part of the assignment.
Alternate solution: Time permitting, bring the game in question to class and do a demo and some preliminary analysis in class. Bonus points if you can put the game "on reserve" at your campus library or otherwise make it something that students can play for themselves on their own time.

Wednesday, October 08, 2008

Lessons learned from SIEGE

SIEGE was an interesting experience for me this year. I learned a lot of valueable lessons, many of them related to life and career more than actually making games. Observations:
  • If you get a group of programmers together, they will quietly take notes. A group of artists will sit in their chairs doodling. A group of designers will loudly interact, debate and argue. (Corollary: never schedule a group of programmers to be in an adjoining or shared space with a group of designers, whether you're organizing a conference or putting together next semester's class schedule.)

  • If the conference session you're moderating has the word "Improv" in the title, any number of things can go horribly wrong -- you run out of time, you have to get moved to a different room, you decide to change what you're doing in mid-presentation, whatever -- and participants will assume it's all part of the act, and applaud your brilliance.

  • When a game designer (or student) first starts trying to define why games are "fun" they have trouble even conceptualizing it beyond "I know it when I see it." Then they encounter Csikszentmihalyi's Flow and/or Koster's Theory of Fun and have this huge epiphany: Eureka, all fun comes from learning a new skill! Then after awhile, they enter another stage of questioning this: wait a minute, if all fun comes from skill mastery, why aren't students driven by the promise of fun to get straight A's in all their classes (even the poorly taught ones), since that involves mastery of the material? Why is sex fun (by some standards), and yet doesn't involve mastery (ahem, again by some standards)? At any rate, you could think of this as three stages of evolution of a game designer, and different designers are going to be in different stages, and when they encounter one another there will be chaos when they start discussing the nature of "fun."

  • Another evolution happens during the career path of a game designer. At the beginning, you take whatever work you can get. Mediocre Sequel 2: The Safe Publisher Bet? Sure, I'll take it -- anything to be able to say I worked on a published title. This continues for awhile. In late career (I suspect this is when your published title count gets into the high teens, but it varies with how interesting your random projects have been until then, and it does require you to have worked on at least one brilliant title), you start to realize that your name is now its own IP, and that working on additional failures actually hurts rather than helps you at this point. And for the first time, you start turning down work because you're afraid of harming your own reputation (as opposed to some other reason).

  • Technical artists -- those rare people who know both art and programming -- are worth their weight in gold to a development team. At the same time, many technical artists are not particularly strong in either art or programming. I'm sure there's a corollary here, but I haven't yet figured out what.

  • If you start playing any Eurogame in the hallway at a game development conference, you will soon have more spectators than players. (At one point we actually had more spectators than the heavy-metal band down the hall who were playing the themes to Mega Man 2 in realtime as someone else was doing a speedrun, live. Apparently, Reiner Knizia is geekier than Capcom.)

Friday, October 03, 2008

Speaking at SIEGE

Through a series of random last-minute circumstances, I'll be going down to Siege this weekend. In particular, I'll be running a session with Brenda called "Game Design Improv" which is a series of hands-on game design exercises inspired by our book.

In between sessions, I'll be hanging out with other developers and academics, and possibly meeting some fellow students in the online classes I'm taking. If you happen to be in the Atlanta area, feel free to track me down and say hi!