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.