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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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!

Everything I Learned About Teaching, I Learned From My Field

I talk a lot here about how teaching is really just a special case of game design, and how so many skills transfer over from one to the other. I changed my mind. Sort of.

At a recent teaching workshop, I witnessed about twenty fellow teachers give short presentations on teaching (and they all taught different subjects, everything from English to Calculus to Welding to Phlebotomy) and I was able to learn something from each of them.

Afterwards, I talked to someone who taught Comedy Writing and realized that she could easily give a workshop on "how to use comedy in the classroom" -- after all, comedy is a great icebreaker, it engages students, and it gets them to relax and enjoy the material. It's broadly applicable to any subject, so any teacher should be able to learn something about this field and take it with them back to their classes to make them more engaging. Of course, I've said the same thing about using game design in a classroom. How many other subjects could you say this about?

And as I thought some more, I realized the answer is probably all of them. Every subject has its own specialized knowledge that could be useful in a broader context. Consider:

• Welders and carpenters and machinists learn about safety first, before they even get to touch any power tools. These people could easily walk into a class and point out any number of safety issues that would be invisible to the rest of us. Making sure your students don't hurt themselves in your class by, say, tripping and falling over a poorly-placed wire is certainly something that would be useful. (Not to mention the importance of planning before you begin any project, such as a lesson plan.)
• Statisticians and mathematicians can draw a lot of really cool inferences from numbers, like taking the mean, median and standard deviation of test scores and using the information to figure out where the class is having the most trouble. Wouldn't it be great for any teacher to know, after an exam (if not before!), what topics their students are struggling with... without having to even ask?
• Computer programmers and engineers are great at taking a complex task and breaking it down into simple tasks... the same way that a teacher developing a new course needs to take overarching course goals and learning objectives and break them down into day-by-day sub-goals and mini-objectives.
• Medical technicians have to deal with people in a friendly yet professional manner. So do teachers, except we call our customers students instead of patients. (Some of our other customers, we call deans and department chairs. It's useful to deal with them friendly and professionally as well.)
• Businesspeople and managers have to monitor, predict and direct the behavior of a lot of people at once. So do teachers.

It seems to me that any field has something to bring to the table.

So, I no longer see education and game design as inherently linked. Instead, I see education as a field that overlaps with and touches every other field. Including game design. And since games are my field, that one particular overlap is the one that I'll happily continue to blog and write and speak about. But in the meantime, I would be perfectly happy if folks from other fields would follow suit and let me know what I can learn about teaching from them.

2nd Ohio Game Jam: Results

I coordinated the second Ohio Game Jam this past weekend. I didn't make a game myself, although I did assist all the teams in very minor ways, so I got to see a little bit of everything. As such, I probably learned as much as any participant.

Lessons learned about running a Game Jam:

• Event planning is a lot harder than I thought it was. Last year, everything just fell into place, and there was a minimum of hassle. This year, it seemed like everything was an uphill battle, from finding a venue (which had to be changed last-minute due to a large-scale power outage) to recruiting participants (since I don't have reliable web hosting for the Ohio Game Jam website right now). For anyone else thinking about hosting a game jam, start planning at least a few months in advance and come up with contingency plans for everything. Hopefully the up-front work will be wasted and things will run smoothly for you, but if they don't then you'll be more prepared than I was.
• Things to take care of (either through soliciting donations/sponsors, providing yourself, or asking participants to bring their own): physical space; computers; open work space (for designing on paper); physical prototyping materials (blank paper, lined paper, graph paper, pens and pencils, and anything else you have on hand); food and drink; sleeping space (preferably with no light); and a large area where all participants can gather (for introductions at the beginning, and presentation of work at the end).

Lessons learned about game development:

• It's impossible to understate the importance of rapid prototyping. All three teams knew about this already, and yet they all made the mistake of trying to implement the complete game mechanics in one go, leaving them all with only 4 to 6 hours of time after "first playable." It's very easy to say that it's important to have something up and running really quickly, and quite another to actually do it; defining the minimum functionality set for playability is a skill, and one that not all designers are strong at.
• Corollary: trade off everything for speed when doing a rapid prototype. For artists, no need to have polished art when a stick figure works just as well for playtesting, and can be done in five seconds. For programmers, all that stuff about proper code structure and good commenting and re-use and maintainability that was drilled into you in every CS class you ever took... all of that goes out the window, because it takes extra time to make your code readable, and time is the one thing you don't have.
• Save early and often and back up. Sounds obvious, but one team had a computer crash that caused them to lose about an hour of work... when there was only 45 minutes to go before development ended.
• If you have a programmer shortage on your team, don't design a game that requires complicated game logic or AI. If you have more than one programmer, choose a development tool that allows you to work on code concurrently (two teams used Game Maker, which is hideously bad at merging two projects, for all of its other benefits).
• Game development experience helps in a game jam... but not much. Looking at the output of the teams, you wouldn't be able to tell which ones had industry professionals and which did not. (When I participated in a Game Jam, I noticed the same thing; I don't feel like my own project was any better for all of my experience, which is humbling.) I'm not sure why this is; perhaps, for all the benefits of field experience, lack of sleep ends up being the ultimate equalizer.

For those who are curious, here's the rundown of what happened at the event:
We had 13 people working in 3 teams, with a total of one game per team created (3 games total).
I gave teams a dual constraint: first, choose a social issue and create a game to spread awareness of that issue; second, design the game to be propagated through a social network like Facebook. As long as we're making games, we may as well try to save the world, right?

One team tackled the issue of financial responsibility and personal spending habits. The core concept was that people have two stats, Money and Happiness, and that there is a tradeoff where spending too much money on luxury goods causes you to run out of money (which makes your happiness go way down), but of course spending no money at all on luxuries also causes happiness to decrease, so the trick is to find a reasonable middle ground where there's plenty of money left over but also enough nice stuff to be happy. The game itself was a top-down scrolling game where the player's avatar wanders through a store looking for the cheapest necessity items, and maybe picking up a luxury item or two on the way. There were other AIs running around: other shoppers which were minor obstacles to work around, salesmen who would convince you to buy a luxury item against your will (while giving you minimal happiness in exchange), and thieves who would just steal money from you. The game created was incomplete, but could make use of social networking by allowing players to buy things for their friends (which increases both of their happiness) and competing with others on your friends list for achievements (most money, most happiness, fastest purchase of necessity items, etc.).

A second team examined the environment, specifically choices that governments make with regard to energy policy, in a turn-based resource-management strategy game. You control a small city with access to randomized natural resources, and choose what land to develop in what way (building hydroelectric dams over rivers, wind turbines in windy areas, solar panels, nuclear plants, etc. -- or of course you could develop the land as a commercial/housing area to attract more people to your city). You have a carbon footprint based on your population and the type of economy you have (fossil fuel-based, hybrid or pure electric), and a cap that's based on your population; if you go over your emission limit, you receive heavy fines. If you don't produce enough power for your population, you suffer blackouts and eventually you'll start losing population. You also have to balance all of this building against your available funds, of course. In Facebook, this game would also allow you to trade carbon emission credits and power with your friends, and also have leaderboards for largest city.

The third team took on the issue of child labor sweatshops. In their overhead-view action game, you played a child trying to escape from a shoe factory. You could pick up various shoes lying around each level (with tradeoffs for each: boots were powerful but slow, while flip-flops could be thrown quickly and accurately but did minimal damage). Your goal in each level was to pick up shoes and use them to knock out the adult supervisors, then talk to the kids to get information (which helped you progress in the game, and also gave you real-world information about sweatshop conditions). The game could propagate socially simply by having a high-score list, but did not include ways for different players to interact with one another otherwise.

Online Classes and Readings

Most traditional classes have two kinds of learning: students attend lectures, and they have assigned reading from a textbook.

I say "and" but really for most undergrad students it's an either/or proposition. Lecture and readings are usually redundant, so the students who attend lecture tend to blow off the reading and those who diligently do the reading don't feel too bad about skipping class. This is a generalization; there are plenty of exceptions, students who attend class and study heavily, or classes where the reading and lecture have no common ground. But in a lot of cases, students are conditioned to study as little as possible, and this is an obvious shortcut that can free up some extra time for, say, playing games.

Without going into a discussion of how to change the culture of an entire generation, let's assume that this carries over into online classes and see what happens.


In the online classes I've taught before, there is no "lecture" per se; the lecture has been replaced by... more reading, which was written by whomever developed the online course. So students have reading from the course website, and assigned reading from a textbook. (Visual learners are probably quite happy about this, while auditory learners get screwed, but I digress.)


To a student who sees this parallel of "lecture == course website" the reading again becomes either/or: read the course website, or read the textbook. Naturally, the website wins, so any assigned reading from a textbook in an online class is likely to get ignored by a lot of people.


I never noticed this until recently, when I was grading an assignment for one of the online classes that I was teaching. Most of the students seemed to not understand a particular concept, the difference between constituative and operational rules from the Rules of Play text. It's a difficult concept, granted, but everyone seemed to be misunderstanding it in the same way. What's going on here? Well, I checked the course website to see what it had to say about this concept... and it just mentioned it in passing, giving a couple of examples to supplement the textbook but not really explaining it properly (probably because the course developer expected that students would do the reading). But here's the thing -- you wouldn't notice that the course website's material was supplemental unless you did the reading in the textbook! So all of these students thought they knew what was going on, even though they didn't.


This is, I think, a major hazard for online course development. Here are a few ways around it:

• Warn students early and often that none of the work in the class is optional. (This probably won't work, but at least it makes it harder for students to complain when you catch them slacking.)
• Force the issue. If the graded assignments directly reference parts of the reading that aren't on the course website, students will have to read at least those parts in order to complete the assignments.
• Tape your lectures and put them online, instead of writing text. This requires some extra equipment and technical know-how (and not all course website packages support all kinds of video), but it does at least make it so that the students aren't just doing reading and reading and more reading. If they don't burn through their will to read on the course website, maybe they'll have a few brain cells left over that are willing to take a peek at the textbook. (Bonus: if you already teach a face-to-face class and tape it, your content is easy to develop.)

Choosing a School: Ownership

Question: Who owns the IP rights to games that are created by students?

What to look for: Ideally, the students should own all copyright and other intellectual property ownership of the projects they create while they are students.

What to do: Decide if this matters to you. Some people don't care, because they aren't planning on selling anything they make as a student anyway. Some people care, but they're willing to compromise on this (maybe by just not using their favorite game ideas until after they graduate) in order to go to a school that is otherwise their choice. For some people, this is a deal-killer.

What to watch out for: Some schools explicitly state that they own all rights to all student work. Probably the most notorious example of this was Team Toblo (a good story to read for why IP ownership might matter to you as a student). Other schools do not have an official policy at all, which is a signal that they haven't thought about it yet in spite of it being a legal and PR minefield. In these cases, proceed with caution, because the rights may be legally unclear and the last thing you need as a student is to get involved in a legal battle. Still other schools have restrictions: they own the rights to anything you create using university resources (such as computer labs or printers), but a project you make on your own with your own equipment is 100% yours, so there's a way to own your work if it matters to you. Mainly, the important thing is to be aware of the official policy before it becomes an issue... and if you think the policy is suboptimal and you plan on attending anyway, consider taking it upon yourself to push for policy change.

Update 11/13/2008: The monthly IGDA column on legal issues gives some insight into IP ownership rights of student work: http://www.igda.org/columns/lastwords/lastwords_Nov08.php
Thanks, Jim!

Update 11/14/2008: It appears this is becoming a much larger discussion. A recent Gamasutra article highlights the problem. This blog post is quoted and linked to in the article, alongside quotes from Tom Buscaglia, Brenda Brathwaite and Susan Gold... so I'm in good company. Maybe this will eventually become a big enough issue that the "we own your IP" schools will consider policy changes, and the schools without an official policy will get off their behinds and make their policy explicit.

Assessment and Evaluation

People who study education will talk a lot about the differences and similarities between assessment and evaluation. I'll spare you the details, but basically we're dealing with the question: how do we know that learning actually takes place when a student attends a course?

The traditional response is to give the student tasks (often in the form of a final exam or project), and hope that their ability to perform well correlates with their mastery of the subject material. But there's the rub: what we measure (performance on a task) is still different from our goal (learning). There's no way to measure an abstract, transparent concept like "learning" directly, so we have to find indirect ways to take a guess.

It strikes me that there's a parallel here with game development, and metrics-based playtesting in particular. During playtesting, what we'd really like to do is know if the players are having fun, but there's no way to measure "fun" directly. So, we take measurements of things that we hope will correlate: how long did each tester spend on this level, how many players finished the game, how long was the average play session, and so on. But it's still indirect measurement.

In both cases, we still live in an imperfect world. Someone tell me when we solve one problem, because it probably means that we'll have solved the other one as soon as someone puts two and two together.

Notes from CTL

I recently attended a small in-house conference held at Columbus State called Celebrate Teaching & Learning Day. I admit this is a hokey name; I mean, we do this as opposed to, what, celebrating ignorance?

I gave a presentation based heavily on my Origins seminar, tailored for an audience of teachers who may or may not actually be gamers. But that's not what this post is about. This is about the other seminars I attended and why they're relevant to teaching and/or game design.

Keynote: Dr. Mark Milliron

• Normally I dislike keynotes, because they tend to be abstract and just an artificial excuse to get people excited. They remind me of pep rallies from high school. But this guy had a lot of interesting ideas, making him one of my favorite keynote speakers to date.
• First big idea: the use of analytics (that is, mining a bunch of data and using it to make educated guesses about future behavior) is already an established technology -- some examples being amazon.com's ability to make pretty good guesses of other things you might like to buy whenever you click on any single item, or TiVo's ability to download TV shows you've never heard of that it thinks you'd like, or your email spam filter getting better over time the more you tell it what is and isn't spam. We need to leverage this kind of predictive modeling in academics. Wouldn't it be useful for a professor to receive this email: "Based on past behavior, here is a list of students who might be thinking of dropping your class next week."? Wouldn't it be useful for a student to receive this email: "You seem to be having trouble with this particular concept. Other students who have similar problems have found the following resources useful."?
• Second big idea: using the power of open-source to improve teaching. Pointed us to OERCommons.org, which is essentially Wikipedia for instructors. (Unfortunately, there are currently no learning objects for game design. But if you teach Biology or English or something, you're in luck.)
• Amusing quote: "Most people who use PowerPoint have neither power, nor a point."

"Sage on the Stage to Edutainer": Dr. Bill Dross

• Three different ways that people learn: visual, auditory, kinesthetic. Any given class will probably be split evenly between them. This is probably not news to experienced teachers, but it certainly has applications for game design (e.g. don't just have a page of scrolling text when it's possible to add voice and pictures; see if you can add an icon to each menu item so that they aren't just text; include subtitles for voice, and visual effects to match audio cues).
• In the classroom, you can help auditory learners by recording your own lectures and making them available as podcasts. (If you don't know how... ask your students!)
• Likewise, you can use audio or video recordings during class time. In particular, it's expensive and not always practical for students to attend GDC, but you can at least download some sessions from GDC Radio and make them available on your course website.
• There is a concept in the field of education called "discovery learning" which is when students do research and learning on their own, relatively undirected (similar to a self-paced course, or doing work on a portfolio piece). I see a direct analogy between discovery learning and open-world games like GTA or Oblivion... and a similar analogy between structured lecture and on-rails RPGs. (This all makes me wonder how much information you can get about a student's preferred learning style, simply by asking them what their favorite games are.)
• I use a lot of informal discussion in my classes, but some professors prefer formal debate (which I haven't tried, but now I want to). The idea is to present a controversial issue, and randomly assign students to either be "pro" or "con" (so, students may be arguing something they don't personally believe). Pro always speaks first, then Con (for only a couple of minutes each -- no interruptions allowed by the other side); then Pro and Con again to rebut each others' arguments; then a short break for each side to regroup; then a summary from each side; and then you can determine a winner (perhaps by a randomly-selected panel of students who are made judges instead of speakers). Examples of topics that I'd like to try this method with: government regulation of the game industry, the importance of diversity in the workplace, narratology vs. ludology, or whether the proliferation of sequels and licenses is good or bad for the industry.

"Hybrid Courses: The Best of Both Worlds?" (various speakers)

• I'd never heard of "hybrid" courses before. Apparently these are courses that are half face-to-face, half online (with half the number of normal contact hours in a classroom). Does that mean that they're a mostly face-to-face class with some extra online content? A mostly-online class with a little bit of face time? An entirely new type of class that has some elements of online and face-to-face and some parts all its own? At this point, the concept is new enough that it varies from class to class, which leads to student confusion.
• Best way to avoid this is to make expectations clear up front -- preferably in the course catalog, and repeated at the start of class.
• If you want to draw a parallel between hybrid courses and development of hybrid-genre games, be my guest.

Game Jams!

Game Jams are great; I'm a huge fan of them. (Roughly defined, a Game Jam is an event where individuals or small teams work together to develop a complete game or working prototype from scratch in a short period of time, typically one or two days.) You get about as much insight into the game development process in a weekend as you'd normally get in a three-year AAA development cycle. You get to experiment with new tools, processes, or designs in a risk-free setting (after all, even if you fall flat on your face, all you've lost is a weekend... and think of the wisdom gained that would normally cost millions of publisher dollars). You get to meet and work with new people you haven't met before. For students, it's about the best practical experience you can get outside of class. For educators, it gives the kind of insight that's hard to get when you're not working in the industry full-time. For working professionals, it offers the opportunity to grow professionally and hone your skills in a way that's normally not possible when you're in the middle of a development grind.

For those of you in or near Columbus, Ohio, the second Ohio Game Jam is scheduled for the weekend of September 20-21 (starting at 2pm on Saturday and going until roughly 4pm Sunday). Since there's limited space, I'm trying to get a head count ahead of time, so I'll send the location to people who RSVP by email to ai864 at yahoo dot com. Feel free to pass on this info to anyone else you know in the area. The event is free, and open to all ages and skill levels.

For those of you not in Columbus but still somewhere on Planet Earth, there's also the Global Game Jam, a 48-hour event starting at 5pm Friday, January 30, 2009 (in your local time zone). This event is many Game Jams happening concurrently at a number of sites around the globe. More info will be added to the website in the coming months, once the list of host venues is finalized. Contact info is on the Global Game Jam website.

Textbook Review: Challenges for Game Designers

"Challenges for Game Designers" (Brenda Brathwaite and Ian Schreiber)

So, it's finally printed and in circulation, and you can buy it now. This is the best textbook ever, and all of you should adopt it for all your classes and buy extra copies from your friends.

Okay, so I'm one of the authors. What, you expect an unbiased review?

This book came about because some people on IGDA's Game_Edu list were complaining that they'd love to have students design games, but they either don't have access to computers or their students don't know programming. Brenda and I were both, like, WTF? You don't need any polygons to play Chess. You don't need any lines of code to play Go. You don't need a development team and millions of dollars to make Settlers of Catan, you just need one guy and five bucks' worth of dice and index cards. So, we decided to write a book about making games without computers.

The original idea was just to take a bunch of exercises that we'd both done in our classes, sets of constraints that serve as starting points. (For example, some of my former students still shudder in horror of the time when I had them create a game concept document based on the Care Bears IP after we studied the use of licenses in games.) Before too long, though, we realized it would be unfair to just give these exercises without any help -- it's fine and good for people who are designers already, but to tell a beginning student they should create a full proposal without telling them how is just unfair. So we added a bit of "how-to"... which incidentally made the book take about three times as long to write, but hopefully a lot easier to understand.

The book is 21 chapters, though one of those is just the introduction to the book. The other twenty all have five exercises each (with a full description of deliverables and suggested process), plus another ten "shorts" (quick ideas to get you started or inspired), for a total of 300 game design exercises... none of which requires any art or programming skill at all (although if you do have programming or art skills and want to take your non-digital design and make a digital game out of it, most of these exercises can be used as a starting point).

Students: If you'd like to design games but don't know where to begin, this should be a reasonable starting point.

Instructors: I expect this to be a good companion to a theory-based textbook like Game Design Workshop. Theory is necessary and all, but at some point anyone learning game design must sit down and design games (lots and lots of games), and Challenges for Game Designers is very practical in nature. You could either combine the two in a single course, or teach an introductory theory-based course to give the basic concepts and then offer a follow-up practical course. I happen to think students would understand more if the theory and practice were combined so that the theories make sense and are contextual, rather than just some abstract thoughts that are meaningless until six months later.

Professionals: When Brenda and I worked at Cyberlore, there was a time when we'd have weekly design department meetings (we worked with two other designers). Once a month, we would use the meeting time to do a design exercise; one of us would be responsible for developing the constraints, and the others would struggle with the problem. It was a way to keep our design skills sharp, and it was one of the few times in the business world where you'd hear people say that they were actually looking forward to attending a meeting. I also ran a couple of these exercises over lunch and invited programmers, artists, and anyone else who had an interest in game design; people had fun, and also gained an understanding of the kinds of things we designers did all day. If you work with other designers (or other people who are interested in game design), we designed this book to be useful in these kinds of skill-building meetings and workshops.

Textbook Review: Teaching Videogames

It's been awhile since I did one of these. I just got a new shipment in, but I chose this one first because it was short.

"Teaching Videogames" (Barney Oram & James Newman)

It may seem strange to call this a "textbook" since it's targeted at teachers and not students, but it's a book on teaching and games so of course I had to take a look. It's written by two people with no game industry credits that I could see, it's barely large enough at 88 pages to qualify as a book (at that size it's more like an oversized pamphlet), and they're charging $42.95 for it, so I wasn't in a particularly generous mood when I started reading.

To be clear, this is not a book on game development. It's a book on game studies. This wasn't clear to me from the title, although I suppose being part of the "Teaching Film and Media Studies" series of books (as shown on the cover) should have been a big hint.

What exactly is this book about? It appears to be a primer on games (in the context of media studies) for those unfortunate souls who teach media studies courses, somehow found themselves tasked with teaching a class on video game studies, and feel completely lost because they don't know the first thing about video games. For those people, this book offers an overview of games and the game industry: a brief history of the industry, important types of businesses (developers, publishers, retailers, etc.), ludology and narratology, women in games, and violence in games and its effect on society. It offers workable syllabi for a pair of six-week classes, one on the study of games and one on the study of play, and includes some worksheets that can be given as class assignments (printed in such a tiny font that I had to squint to read it, but thankfully including a link to a soft copy online).

I didn't see any blatant errors; the content is pretty solid for what it is. In fact, my lesson plans for my Game Industry Survey course already contain a lot of this information, so I may not be as hopeless at game studies as I used to think I was. And the book is a fast read, so if you know nothing about video games and need to get up to speed pronto, this is a pretty decent bet. It starts off with a bit of academic jargon in the first few pages, but quickly lapses into a more readable, conversational tone.

That said, the book has what I see as a major conceptual flaw, and it's something that has probably been bugging some of you since a couple of paragraphs ago: this is written to assist those who are teaching a game studies class, but don't know the first thing about it. So I have to ask... for those who don't know anything about a subject, why are they teaching it in the first place? This book doesn't qualify someone to teach a class in game studies, any more than reading the Cliffs Notes version of Hamlet would qualify me to teach a class on Shakespeare in the English department. A teacher who knows nothing about a subject should not teach a course in that subject. Period. Am I the only one who thinks this? Am I oversimplifying? At any rate, it seems to me that if someone needs this book, then really they don't need the book, they need to not teach the class. So I'm suddenly not seeing the point of this book existing in the first place.

For those who teach game studies and are fully qualified, most of the content in this book is a waste of time, because you know it already. You won't see anything new. About the only thing that might be of use is the worksheets and lesson plans, which amount to maybe a tenth of the total book, and you can probably find more and better content in the IGDA Edu Curriculum Knowledge Base. The best reason to buy this book, then, appears to be the picture of Lara Croft wearing glasses and looking all educated on the front cover.

Students: Ironically, I think the people who would get the most use out of this book are students who are contemplating a Game Studies or Media Studies major. The book is short, it's easy to read, you can skip over the academic parts, and it'll give you a head start for your Game Studies 101 class (and give you some idea of the kinds of things you'll be studying). Just be aware that neither this book nor any related course of study will actually help you to make games, it will only let you study them.

Instructors: As mentioned above, either you don't need this book (in which case, buying it is a problem), or you do need this book (which is itself a problem). I did think of one edge case where the book might be useful: if you're teaching a more general Media Studies class (comparing and contrasting various media and how to study them) and you want to include a week or two on games but you're unfamiliar with this medium, then this book would be suitable for you to build that content into an existing class.

Professionals: If you're a practicing professional who knows all about making games but you never actually got to take any game studies courses in college (because you were too busy learning game development), and you'd like to read the books out there like Rules of Play except they're too big and intimidating to fit into your busy schedule, this will give you the quick-and-dirty introduction you're looking for.

Culture Shock: Deans and Heads and Chairs, Oh My!

When I was a student, my only real faculty contact came from my professors. Sure, there were all these other people out there with titles like "dean" and "department chair" and "provost" but I never had any dealings with them, nor did I have any idea what they did. I had no concept of departmental politics or inter-departmental territorial disputes; I couldn't see beyond the exam next week.

Now, as a faculty, I see all this stuff (even though I sometimes wish I didn't... sort of like if you enjoy eating sausage and then see how it gets made). But it occurs to me that it's still off the radar of most students (and, indeed, most industry professionals who have some dealings with educators).

I'm not sure what, if anything, to do about it. Part of me feels like students should probably at least know who the dean of their department is and why that matters. Maybe the non-teaching faculty should do more to have contact with students in informal settings (not that they would necessarily have the time, with their overloaded schedules)? Or maybe the teachers who have a lot of student contact should speak a little bit about departmental issues in their classes so that the whole thing is a little more transparent?

Difficult Assignments

As a student, whenever I received an obviously challenging assignment, my first assumption was that the professor was a sadist who just enjoyed seeing students fail. (Apparently I'm not the only one; typing "sadistic professor" into Google gives 755,000 hits.)

Being on the other side, I do give challenging assignments in my classes, and even difficult questions on quizzes and exams. But I do it for the opposite reason: it doesn't give me any joy to see a student fail (quite the contrary), but it does give me great pleasure to see a student encounter a really tough problem... and then they succeed.

Culture Shock: Student Passion (or lack thereof)

I've recently mentioned the lack of passion I've seen in teachers, compared to that of game developers. It occurs to me that the same complaint can be made of students.

Admittedly, this is largely the teachers' fault. How hard is it to get excited about something when you're learning from someone in the field who just isn't excited about their own work? Still, it's a bit of a surprise for me, coming from a job where everyone is working together as a team to make games... and seeing students working in a totally different way.

In the game industry, at least on the projects I've worked on, most people care about the project. Sure, if you work really hard to finish the work on your plate, your "reward" is to get even more work piled on you. So if you're cynical, you could say that the best "strategy" is to just do the bare minimum you need to not get fired. After all, you're salaried, so it's not like working harder actually means more money or rewards or anything. And yet... that almost never happens in practice, because the real reward is that your game is better. And if you care about the game, and you want it to be a good game, then you'll do whatever you can to make it the best game you possibly can. If you don't care about the game... well, there's a whole big software development industry out there that has nothing to do with games, which will pay you more money for less work. So people don't tend to become game developers unless they have this drive to make great games.

You'd think that the same would be true of game dev students, wouldn't you? Put a group of students together to make a game, and you'd expect them to all work insane hours and do everything they can to make it the best student project ever. After all, it's not like students can't do amazing work.

But in practice, you don't always see this. Sometimes you get an outstanding student team (usually the result of a single outstanding student leader who pulls the team together, and if you removed that one student the whole thing would collapse). But I'm seeing a lot of cases where this isn't happening at all. Some students don't show up for meetings and don't do any work at all -- as if they wanted a free ride, just a grade, and they don't care that this project is something that could go in their portfolio and get them a job (among other things). Students make excuses about why their work is late, when I know full well it's because they were just goofing off and procrastinating, a sign that they don't really care much about their project (they just see it as classwork, not an original project).

I'm still trying to find ways to make sure students get it, that game projects are an opportunity to create something experimental and new and different and original and really really cool (possibly the last opportunity they'll have for the next ten years of their career), and that they should really care about it. But I feel like it's an uphill battle sometimes, like I'm fighting against a dozen years of "education" that teaches students to jump through hoops for a piece of paper with the attitude that the real stuff comes later after graduation.

And it's a bit of a shock for me, even now, because I don't have to deal with this in the industry. I don't have to ask the programmers on a big-budget game to show up to work and give their best effort, because they already do.

Random Teaching Bits

I recently attended a teaching workshop. (Irony: during the day, as I was learning to become a better teacher, I totally blew off the online class I'm teaching.)

Here are some takeaways I got from the session:

• Normally at the beginning of a course, I ask students what their expectations are. This is good; it gives them ownership over the contents, and ensures that everyone's taking the right course for them. However, there's a problem: most of the time, my students don't know to expect, so they say nothing. Possible solution: ask where they see themselves ten years from now if they continue in this field. What skills do they expect they'll need and use? This lets me deal with student expectations about the course and the industry at the same time, and a greater number of them will have something to say in response since they all probably have some image in their head (no matter how inaccurate) about What It's Like Out There.
• Another problem I run into occasionally is a student who is having issues outside of class and it makes their coursework suffer, but I don't hear about it until after the fact. Solution: address this on the first day of class as a matter of policy. I particularly liked how one professor put it: "my job (as a teacher) is to help my students succeed, and I can't do that if I'm not kept in the loop."
• Lastly, part of the process of mastery and learning is feeling really stupid at times, and this is something that I don't think occurs to a lot of students (especially if they've excelled at all of their classes before). Really, the more you know in a field, the more you realize that you don't know. Once you master the basics, that's when it starts occurring to you that there are all these unsolved problems, and all these new ways to put things together. As a result, the smarter you get, the more ignorant you feel. Corollary: if you feel like a total moron, it probably means you're learning something!

The Importance of Keeping in Touch

I recently had a conversation with Alex, a former student of mine who made it in the industry (and totally deserves it, and I mean that in a good way). He's just finishing up his first project, so I took the time to get in touch with him and -- without having him break any NDAs -- did something of a post-mortem on his college education.

It occurred to me afterwards how useful our conversation was. As a teacher, I get some feedback during the education process but I get precious little after the students leave campus, so how am I to evaluate if my teaching is useful? An hour on the phone was worth a hundred end-of-course evaluations.


The biggest takeaways I wanted from the conversation:

• Did he enjoy the job? What were the best and worst parts? (This gives me additional content for my classes, either with a real-life horror story or success story, and some people might actually know him so the stories are more credible.)
• What was it like working on the project? (This tells me how obsolete I am. For now, at least, his experiences were similar to mine... so my descriptions of what it's like out there as a newbie are still valid for now. Whew!)
• What were some challenges they ran into in the project? (This is also an obsolescence gauge, and it tells me if I'm teaching the right skills based on whether I have course assignments that mimic real-world challenges.)
• What were some things that he encountered in the industry that I just totally failed to prepare him for? (The scariest question to ask but the most important.)

Anyway, I would encourage other professors and recently-graduated students to do something like this, especially at the time when the ex-students are just finishing their first project and have some time to reflect. Professors: initiate the conversation, as some students may be too busy or intimidated to just open up and start criticizing you after they're gone. Students: initiate the conversation, as professors tend to keep busy and have lots of things going on at once, and it'll be much easier for them to have this feedback if you open the door.

For what it's worth, my two big takeaways from this for myself:

• What went right: the importance of learning a new genre. Alex had never even heard of the genre they were creating before (tower defense games) and he had to learn really fast! This is a common thing in the industry for new designers, and being able to research a type of game they've never played before is a great skill to have. I had my students create a user interface for a modern football game, given the (correct) assumption that most of them weren't that familiar with sports games... or sports, for that matter. There's even an entire chapter in my book on how to work with an unfamiliar genre (Chapter 12).
• What went wrong: I didn't place enough emphasis on Excel in my classes. Sure, I said plenty of times that Excel is to game designers what Microsoft Visual Studio is to programmers and that students should do everything from keeping game stats to their checkbook and grocery list in Excel just to get familiarity with it... but how often did I actually give a game design assignment that required the use of Excel? Almost never. And I never gave any lectures on advanced features of Excel that are useful for game designers (like the use of RAND, RANK and VLOOKUP to create a randomly-shuffled deck of cards). I could probably offer an entire course in "Excel for Game Designers" but failing that I should at least have a few homework assignments that require it.

Updated Labels

As long as I'm on a blog-housekeeping kick, I've just bitten the bullet and added labels to all old posts, so if there's a particular post of interest you should hopefully be able to find similar posts this way. Enjoy!

I have a feed

Several people have asked me in the past if I have some kind of newsfeed for this blog. I had no idea. It's kind of like when someone asks you for your phone number, and you can't remember because you never call yourself.

Brenda kindly pointed out to me that I do indeed have one, and it's here: http://teachingdesign.blogspot.com/feeds/posts/default

So, for anyone wondering how to subscribe, there you are.

Bloom's Taxonomy

In the past, I've said that there's a direct link between education and game design. Mostly, I think about things that teachers can learn from the field of game design (because in my experience, a lot of teachers have trouble with something that games do really well: actively engaging the players/students). But this is my bias, because I have a lot more experience designing games than I do teaching. I'm just now realizing that game designers should be paying more attention to the field of education as well.

Case in point: Bloom's Taxonomy. Most game designers have never heard of this. I've heard it referenced often when teachers are talking to other teachers about their field, so presumably it is to education what the MDA Framework is to game design.

What is Bloom's Taxonomy? Long story short, it's a model for how we learn. First, we memorize a bunch of facts without really understanding them; then we start to understand what these things all mean, and we begin to actually use them to solve known problems; eventually, we learn to analyze new problems and solve them too, and if we stick around in a field long enough we learn to put existing tools, models and techniques together in new ways so that we can solve some problems that couldn't be solved before; finally, we get to the point where we can not only solve our own problems, but also evaluate other people's work in a competent way (which is something that, ideally, all teachers are capable of... but I digress).

Bloom's Taxonomy is important in teaching because it helps you to think of appropriate ways to design your courses based on learning goals. If you want your students to emerge from your course with the ability to analyze problems in your field, you're not gonna get there if all of your assignments and tests simply require rote memorization. On the flip side, if your goal is for your students to be able to apply knowledge to solve specific types of problems, then asking them to make abstract value judgments on other people's work is probably too advanced for the level you're teaching.

But enough about teaching -- think about this in terms of game design. Bloom's Taxonomy describes any kind of mastery... such as the act of a player mastering a game:

• Knowledge = learning the basic controls and mechanics of the game
• Comprehension = learning to use the controls without looking at the manual every 5 seconds; understanding the challenges that the game is throwing at you, and the general nature of what you must do to overcome them (whether you're capable of doing so or not)
• Application = advancing in the game, using your skills to "beat" an enemy, boss, level, etc.
• Analysis = optimizing your gameplay, e.g. choosing the best combination of skills, items and equipment for your party in an RPG. In other words, powergaming.
• Synthesis = finding new methods to optimize your gameplay with. The player innovation in MMORPGs of calculating "damage per second" as the ultimate measure of strength is an example of this. Anyone can use damage-per-second, but to come up with the idea in the first place required a pretty deep understanding of the game.
• Evaluation = at this point, I think we see a solid division between your average gamer and someone who has crossed the line to being either a game reviewer, critic, or designer. This would be the ability to look at several similar games and decide which one is "better" in some way (more fun, more balanced), while being able to back it up with solid reasons.

As a game designer, this has clear applications. Most games do not make use of all of these steps; a simple retro-arcade twitch game never goes beyond application, while only the most open-ended experiences lend themselves to any synthesis tasks. And this is fine, but it helps to explain why, say, a retro-arcade twitch game with an inventory/equipment system, multiple character classes, multi-level tech trees and such would probably not work.

This also explains what you need to do if you want to create an open-ended game where you expect players to find their own unique solutions to your puzzles (as in Thief or Portal). You have to work up to it, first taking your players through the knowledge, comprehension and application steps and making sure they're comfortable with those (perhaps by forcing them to: making it so that they cannot progress until they have mastered the basics). Only then can your players impress themselves with their own ingenuity at putting two mechanics together in creative and unexpected ways. Just giving the players all the tools up front and letting them play won't work, any more than giving your players a stack of equations on the first day of Physics 101 and then expecting them to "put it all together" and build a working rocket.

New Blog on Game Design Textbooks

Game educator Malcolm Ryan has recently started a blog about books that are useful for game designers. He is planning to review one book per week until his bookshelf runs empty. So, it's no longer just me doing this, which is great because the more critics we have, the better (given how many horrible books there are out there).

So, let's all give Malcolm a warm welcome.

Challenges for Game Designers

So, the book I've been writing with Brenda is almost done. We're going in to print this week, which means it should be available soon thereafter.

Description:

Game designers, like other artists, get better with practice. "Challenges for Game Designers" is a series of creative exercises based on real-world problems, allowing the aspiring and practicing game designer to hone their craft without taking the time and risk inherent in a full game development project. Well-known game designers contribute their own unique solutions, allowing a window into their thought processes. While most books in this field admit that a game designer must regularly design games, no other book gives the reader, whether student or professional, a starting place to practice their essential skills. "Challenges for Game Designers" is nothing but practice, making it an essential book on any designer's shelf.

The book came about when Brenda and I witnessed some other game educators asking if there was any way to teach game design that didn't require getting involved with computers and programming. Yes, of course you can, but there weren't any books that would really give a list of exercises that you could use for practice. So, we made one. The entire manuscript took about 6 months, so we probably set a new land speed record.

If you're interested, you can order it here, among other places. If you're an educator, contact the publisher for a free desk copy. If you're still making up your mind, the book also has a companion blog that you can view for free here.

Design Challenge on GameCareerGuide.com

Apparently someone at GameCareerGuide was paying attention to this blog, because Jill Duffy took my game design assignment as inspiration for a full-fledged design challenge: create a player aid for RISK.

So, if you're interested in trying it out for yourself, head over there and read it, and then submit your work on their forum.

Another class assignment

A teacher presented this as an assignment in a college Economics class. I think it would work well in a game design class as well, but this makes an interesting point: "design a game around the subject material" is actually a great assignment in any school subject.

This particular assignment had two parts:

• Form groups. In your group, design a game, or mod an existing game (in this case, a game that uses economics to drive its core mechanics, but replace whatever suits you).
• Then, give your game to another group, and receive a game from a third group. Playtest the game you're given, find the holes, and provide meaningful feedback.

This assignment gives practice in designing games, and also critically analyzing them, and also receiving constructive feedback on your own designs.

A Game Design Assignment

Another teacher of game design mentioned this at Origins:

Take a relatively complex board game (say, Puerto Rico). Design a player aid for the game.

This forces students to exercise the following skills:

• Reading and understanding the rules! This is actually a difficult task, and going through the process involves understanding that games are composed of rules, and learning how the different rules can work together. Students who play through the game instead of merely reading a rule sheet will learn that the dynamics of a game set in motion are sometimes very different -- and sometimes easier to understand -- than the static nature of a written document.
• Learning how to explain the rules to someone else. This doesn't just mean writing a manual, it means making the game easy enough to learn that you don't need a manual. (Consider all of the video games today that do such a good job of teaching the player in the first few levels, that the written manual is superfluous.)
• Evaluating the User Interface. Players must decide what parts of the game are the most confusing or intimidating. What is hard to use? What aspects of the game are unclear? This also requires the ability to conceptually divide the game into its component parts, and see the relationship between the mechanics and the UI.
• Improving the UI. Once a problem is identified, the student must come up with a superior solution. In this case, it involves adding a new component: a player aid or quickref sheet of some kind, meant to simplify some confusing aspect(s) of the game. Oh, and of course you have to design the player aid so that it is itself easy to use, and doesn't make things more confusing.

And for all this thinking, the actual work output is simple: a small piece of cardboard or a single sheet of paper, perhaps. And that's the beauty of it: students learn that sometimes, a huge amount of work goes into a very small component of the game, but that component ends up making a huge difference in the player experience.

As an alternate, more advanced assignment, find a game with long, difficult or confusing rules and have students rewrite the rules to be more clear and concise.