Culture Shock: Iterative Design is not Iterative Design

When designing a game, most people at least give lip service to the concept of iteration: that is, no one gets it right on the first try, EVER, so build some time into your schedule to make major changes that you'll find along the way. It's the game developer version of the saying from engineering, "build one to throw away". I'm sure other fields have their own jargon for essentially the same thing.

Of course, with games (especially for console), once you ship your game you're done. No more iteration for you! If you're lucky and the original game is Good Enough, you might be able to improve some things in the sequel... but you can never go back and actually change the first one. "Remakes" of old games are incredibly rare.

Designing a class is just the opposite. I taught Game Industry Survey once already, and I'll teach it again two more times this year. Each time, I get to look at the results from previous classes and iterate on the design, improving weak points, tweaking the grading system, updating the content, and generally making the whole thing better. And I get to do this again and again, with fresh students each time who don't have any previous experience with earlier versions.

This property of classes encourages risk-taking. I can do something crazy like make each homework worth a hundred thousand points, and if it doesn't work then I can just apologize to the current class and change it next time around. It's quite a different environment from the risk-averse environment of the game industry, and the only thing that changes is that I get to redo my work after it "ships".

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Winter Break is a Hoax

With only one week between the Winter and Spring quarters, I effectively need to prepare for all of my Winter and Spring classes right now. This involves two brand-new classes, plus the administrative details of the classes I'm repeating (like changing the dates on the syllabus). I also have some short-term industry contract work, and some game-related R&D that I'm supposed to be doing at home.

So far, I've been about as busy as I was during Fall.

I always thought that whole "22 weeks of paid vacation per year" thing sounded too good to be true...

Fast Group Board/Card Games

One of my courses this Winter will focus on the rapid design of game concepts. While most of the games will be digital in nature, I think it's important to have at least some grounding in physical card and board games, as the boardgame industry has permanent ties to the video games (for several reasons).

One project I'd like to do will involve eurogames, and in particular I'd like to demonstrate a number of these games in class. Ideal games can be played with a large number of people (6+ "players", with the ability for several people to play as a single team), have simple rules that can be explained in a minute or two, have a total playing time of 15-30 minutes or less (although for games with multiple rounds, 15 minutes or less per round is acceptable), and can be played without specialized components (in case I don't actually own it in my collection and can't find a copy in time). Oh, and it should be fun, at least for the first few times.

So far I've come up with 6 Nimmt, Diamant, Circus Flohcati and Tutankhamen. If anyone has other suggestions, please post a comment here. Thanks!

Teaching: Groups of Three

With my first set of courses done, I'm looking ahead to the next set. One course in particular offers an interesting challenge.

The course is basically a set of game design exercises, meant for small groups (three or four; I think five would be excessive). Each exercise would go something like this:
Tuesday in class: We play a game or set of games, and analyze them from a game design perspective. The choice of games is relevant to what we'll be doing for the project.
Tuesday-Thursday, homework: Students perform some kind of preliminary market analysis that will be relevant to the project, so they won't be starting from square one. For example, if they'll be designing a game to fit a license, this is where they'd take a look at the license.
Thursday in class: Project is assigned. Groups brainstorm ideas together, and submit their best idea at the end of class.
Thursday-Tuesday, homework: Groups take their best idea and flesh it out into a full concept (one or two pages). Something that would be presentable at a business meeting.

Now, the obvious problem here is that it's an awful lot of work outside of class.

Here's what I'd like to do: delegate the homeworks to one person in each group, and rotate it around. With groups of three students each, and nine projects total in the course, that means each student would have a total of six homeworks, none more than a page or two. Much more manageable.

But what do I do if the number of students isn't divisible by 3?

Culture Shock: Class Post-Mortems

In the game industry, it's traditional to do a post-mortem at the end of a project: everyone on the development team sits down and tries to identify what went right and what went wrong, as a way of avoiding past mistakes on future projects. I wanted to bring that same spirit to my classes, particularly the one that I'll be teaching again immediately after winter break.

Now, in both cases, brutal honesty is hard to come by. If you're working on a development team, your desire to be honest for the good of the company is tempered by your desire to not tell your boss why he sucks. Likewise, it's hard for students to tell a professor why his class sucks if he hasn't yet submitted final grades. So that much, I'm used to.

That said, there's a self-selection bias that exists in a classroom but not in industry. That is, at a game company everyone on the team shows up for the post-mortem, because it's part of their job and they're getting paid for it, so the people who got burned on the project will be there as advocates for change. After a class is over, the students who hated the experience are going to leave as soon as possible; they don't want to stick around for a post-mortem. The only students who remain will be the ones who were already loving the class and don't want it to end, so any comments will be skewed very positive. Meanwhile, the students who struggled and had real issues won't be there to let me know, so I'm likely to repeat my mistakes by catering to a certain breed of student while possibly alienating others. (Don't get me wrong. The students who participated made some great suggestions that I'm going to implement next time around; I just want more information from a wider range of perspectives, because that tends to lead to more surprises.)

I suppose that's what the student course evaluations are for, but I don't really trust those either. Many students don't take them seriously and will comment more on the professor's hair style than teaching ability; also, it doesn't give me the ability to ask targeted questions ("what do you think about Homework #4?") so the comments may be too general. Oh, and I had my evaluations done about two-thirds of the way through the course, so anything that happened in the last third won't be represented on the evals.

I was thinking of perhaps using class time to conduct a post-mortem, as a way of forcing the issue, but then I'd have to remove something else -- so I'd be cheating my current students out of valuable class time, in order to benefit the students next quarter. Not really fair.

Any other ideas of how I might get honest feedback from all my students -- both the ones that love the course, AND the ones that hate it?

Final is done!

Overall, it went very well, and I'll definitely consider this style of game-demo-exam in future classes. Things I learned, in no particular order:

• I'm not exactly a whiz with video cameras. Even though the final was taped, I have no idea if it recorded sound, or even if it recorded at all, so it's a good thing I wrote everything down as I went.
• Preparation is key, and I didn't do enough of it. In particular, I forgot to make sure there was a PS2 in the room, so I had to take a short recess in order to hunt one down and connect it. Time was very short, and delays like this were deadly.
• Students were absolutely terrified going into the exam; this comes from the prospect of being asked only two or three direct questions, and what if I draw a total blank? As soon as we started, everyone was much more at ease -- it felt a lot like the discussions we've had in class all along -- and I think many of them forgot they were even taking an exam :)
• Students had a tendency to repeat each others' answers, weighing in with their opinion, apparently forgetting that I was only asking for NEW information. These took up a lot of time, particularly on open-ended questions in which everyone had an opinion they wanted to share. I need a new rule to prevent getting bogged down on a single question; I'm considering limiting the "buzz-in" responses to something like three per question instead of unlimited.
• I realized when I had asked a single round of questions that we were about an hour and a half into a two-hour exam, and decided on the fly to go immediately to the "lightning round", and then ask some bonus questions (individually written responses on index cards) with whatever time we had left. This ended up being a reasonable way to deal with time pressure. Unfortunately, it did mean that there was more of a focus on older games (and more class lecture, less reading and terminology) than I'd have liked.
• This really only works with a very small class (<20),>
• Ask the most interesting and thought-provoking questions first, so students can get into the spirit of the exam and really start paying attention. Save the most fun, entertaining questions for last, so students will leave the exam (and the course) on a positive note.
• It helped to talk like a gameshow host, referring to students as "players" or "contestants", asking for a round of applause for our sponsors, and having parting gifts. First because it sounds so ridiculous that it really removes tension, second because it makes the video camera in the room feel more natural.
  

Marble Sadness

There are times in your life when you realize that it's nearly impossible to share some experiences of your youth with the next generation.

Those kids who saw the Star Wars movies starting with Episode I (instead of IV like the rest of us) will never be able to experience that shock of finally realizing, after all of the conflict, that Vader is actually Luke's father. You just can't un-see the new trilogy to experience the old trilogy with a clean slate.

Similarly, a couple of weeks ago I found (to my surprise) that most of my students had heard of Marble Madness, a wonderful arcade game first released around the time that today's college students were just being born. Why? Because the game has been ported to just about every console machine Atari could get its hands on. My students haven't seen an arcade model (many didn't even know it was an arcade game), but they've seen the NES version.

This is a shame, because there has never been (to my knowledge) a decent port of this game to a home system. The great thing about this game is its play control: you roll this heavy trackball and your marble on the screen moves in the same way. Converting it to a d-pad control simply doesn't work, because it removes that visceral rolling that forms the core of the game; it's like playing a dance/rhythm game with the sound turned off.

So, all of these kids today think of Marble Madness as this mediocre race game for console with lousy play control, not as a perfectly wonderful arcade game with the curse of never surviving a port intact. And that makes me sad.

Teaching Backwards

Due to low enrollment in one of my Winter courses, the focus of the course has changed to something completely different. This happened all of a sudden at the very end of classes this quarter, so it's a bit unsettling.

I'm excited about the content though. This will be a pure design course, with no art or programming to get in the way. It's project-based: students will work (probably in groups) on a set of exercises. I'll cover some physical card and board games, and some paper designs (and project proposals) for digital games. I plan to keep the students on their toes by offering them interesting sets of constraints; I did this before on a semi-regular basis at Hi-Score, so expanding that into a full class shouldn't be too hard.

Here's the strange thing, though. This Fall, I taught a course about rapid prototyping and iterative design, from a technical game design perspective; this was a course where students were expected to actually implement their ideas, sometimes doing some light programming or scripting in the process. It's a pretty advanced course for undergraduates.
Meanwhile, this Winter I'll be teaching a practical game design class. And this Spring I'll teach a game design class that covers the theoretical foundations of the field.

Through a set of circumstances outside of curricular matters, I'll teach these courses in the reverse order that students should be taking them!

Lesson learned: next time I'm introducing a new set of courses to an existing curriculum, offer the lower-level ones with fewer prerequisites first.

Culture Shock: Going Independent

Occasionally, a jaded game developer gets fed up with harsh industry practices and decides to strike out on their own, starting their own game company to make their own games. This usually involves moving to a cheaper apartment and eating ramen for awhile.

And occasionally, I'd imagine a jaded university researcher gets fed up with stuffy academic bureaucracy and decides to strike out on their own, doing research as a commercial venture. This also involves ramen, unless they manage to secure a grant first.

If a teacher decides they've had enough of the system, though, there's not much they can really do. Tutoring, maybe, but it's not really the same. I suppose it's because academic programs are accredited; you could start your own university, but it takes millions of dollars, and there's no easy way to do it "on the cheap" that I can tell.

Not that I'm looking to do any of this, mind you. It's just one of those differences I noticed the other day.

Final exam rules are finalized

Just finished writing up the rules for the interactive final. I'll hand them out in class Monday, but you get to see them here first!

• Students get assigned a unique random number from 1 to 17 (there are 17 students in the class). Randomizing prevents anyone from arguing that I intentionally gave them harder questions, or that they got screwed by sitting next to the wrong people.
• Starting with #1 and incrementing, each student is asked a question. (Most questions will be about a particular game that I'm demoing at the time). The student gives their best answer. Answers are scored as a normal test question.
• After the student in the "hotseat" is done, anyone else may raise their hand to elaborate or disagree. If several students want to chime in at once, start at #17 and decrement. (In this way, a particularly bright student who keeps completing everyone else's answers can't keep control of the spotlight -- once they answer out of turn, everyone else gets a shot before they can try again.)
  
• For those parts of the answer that the student elaborates on correctly, they split the points with the "hotseat" person, 50/50. In this way, the final is collaborative; even if you don't answer your own question fully, you can reclaim some of those points with help from other students. At the same time, students who answer other people's questions can get above 100% on the final. I expect this to have interesting ramifications on students' study strategies...
• For those parts of the answer that the student elaborates on incorrectly, they lose a quarter of the full points (i.e. half of what they would have been entitled to). This is to discourage random guessing. Educated guesses are encouraged (I hope), since it's a 2-to-1 ratio of gains to losses.
• If a student doesn't show up for the final at all, the questions that would have been theirs instead become bonus questions for the group. Everyone gets to answer on an index card, with points given (or taken away) as if they had answered out of turn. Students can choose to only answer partially, or not answer at all.

Time permitting, I'd like to add a "lightning round" at the end, quiz-show style: rapid-fire questions, all with very simple, clear answers, directed at each student in turn, with no answering out of turn. This will be the ideal place for those little tidbits of information that I want everyone to know about the industry, but that can't be demonstrated easily by playing a game.

The final is 2 hours long, which is frighteningly short if I'm asking even just two questions per student (it comes out to about 4 minutes per question on average, including time for me to ask the question, time for the student to answer and time for other students to chime in out of turn). Not sure what I'll do if I run out of time; I'll definitely be practicing everything ahead of time to make sure that I can breeze through my own parts, at least.

So, that's what I've got right now. I'd love to hear your comments.

Teaching: Oh yeah, study sheets!

One of my classes has a final exam. I was planning on actually designing the thing next week, since there's a solid week between the last lecture and the date of the final and I'll have nothing else to do in that time.

Until then, I was planning on working hard to get the last of the grading done, so students will know their grade going into the final. I always liked that as a student, being able to compute exactly how well I need to do on the final to get what grade. I'd like to do that for my students. But I don't really have time to do that AND come up with all of the questions for the final exam.

But then I realized I should really give out study sheets for the final exam (I'm ashamed that I had to be reminded of this by a student). But in order for those sheets to be accurate, I have to know the content of the final...

So, I either have to keep students in the dark about their grades, or keep them in the dark about the final exam, or take a guess of what content I'm going to test on the exam and then try to stick to that. I'll probably do the latter.

Now I know why in some classes, the study sheet would bear no resemblance to the actual content of the final... it's because the final wasn't written until after class was over!

Elementary Schools

Sometimes, just when I feel like I'm too old to be in touch with my students, they surprise me.

Today they surprised me by recognizing Math Blaster, Number Munchers, Carmen Sandiego and Oregon Trail from their own early childhoods. (This is, like, ten years after MY early childhood when I experienced these games.)

So, apparently the classics never die. Or maybe elementary schools are just hopelessly behind on the technology curve. Or maybe we just haven't had any decent educational games in the past ten years. Either way, it means something.

The Game Industry Hates My Students

This Tuesday, Final Fantasy XII is released. One week after that, Guitar Hero 2 hits stores. Two weeks after that -- just in time for finals at my school -- it's the Nintendo Wii. Pretty much everyone in my classes is holding their breath for at least one, if not all three of them. So am I, for that matter.

In theory, in the middle of all this, I'm supposed to be assigning work for my students to do. As if they're going to be the least bit productive with all these wonderful distractions.

It would be so much easier if actually playing the games was the homework assignment. But I know another professor who tried that, only to find that one of the assigned games was delayed a few weeks. Oops.

At the very least, I'm not going to have any time to play these games myself until winter break, so I'll have to make it a policy that anyone giving spoilers in class immediately drops a letter grade :-)

Designing an Interactive Final Exam, Part 2

The other half of an interactive final is, of course, the content. So, this one goes out to all the developers and teachers out there:

Topics in the course include:

• business models in the industry
• the process of making games
• history of the industry (including its roots in board games)
• current events
• emerging fields (game journalism, serious games, etc.)
• academic/industry relations.

I'll be putting together a list of questions I can ask on these topics, and find ways to work it in to a discussion on some particular game or other. For example, I can show a game that didn't do well in the marketplace and ask about WHY it didn't do well (maybe it had poor graphics for its time, or maybe it was overshadowed by a major event, or maybe it had poor marketing, or maybe the development team didn't do its job properly). In some cases, actually playing the game can provide some clues here, and I'll choose my examples carefully.

If you have any ideas for good questions to ask (and games to go with them), or good games for discussion (because they have a lot of unique properties), send them to:
ai864 "at" yahoo "dot" com

Please don't post them here in the comments. I don't know if any of my students read this or not, but I'd hate to give an unfair advantage to those who know how to use google :-)

Designing an Interactive Final Exam

I gave my students a choice: a traditional pen-and-paper exam with the standard true/false, multiple choice, matching, fill-in-the-blank, essay... or an interactive final exam which is obviously more experimental. Absolutely NONE of the students opted for the traditional exam, even though it would probably be easier (or at least, easier to prepare for).

This is good, because now I only have to design one final exam and not two :-)

My first task as a combination game designer / instructor: come up with a set of rules for an interactive final. So far I have:
* I'll demo a series of games, retro and modern. For each game, I'll point out certain aspects of the game and then ask related questions to each student in turn. So, it's kind of like an oral exam. In a group. With games.
* After a student answers (or is unable to answer), other students can elaborate or disagree for extra points.

If you have comments on the rules, feel free to post them here.

Culture Shock: Competition

The old joke goes something like this:
Q: Why is the infighting so fierce in academia?
A: Because the stakes are so low.

In the game industry, if you need help from someone else in the company, they generally go out of their way to help you. It's intrinsically understood that you're all on the same team, working towards the same goals (i.e. shipping the game, and remaining profitable), so helping your co-workers is just helping yourself.

In college, everyone has their own agenda, and other people's agendas run counter to yours. If you ask someone else for assistance, they may not give it to you unless it serves their needs as well. In fact, they may work to sabotage your efforts if they think your success will cost them resources later on. This is doubly true if you're trying to get help from someone outside your department, as is often necessary when you're teaching an interdisciplinary subject like game development.

For example, ever since the start of Summer, I've been looking to reach out to Computer Science students. If any of my undergrads are going to actually make games, they will either need to know how to program (a rare trait in a telecommunications major) or they will need to know someone who does. Tonight, I met my first CS student -- just one. I'd like to find at least five more that are interested in game development, before winter break, so they can register for a class where they can make a game on a team...

IGDA Game Education SIG is now online!

As announced recently by my colleague Darius, the special interest group for game education in the IGDA now has a blog.

So, now it appears I have competition. :-)

Teaching: Advance warnings aren't.

One of the classes I'm teaching is all about rapid prototyping. We started on paper and are just now progressing to digital prototypes.

I mentioned on the first day of class that there would be some programming involved, and that the skills students would use would end up being about 25% programming, 25% art, 50% design.

I had the students with programming experience raise their hands, so that they could be identified by their classmates.

I left a full week in the schedule before we started anything programming-related, with no assignments due. I suggested students use the time to either (A) learn a rapid-prototyping tool like Game Maker or Flash; or (B) do a few simple exercises in a tool that they already know, like drawing sprites on the screen; or (C) find someone else in class who knows how to implement some of this stuff, and pair up with them.

On the day the first digital assignment was handed out, all of a sudden it was a huge surprise. We have to actually program? Like, displaying numbers to the screen and having buttons that change those numbers? Ohmigod, that's so unfair, this isn't a Computer Science class, most of us don't know how to program, how did this happen? (The current assignment is to do a functional mockup of a Diablo-like subscreen, displaying HP/Mana and doing some very simple inventory management: equip, unequip, drop.)

Next time around I'll hopefully have some actual CS students taking the class, and I'll pair students up manually instead of letting them do it themselves (and let them change groups on their own... if their other members consent). Maybe instead of a "dead" week, I'll assign some busywork project that forces students to learn how to do some simple prototyping tasks, like drawing to the screen. Beyond that, I'm not sure what else I could have done to prepare students for the shock of actually having to use a computer. Or maybe I'm being totally unfair, and overestimating the capability of a non-CS student to learn and use a game authoring tool (or socially network within the class to find someone else who can).

Comments? Suggestions?

I have found the dividing line

Percentage of my class that has played the arcade version of Dragon's Lair (1983): 0%.

Percentage of my class that is familiar with Gauntlet (1984): ~25%. Mostly from the more recent console versions, and Xbox Live Arcade.

Percentage of my class that played the original Super Mario Bros. (1985): 100%.

I suppose I can expect this to shift up by a year, next Fall.

Teaching: Work Ethic

In the game industry, if I found an interesting article on game design or business or something, I could just pass around the link in email and by the next day everyone will have read it.

In class, if I do the same thing with my students, maybe one or two of them will take the time to click the link. Even if it's something really cool, like listening to Warren Spector and Greg Costikyan cussing or a game you can play for free online.

And I think it comes down to the difference in how these things are approached. In school, I don't think most students think of it as a job (where you get "paid" in grades perhaps?), nor are they concerned with professional development (since learning new stuff is kind of mandated, which automatically turns people off from doing it voluntarily).

I was guilty of this myself; I didn't really develop a solid work ethic until I was 25 or so. But oh, how nice it would be to be able to teach it, since it's practically required to get into the industry (and certainly to do well once you're there)...

Teaching: Clarity trumps Fairness

It started out so simple. Have students each study their own special topic, in-depth, and present to the class. They're presenting things that everyone in the room should know anyway, like who is Shigeru Miyamoto and why is he important, or what was Origin Systems, so that they don't sound like they were born yesterday when they're rubbing shoulders with veterans at GDC. They may or may not have played Katamari Damacy or Shadow of the Colossus, but they should at least know what it is because they will hear people referring to them.

May as well match up the topics with their relevant courses. If a student is going to speak about Knights of the Old Republic, let's do that on the day when we talk about sequels and licenses. Someone speaking about the ESA should do so on the day we cover game publishing. Spread it out so everything makes sense, and so that I don't have to devote a full day of class to having every student speak about a series of unrelated topics.

But it wouldn't be fair to penalize students who signed up for topics early in the course, would it? Then they only get a few days to prepare, while someone who signs up the last day of class would have many weeks. Every student should have the same amount of time to work on this so it's all fair. One week is plenty of time to prepare for a short (3 to 5 minute) presentation. So, each student signs up for a date, I'll keep the topics secret, and I'll inform each student of their topic a week before they're due to present.

Now, in doing this I wasn't thinking about actual implementation issues, just how fair the policy was. It turns out that doing things this way is really hard for several reasons. First, I have to remember to email the topics a week in advance; I now have reminders posted all over my living space, but there were a couple times when I notified the student late. Second, I had a situation where several students didn't receive their topics by email; something got fragged in the system and they showed up unaware that they had to present anything. In either case I need to give more time to the student, but that pushes back their topic to a class where it's no longer relevant.

Third, students signed up on a sheet that's in my possession, and many of them didn't think to copy the dates they signed up for, so I get a lot of emails asking when someone's next topic is due. The process is definitely not user-friendly.

For this course, I've already set the policy and it seems a bit late to change it now, so I'll just have to suck it up. Next time I do this, though, I'll just make the topics available at the start of the course; it may not be as "fair" but it's a whole lot easier for everyone to follow.

Culture Shock: Tardiness

As I forcibly drag myself out of bed at some unholy morning hour so I can get to my class on time, it occurs to me that this is the sort of thing that would never happen in the game industry.

Mostly because if you show up late and say "sorry, I was up late playing this game that I just couldn't put down" people will understand. It's not something anyone should make a habit of, but it is a valid excuse.

As a teacher, of course, I have to show up on time or my students will leave. Many of them probably believe the widespread (but false) legend of some "15 minute rule": if the professor doesn't show up within 15 minutes of the start of class, then allegedly the class is automatically canceled. Sort of like how many of my students want to believe that emulation is legal if you own an original copy of the game, or if you delete it within 24 hours, or if the game is no longer sold in stores (all false).

Looking for more "Making Of..." videos

I've noticed a wonderful trend in AAA (big-budget) games lately: many of them include DVD-style bonus content as unlockables. This includes reference art, developer interviews, and other behind-the-scenes stuff that really gives some insight into the game development process.

These things are great for the classroom. All of the stuff I'm teaching about the theory of how games are made, is reinforced by live developers that made a really sweet game. Some of these developers are important enough that a student should know what they look like in case they meet them at GDC or something.

So far I've found three games in my personal collection with this kind of bonus content:
God of War
Sid Meier's Pirates! (Xbox version)
Guitar Hero

Unfortunately, in all three games, I actually had to play for a bit to unlock these things. But that's the kind of selfless sacrifice I'm willing to make for my students :-)

Have you encountered any other games lately that feature this kind of material? Please let me know!

Teaching How to Write is Hard

Timely as ever, Darius mentions the importance of not referring to "the user" or "the player" in design documentation.

I tell my class to avoid "the user" because it makes it sound like you're writing a piece of software, not a game. Software has users; games have players.

I also tell my class to avoid "the player" even though it's marginally better than "the user." Referring to "the player" depersonalizes the experience and destroys empathy. Darius also pointed out another reason: not all players are identical.

The easy way to do better is to write in the second person: "you press the X button" rather than "the player presses the X button". This builds reader empathy.

The harder way is to create fictional characters, give them names, and tell stories about them. "Confident from his years of experience with Street Fighter 2, Joe mashes the X button into submission." Human brains inherently grok stories, far better than bulleted lists or technical descriptions.

And in spite of all this, half of the design docs I get back in a homework still speak of "the player". The tendency is apparently a tough habit to break. (I remember I had similar problems learning to avoid using passive voice.) But I have to wonder why. Why is it so natural to write in a style that's so unnatural to read? And what can I do, if anything, to really drive the point home... so that students get it right the first time?

Teaching: Grading Homework

Now I understand why so many homeworks I had to do as a student involved right answers: specific numbers, computer programs that either ran or didn't run on test data, multiple choice. It's because it's much easier to grade; in some cases it can even be automated with those ScanTron things.

Even the essays I had to write were typically on a given subject, and everyone in the class was writing a different variation of the same essay. These are harder to grade since you actually have to read them, but it's still relatively easy because you know the kinds of things you're looking for.

Well, I made the mistake of starting my first assignments with "choose any game"... so everyone's assignment is going to have different content. I also didn't specify an exact format, so some people write paragraphs while others give bullet points (and both are equally valid). So for each student I first have to look at the game on Mobygames and Wikipedia and IGN/Gamespy/Gamespot to understand their game, then look through their description and see if it's reasonable. With 30 assignments total between my two classes, that's a bit of work.

Next time I give these classes it will be easier. I won't need to prepare each lecture in advance (I can re-use most of the content that I'm creating now) so I'll have extra time for grading. I'll also give an example of what I'm looking for so that students have a format they can follow.

Culture Shock: Strunk & White are Dead

As a game designer, your top priority is clear communication with the rest of the development team. A good design doc is concise, easy to read, and uses all sorts of tricks to get others to read and understand it. The Elements of Style is the Bible.

Go up a bit on the corporate ladder and everyone's got a PhD in English Literature. You never "use" anything, you always "utilize". You don't "work together" with other people, you "synergize". Things that could be said in one simple sentence stretch on for paragraphs, because in the business world it's more about impressing or intimidating the other party than communicating with them.

In academia, where the whole reason for you to exist is to transfer knowledge and ideas, you'd think people would emphasize clarity. But listening to people speak and reading what they write, it sounds a lot more like business than game development. What's the point of sounding educated, if it comes at the cost of being understood?

Me, I'll take points off of a student's paper if it sounds like it was trying too hard to impress me with vocabulary. If I don't enjoy reading it, then something went horribly wrong...

Teaching: How to deal with procrastination?

I remember being a student, and going to great lengths to rationalize why I should start my assignment tomorrow. Can't do it right now, I need a solid five-hour block of time and my gaming group starts in three hours. Don't start it early, there's always problems in how the assignment is stated, let some other sucker run into the traps and force the professor to issue errata, and then I won't have to waste my time running into one brick wall after another. I remember how it was.

Of course, life in the game industry is totally different. You don't put off critical tasks, because at best it puts the entire project behind, and at worst it gets you fired. Also you're working on a game that you (hopefully) care about, and any lost time now means one more cool feature that won't be in the game. It's been long enough that I actually forgot that there are people out there that don't start working on a task as soon as it's assigned...

So, I encourage my students to start early on their projects because it will give them time to iterate properly. My professors told me the same thing when I was in college, and I learned to ignore them. Naturally it's come back to haunt me, and now I get emails at 11:45pm on Sunday asking basic questions about the homework that's due Monday in class.

Is there any way I can say this and still be taken seriously? I really am completely serious about this, and it's a necessary skill to survive in the game industry. But every time I talk about the importance of starting early, I can almost hear my 10-years-younger self in class saying back to me, "yeah, right".

Teaching: Design Exercises

I've had a lot of success at Hi-Score with running game design workshops. The basic formula is always the same: I create some initial constraints, and then let the participants loose. The constraints make the creative process easier, because the designers are forced to start off asking themselves questions, and asking questions about your game is a great way to narrow down what it is that you're actually going to build.

One of the easiest kinds of constraints to make is a thematic constraint. Your game can be anything, any style, but it must be about frogs. Or rain. Or paint. Or whatever. CMU ETC's experimental gameplay project did this.

In my game development class, the project I just handed out today asks the students to make a game on the theme of Light and Dark. Including two opposing themes joined by the word "and" does a subtle, interesting thing: it forces designers to ask, how do the two themes relate within the game? Are they opponents (Light versus Dark, e.g. Archon)? Are they collaborative (Player wields the forces of Light and Dark together)? Are they orthogonal (There is a Light World and a Dark World and the player must navigate between them, e.g. Zelda: Link to the Past)? You will get radically different games based on how the relationship is interpreted.

I expect you could have similarly interesting results with any two opposing forces. Design a game about Nature and Technology. Or Land and Water. Or Cheese and Chocolate. Anything to force the designer to start asking a question about the theme itself.

By sheer coincidence, my colleague Darius recently blogged about another way to present a constraint for a game design exercise: take a controversial, famous quotation and make a game to demonstrate the idea (or disprove it, I suppose). Could be a great design exercise for a serious game developer. I think this is also a great method because it forces the designer to ask two questions: (1) do I agree or disagree with this quote, and (2) how can I express my opinion through gameplay?

Teaching: Fun in Class

What makes classes fun?

Oops, sorry. I forgot, classes aren't supposed to be "fun," they're supposed to be "engaging." Okay, what makes classes engaging?

Things I've noticed that get students' attention:

• Interactivity. If I'm constantly asking questions and not just lecturing, everyone is paying attention. Students are more interested in listening to what their classmates are saying, than to what I'm saying :-). The questions don't even have to be 100% relevant, as long as they have some small relation to the topic (or they act as a segue into the next topic).
• When I absolutely must transfer information without interactivity, students pay more attention if I'm animated and excited about what I'm talking about. It must be a quirk of human psychology: if someone is really interested in something, then you're more likely to be interested too, because there must be a reason why the other person is interested.
• Playing games in class. I'm lucky to work in a department where every classroom has a really nice projector, where I can hook up a console and play it on the big screen. Even with the lights turned off (which always put me to sleep as a student -- I need light) everyone is watching the screen. I always give the controller to a student; playing distracts me and makes it difficult for me to point out what's going on in the game. Besides, there's never a shortage of volunteers.

I think it's vital for students to be engaged in any class with the word "game" in the title. It's an expectation, the same way that students taking a comedy class would expect to laugh a few times each class period.

Game Design Curriculum: Game Design Classes

Wrapping up my series on the game design curriculum, I wanted to suggest some game design classes. You can't have a game design major without some classes that focus on game design, right?
(I realize these are not practical for students who may have no control over their university's curriculum. That's why I saved this section for last.)

Since these courses aren't standardized anywhere, I'm making up the names as I go.

Game Industry Survey. Game design students, especially, need some kind of survey class that talks about the important people, companies and games that every developer (whether a designer or not) should know; and also, an overview of the types of companies and jobs found in the game industry. As I said earlier, you should have at least one minor related to another area of game development, so this course would help you decide which area to minor in.

Theory of Game Design. Every game designer wants to have their own Grand Unifying Theory Of What Makes Games Fun. Most of them are useless. A precious few have gained acceptance (or at least acknowledgement) within the industry: LeBlanc's MDA, Koster's Theory of Fun, Bartle's player types, and some others. Students should be introduced to the prevailing theories of what Fun is, where it comes from, and how to make it.

Core Systems Design, Creative Design and Level Design. Those of us in the industry largely learned game design by doing it; the same is true for artists in other media. The bulk of game design courses in school, then, should be practical and not theoretical. I would envision several "pure" design courses where students are given a set of projects, each with their own constraints. Students then create designs, test them and iterate on them, ideally under the watchful eye of an experienced designer who provides guidance. By "Core Systems Design" I mean creating the basic rules of the core of a game; "Creative Design" would deal with the design of characters, plots and storylines, and UI; and "Level Design" is, well, level design.

Technical Design. A designer should have some experience in the left-brained side of their field. This course would include some Game Theory (prisoner's dilemma, payoff matrices, stuff like that), some applications of mathematics in game design (e.g. solving intransitive games, use of triangular numbers in games), and some basic understanding of numerical methods and computation (for example, what the difference is between integers and floating points... and why Hit Points -- and most numbers in a game, in fact -- should be integer).

Prototyping. As far as I can tell, the only people in the entire game industry who like to see 500-page "Design Bibles" are Producers and Publishers, because it gives them the impression that work is being done. Designers don't like them because they take a long time to write and they're impossible to maintain halfway through the project, and the written word is static while most game systems you're documenting are dynamic. Programmers don't like them because reading a massive design doc is boring, confusing, and obsolete as soon as the designers stop maintaining it. A far better way to communicate and "document" living systems is with a prototype, whether it be in the form of a paper boardgame or an actual computer program. Designers should be able to whip up a quick prototype of a small system (say, a subscreen or a turn-based combat model) in Flash or a similarly "light" scripting language, even if they don't know C++ or Java.

Team-Based Game Development. This wouldn't be a game design class per se, but an interdisciplinary class where students work together in moderately-sized teams to create a full game or game demo. Of all disciplines, game designers cannot exist alone; they need to learn to work well with programmers and artists. Luckily, finding strong programmers and artists who want to make games isn't that hard at most universities :). If you look hard enough you can usually even find one student who's skilled enough at game audio, and maybe another student for production (or the teacher can act as producer). This course might also be called a "capstone" or a "portfolio-building" class.

For what it's worth, this year I'm teaching Game Industry Survey; plus a Prototyping course (my university calls it Game Development) and an advanced variant that will be closer to what I'm calling Core Systems Design; and a 20-week Team-Based Game Development class (we're calling it a Capstone), and something else (TBD) in the Spring. So, I'm practicing what I preach here.

Teaching: First Day

So, my first day of classes ever was this past Wednesday.

The good part about teaching games is that I'm seeing students at their best. They're well-behaved, engaged, motivated and intelligent. I've heard horror stories from other teachers about how rude or lazy or dishonest their students are, and I'm just not seeing it in my classes at all. Much as I'd love to take all the credit with my natural teaching ability, I'm sure the subject material has something to do with this also :-)

One down side to teaching games: none of my classes are part of any core curriculum (yet), so my classes are the first to be dropped in the event of a schedule conflict. In a way, this is a good thing, as my class sizes stay relatively small (about 15 students each) so we can have some real group discussions without too many people getting lost in the noise. I can't imagine what it would be like to teach to 150 students at the same time, while trying to make the class interactive in some way; for the time being I don't have to know.

I'm also realizing a small flaw in my original plans: my syllabi make class participation part of the grade, but I'm so terrible with remembering names that I need to create a mechanism to track participation that doesn't involve my memory. I suppose I could take attendance, but that just seems so grade school...

Need help with Terminology

As far as I can tell, there are four basic types of interaction in a two-player simultaneous game:

Pure cooperation -- you work together against the game. One could make this REALLY obvious by having the players share a life meter, score, etc.

Pure competition -- players are in direct opposition, and there is a Winner and a Loser (or a draw game, maybe).

What I call "coopetition" -- there are two possible outcomes: either one player wins and the other loses, OR both players lose (but a shared victory is not possible). This forces the players to work together to avoid the we-both-lose outcome, but they also have to work against each other to avoid the I-lose-you-win outcome. Extremely rare in the field, but one of my favorite types of game forms.

And then there's this fourth, open-ended style where players can cooperate or compete at their discretion. The most obvious examples are games like Joust and Wizard of Wor where players can kill each other (and the game offers some reward for doing so), but players can also keep out of each other's way and just work as a team to get to the highest level they can. What do you call this style of gameplay? The best I can come up with is "co-option-tition" or "co-optional", both of which sound really lame to me.

Any ideas?

Kids These Days

As part of my faculty orientation last week, I learned a bit about the entering Freshman class (theoretically hoping to graduate in 2010), and also about some other teachers' attitudes towards students. It was a bit of a shock.

I learned that cheddar is money, not a dairy product. Dope is an adjective, not a noun, and it means that something is really good (although I think my generation wins for confusion here, as when something was really good we called it "bad").

I learned that the entering class has no meaningful recollection of any presidents other than Clinton and GW. The first Gulf War happened when they were two; it falls into the same historical category as Vietnam, WWI, and the Civil War. They don't remember the Cold War or the breakup of the Soviet Union; the threat of nuclear war isn't as scary as AIDS, Columbine or terrorism. The Kennedy tragedy was a plane crash, not an assassination. The original Star Wars trilogy has lousy special effects. George Foreman is the guy who sells those grills on TV. Popcorn was always cooked in a microwave, televisions have always had cable (and been in color, and had remotes), and telephones have never actually "rang" (with a physical bell). Record players and vinyl albums are what DJs use to mix music, and they've probably never seen an 8-track.

I learned that this is the generation of kids who grew up with Soccer Moms. Their parent is their personal assistant, their teammate, their coach, their friend. They may run the risk of being spoiled, but they're also confident, achievement-oriented, and they probably get along with their parents better than any other generation in history.

While these kids may actually respect their elders, they don't seem particularly respected in return. I mentioned that one of my goals in the Game Industry Survey course was to educate the students about the industry to the point that they could carry on an intelligent conversation about games; the response from the room was along the lines of, "you want them to have an intelligent conversation about something? Good luck with that..."

Excuses among students are common. One colleague told me that he killed a dozen or so grandmothers, aunts and uncles every semester, some of them twice. I found this similar to when I made online CCGs and we'd occasionally have to ban some kid from our game for poor behavior, and I learned that everyone has a little brother who logged into their account and caused trouble... even only children have little brothers.

It's only been ten years since I was in college myself. How did things change so much in such a short time? Am I aging at an accelerated rate, or have things always been this way?

Humility

Sometimes, when you're surrounded by hype, it's important to remember deep down just how insignificant you are.

This year I went to GDC. It was a huge event, more people there for a single purpose than I'd seen in years. Over 12,000 developers came to learn, network, and talk shop. That's probably around 30% of the North American game development population.

Later on I made it to Origins. This was a place by gamers, for gamers and there were well over 15,000 people just living and breathing games. And this was just board and card games, mind you -- not a digital game in the lot. Had it also involved a LAN party, it probably would have been way bigger, maybe even three or four times this size.

I didn't make it to E3 (and thank you ESA for making me update my already-finished course syllabus :-) but there were like 70,000 people there, between industry, retail, press, and fanboys who managed to snag a pass from a friend. I can only imagine how packed that must have been.

And then, a few weeks ago, I visited the Ohio State Fair. Over the course of a week and a half, there were some 800,000 people who came from far and wide just so they could see a cow sculpture made of butter.

And the game industry just has no way to compete with that.

Culture Shock: Meetings

In the game industry, everyone is keenly aware of just how far behind schedule the project is, and it's (usually) recognized that meetings can burn a huge number of man-hours in a very short period of time, so when people call a meeting they tend to get right to the point. People are in the room to find a specific solution to a specific problem, and then to document the solution and the reason behind it so that they don't forget later. Meetings in practice often fall short of this ideal, but we try.

During a meeting, everyone may have their own ideas and their own agenda, but they are entirely forthcoming. Creative disputes (sometimes involving voices raised in passion) are expected from time to time. Everyone cares deeply about making the best game possible, which means no one is going to hide their idea and keep quiet just to "not rock the boat".

In academia, meetings feel a lot different. There is not necessarily the same time pressure (you're certainly not going to have a whole group of people laid off just because their project is behind, since half of the people you're dealing with have tenure), so the atmosphere is more relaxed and reserved. There is more competition between individuals and less overlap, and there is a lot more concern about making sure no one else in the room is offended, so people tend to be less forthcoming with their ideas and they're much more subtle about pushing their own agenda on the group. As such, brainstorming effectively is much harder.

Bonus culture shock of the day: specific to the institution where I'm teaching, students add classes by filling out a "pink slip" (this is what they are called) and having the instructor sign it. I have to question the wisdom of whoever thought it would be a great idea to subconsciously train their students to energetically ask their superiors for a pink slip...

Culture Shock: Homework Design

One thing I never appreciated as a student was that, no matter how heinous the work I was assigned in class, the professor had to do even more work than I did. If I'd thought about it at the time, I never would have complained about my workload, ever.

For one, the professor has to actually do the assignment, same as the students. It's much like beta testing -- gotta make sure the assignment actually works, that it isn't too advanced or too time-consuming. It's also useful for having an "A"-level standard to use while grading (assuming you could get an A in the course you're teaching :-).

Of course, before testing the assignment, the professor has to actually design the thing. And afterwards the professor has to grade all of them. And during the assignment period the professor will be fielding questions about the assignment during office hours.

At least, that's what it's looking like to me so far. Maybe I'll discover a shortcut later.

Game Design Curriculum: Elective Minors

The sad fact is, almost no one gets a game design job immediately on graduation. Most people enter the industry as a programmer, an artist, or a software tester. The reason for this, I think, is that those positions are inherently low risk: a programmer or artist who screws up their entry-level work is probably not going to sink the entire multimillion-dollar project; another programmer or artist will clean up the mess and no one else will notice. (A tester, by definition, can at worst do nothing.)

But a designer's job is, essentially, to tell the programmers and artists what to do. Design mistakes don't just require another designer to make repairs, but also programmers and artists to redo their work. Design mistakes bleed across departments, so companies tend to be very careful of who they hire in those positions.

As such, anyone interested in game design should also minor in Computer Science, Art, Business, Marketing, or some other discipline that is directly related to game development. This gives you three ways to enter the industry: game design (unlikely), QA (easier to find, but tedious and boring to most people), and whatever you minored in. Understanding multiple disciplines also makes you marginally more attractive to a game company (especially a small one), since you can fill more than just one role and you're more likely to communicate well with people in different departments.

Additionally, take a second minor in something that has nothing at all to do with games. Game designers need to foster a lifelong passion for learning (just look at all the crazy stuff that Will Wright or Sid Meier knows – the stuff that has nothing to do with games – like astrobiology or world history). I know, I know… most educational institutions do their best to squash the love of learning out of every last student. That makes it all the more important to reverse the trend in college, by studying in-depth something that really interests you. It could be anything; astronomy, art history, classics, Shakespeare, French, quantum physics, whatever. There are many reasons why this will help you. First, it will set you apart from others by giving you unique interests. Second, it demonstrates your all-important love of learning. Third, it gives you a small, random chance to be a perfect fit on any given dev team (example: if you minored in abnormal psych and unbeknownst to you, the company you’re applying to happens to be in negotiations on a game with a paranoid schizophrenic as the main character…).

Two minors? Sounds crazy, but in a field with practically no entry-level positions open to new graduates I consider it a necessity.

Topic for Discussion: Game Research

If half of being a faculty is teaching, the other half is performing research.

Game Studies research is pretty straightforward in terms of how to approach it; it's similar to other cultural and anthropological studies, where you conduct interviews and observe player reactions to games and analyze demographic tables and such, and then you find the correlations.

Game Design isn't like that. Yes, some researchers conduct studies that try to quantify "fun", in the same way that economists might try to quantify "utility" or psychologists quantifying the exact definition of various disorders.

But look at cinema. Is anyone writing research papers on the crafting of an audience reaction, or the correlation of fun to car chase scenes, or creating emotional tension in the viewer? These kinds of things are artistic, creative and highly subjective; they don't lend themselves well to number-crunching quantitative research.

Instead, the academic side of film creation concentrates on, well, creation. Students make their own experimental films and showcase them.

Should game design research be the same way? Shouldn't we be making experimental games, using mechanics or themes that haven't been used before? If we must, we can always write an academic-style paper about the game we made, that talks about the design intent and observed player reactions.

And yet, I haven't seen anything like that coming from academic researchers. Grad students, yes, but not faculty. Am I barking up the wrong tree here, or is this a direction that game research should be heading in? Or has it already, and I'm missing out on a lot of experimental games out there?

Culture Shock: Mommy, Where Does Funding Come From?

In the game industry, funding models are pretty straightforward. If you're a third-party developer, you get your original game project as finished as your startup funds permit and then shop it around to publishers; or you respond to publisher RFP's. If you're established enough, publishers come to you instead. Wash, rinse, repeat until one of two things happen: you go too long without getting a new contract and you go out of business; or you generate a massive hit that gives you royalties, letting you self-fund your next project.

In academia, things are different because there are so many funding sources. For public institutions, you have state (and maybe federal) funds. There's alumni donors. There's tuition, of course. Then you've got grant funding from large organizations (e.g. NIH, DoD, NSF -- at least in the States), and from private foundations. Oh, and there's the occasional research project that gets commercialized and generates revenue to the school through royalties. And it's some combination of all of these that pay your salary as a teacher.

To complicate things further, these sources don't exist in a vacuum; they affect each other. For example, you get more state funds if you increase your enrollment, which also increases your tuition revenue (but also your costs to support the extra students, which may wipe out your gains). You also get more state funds (at least here in Ohio) based on the number of patents you generate, which also means increased commercial revenue. You increase alumni donorship by getting your university in the news because you just published some really important piece of research, which may or may not have been funded by grants. Deciding where to put your resources and where to chase additional funding is a huge balancing act.

And that's all ignoring university athletics; I don't even want to think about the complexities of that.

Back when I was a student, I thought that the whole point of universities was to teach their students. But then I also thought that the point of working at a game company is to make the kinds of games you want to play yourself. In both cases that may be the Dream, but everyone has to deal with the reality of where their next paycheck is coming from, first.

Game Design Curriculum: Other Stuff

There are a few other assorted courses that I've found useful in the field.

Communication. No matter how good your high-level designs are, you must communicate your vision to the rest of the team. Having solid communication skills is one of the most important aspects of being a designer. If your school has a class in active listening, take that too -- designers tend to receive lots of feedback from their team (mostly on how much their design sucks :-), and being able to listen effectively and deduce the real design problems from someone who isn't a designer is a great skill to have.
Microeconomics. Really, anyone that wants to work for a company of any sort should understand the basics of supply and demand. Like it or not, game companies are businesses and they therefore need to make money if you want to continue receiving a paycheck. This course will prevent you from saying embarassing things in company meetings, like “we should make our game engine open-source and stop charging people for it, we'd get more players then.”
Women’s Studies. Currently, the game industry is really terrible at dealing with women. First, it’s lousy at attracting women to the industry; the average game company is about 10% women, and it’s even worse if you just look at game designers. Second, it’s not so great at marketing to women; the number of female gamers is growing, yes, but if you look at game ads and game magazines (and some games, too) you still see chainmail bikinis and the like. Game developers (especially male ones) need to understand some fundamental truths about women if we ever want to make them feel welcome. I sincerely hope that some day, this problem will be fixed and I’ll be able to remove this course from my proposed game design curriculum.

Topic for Discussion: Money, Grades, High Scores

Darius pointed out to me yesterday that giving grades to students is a lot like giving incentive pay to workers. The ever-eloquent Joel "On Software" Spolsky has recently (and not-so-recently) written about why incentive pay is bad. In short, it insults the worker by implying that they're only trying to do a good job because they want the money (rather than the more powerful incentive of taking pride in their work and genuinely wanting to do a quality job for its own sake), and it also encourages workers to "game the system" to get more pay while actually doing a less optimal job in the process.

Let's suppose that both Darius and Joel are correct. What are the implications for teaching, if the necessity of giving grades takes the students' focus away from the theoretical goal of actually learning something?

In part, this is why I'd like to make my grading system playful. By doing something mildly ridiculous, I'd like students to forget about the grades and concentrate more on the class itself. (I realize I'm running the risk of having students focus more on grades since the system is novel. I'll let you know how it goes.)

I'll take this a step further and tie the discussion to games. In the early days when video arcades roamed the earth, every game had a scoring system and a high score list. But did we actually play the games to get on the high score list, or did we play because they were fun? Did high scores actually make the games less satisfying, by implying that we were just playing for the score, rather than the sheer joy of shooting countless waves of aliens?

I'm not sure if that's the case or not, but games have definitely moved away from scorekeeping over the last decade. (Of the ten games I'm playing right now, only one of them has any kind of scoring system.) The focus nowadays is usually on "beating the game", and even then the player is often encouraged to go back and do it again with a higher level of mastery -- time attacks, higher difficulty modes, hidden secrets, unlockables, and so on. Essentially, games have evolved from letter grades to pass/fail... with the option to do extra work to earn honors credit!

I feel like there's some universal connection here that's just beyond my grasp, something that suggests a better way to evaluate classes than the standard grading system. Any thoughts?

Culture Shock: Industry Jargon

When talking about game development disciplines (programming, game design, art, sound, production, QA), one thing I've noticed is that the industry vocabulary has not been adopted by most academics.

At GDC, there were a number of times when I introduced myself as a game designer and was immediately asked "so, what language do you program in?" Well, I happen to be a C++ man, but that's beside the point -- design is not programming. I would advise any developer applying for a professorship to explain game development and their specific role during their job interview, just so everyone is clear on your experience and area of expertise.

Here's another example: one of the courses I'm teaching this fall is called Game Development. Game developers will look at me in horror for this; the field is so broad and interdisciplinary that it's impossible to teach in a single course. You would need a twelve-semester sequence to cover everything. If all you have is a single class, you'd need it to be so abstract that it's functionally useless. A course in game development would make about as much sense as a course called Science or a course in Art.

As it turns out, this particular course is about how to build game prototypes. We'll start with paper and work our way up to digital prototyping. The focus will be on expressing and communicating ideas -- as efficiently and cheaply as possible -- through the medium of game prototypes.

So, in a sense it is a class in game development, as students will be one-person dev teams on small game projects. But no one in the industry is likely to know that from the name. In future years, I hope to rename the class to "Digital Game Prototyping" or something similar.

Culture Shock: Writing a Syllabus

I never gave much thought to the syllabi I received on the first day of every college class. I just assumed the Syllabus Faerie created them all on the day before the semester started.

Now, for some well-established classes where the content doesn't change much, I'm sure a new professor is handed the old syllabus as a starting point, but when teaching a brand-new class it's something one has to create from scratch. And when that class is game-related, you probably won't find that many similar classes to draw inspiration from.

Having never written one of these before, I was a bit nervous. But now I'm feeling much better about it, because I found a way to bring the art of syllabus-writing into my field of expertise using two models:

Syllabus as Developer/Publisher Contract. In a way, a syllabus is a contract between the professor and the students. Both syllabus and game development contract spell out timelines and development goals and a description of the end-user experience. The contract is agreed to by both parties (in this case, the students "agree" by not dropping the course, analogous to a publisher not canceling the project). And the contract is a living document, open to negotiation if all parties agree partway through that it just isn't working in some area.

Syllabus as Game Design Document. A design doc describes in great detail what the game will do and how it will work, down to the core mechanics. A syllabus describes in equally great detail what the class will involve, how it will work, and what are the grading mechanics. Again, both documents are subject to iteration during the course of the project; in particular, game features (lecture topics) tend to get added or cut later on in the project (course) when there is more or less time than needed in the schedule (semester).

Culture Shock

One of the things I wanted to do with this blog was describe those areas of academia that were particularly surprising to me for one reason or another. I've spent most of my professional life in industry, so I have a bit of an outsider's viewpoint of the academic world.

These posts will be meant primarily for those of you in the game industry who are curious about what it's like on the other side. Students may also gain an appreciation for what their professors go through (we really are normal people, just like you, honest).

Experienced professors will probably look at these and either find them blindingly obvious or hopelessly naive. That is, more or less, the point :-)

Game Design Curriculum: Computer Science

If we accept that learning art will help you to communicate with artists, then learning some computer science should help you communicate with programmers.

Intro to Programming. Some aspects of game design are pretty technical; if game data or rules are stored in a scripting language (either a commercial one like Python or Lua, or a proprietary one) then it is often expected that a designer will be creating content in those languages, which requires at least some fundamental knowledge of programming. Since you do want a solid foundation, take the course for CS majors if they'll let you.
Data Structures and Algorithms. I don’t feel that a single, introductory programming course is enough to truly understand how to convert ideas into code. A course dedicated to algorithms will give you a better idea of how that’s done, and a course dedicated to data structures will give you some tools that’ll make certain problems much easier.

Topic for Discussion: Learning vs. Gaming

At the wonderful design/art/business blog Lost Garden, there's an interesting post about how learning in the context of games is fun. It alludes to the earlier work by Raph Koster.

The comments, however, have moved to a discussion on why school is largely considered Not Fun, if learning is supposedly the Ultimate Source Of Fun.

I still can't help but feel that something is wrong with the theory. If learning is fun, then classes(especially college with its more freeform attitude towards learning) should be fun in spite of the educational system. Teachers shouldn't have to work hard to engage their classes, they should have to go to great lengths not to engage them. But clearly that's not the case, which implies that only certain types of learning are fun.

Which types? Does learning have different "types" in the same way that there are different kinds of fun? Are certain types of learning more fun than others?

Game Design Curriculum: Fine Arts

Now we cover the really creative stuff. How much art do you need to be a designer?

Intro to Art or Intro to Architecture. Two reasons for this. First, some aspects of game design are pretty artistic, so understanding the basis of art can give you some perspective (or architecture, since designers are effectively architects: instead of creating blueprints and plans for building a structure, they create blueprints and plans for building a game). Second, you’ll be working with artists, and being able to understand some small part of what they do will help you communicate better with them.
Computer Art. Take a course that requires you to use the tools that artists need to use on the job (currently this would be either 3DSMax, Maya, or Photoshop). Again, this lets you communicate better with artists on your team, and lets you express your ideas more visually.
Improvisational Acting. You learn three things in this class, all useful skills to have as a designer: creativity; thinking fast; and making the other people on your team look good.

Topic for Discussion: "Pacing" of a class

In comments to a previous post, Patrick Dugan mentions a "progressive curve of increasing [grades] as the semester progresses".

This reminded me of something I've been ruminating on for awhile. If you have a class with regular assignments throughout, what's the best way to weight the assignments with respect to time?

Most of the classes I've taken as a student follow a roughly constant curve; each homework is about as heavily weighted as any other, with occasional (seemingly random) spikes for large assignments, plus of course a heavier weighting on the mid-term and final.

On the other hand, most games I've played (especially boardgames) follow an increasing curve; early victories or setbacks are small, later ones are more important. This is great for games, because it keeps players interested to the very end. Also, players will know that even if they start out poorly, they can come from behind to win if they do particularly well in the endgame, so no one loses hope. Would this progression be worthwhile in a (game-like) classroom?

Pros:

• Students given incentive to try harder in the last half of the course rather than drop.
• Early assignments are safe experiences, where students can learn my grading style without huge risk.

Cons:

• If every class did this, students would have too little work to do early in the semester, and be overloaded as finals approach.
• Puts too much emphasis on the last half of the course, so may only be suitable for classes that build on earlier topics, rather than "survey" classes that cover a variety of unrelated material.

So, what's your opinion? Constant weighting, or progressive increasing? Or is there some other method that might work even better that I haven't considered?

Updates

Since I appear to have some frequent readers now, just a note that I plan to be updating this blog once every two to four days, as I have been so far.

So, if you stop by every day, that's great, but I don't want you to be disappointed. Dropping in once or twice a week should be plenty.

Game Design Curriculum: English

By now you might be wondering if game design is a purely technical field. No, I promise, there are plenty of arts (fine and otherwise) in the field.

Writing. Designers write. A lot. If you can’t stand writing, seriously, you might consider entering the industry through a different field. Anyone who writes a lot needs to start with a foundational course in college-level writing.
Creative Writing. Designers are the ones who write the text that goes in the game: backstory, storyline, character dialogue, and related stuff. Designers are also asked to write formal game proposals, which involve a bit of creative writing.
Technical Writing. Designers write two types of documents, primarily, that are technical in nature (that is, their purpose is to convey information rather than to entertain). These are the design document, and the game manual. If you ever wondered why no one reads the manual, it's because most manuals are not written very well, because the writer did not have a solid grounding in technical writing.

Topic for Discussion: Grading Methods

I'd like my classes to feel distinctly game-like, so it's only suitable that the grades themselves are game-like. So far I've considered two ideas, and I'm trying to decide between them.

Method 1: Dance Dance Revolution scoring.
The class is out of a maximum of 1,000,000 points. A typical assignment might be 100,000 or so. Giving out awards of a few thousand here or there for class participation is easy, and it's more points than they'd get in all their other classes combined.

Method 2: Zelda scoring.
You start with a full health meter of 100 hearts. When you lose points on an assignment, your grade "takes damage". Extra credit provides "healing". You can keep track of your own grade on a life meter provided on the syllabus.

Zelda scoring is more realistic in that students always know exactly what their maximum possible grade is, and overall where they stand. But it can also be more demoralizing and intimidating since you're always losing points instead of gaining them, and it sets up an adversarial culture between me and my students since I'm dealing damage with every assignment.

Do you have a favorite? I'd love to hear your thoughts.

Game Design Curriculum: Science

As with math, the creative field of game design doesn't intuitively seem to require a strong scientific background. But if we've already established that math is useful, science shouldn't be too much of a stretch from there.

Physics I. As I mentioned when I was there, any game that uses physics (and there are many of them) requires knowledge of kinematics. Taking the rest of the sequence (heat, fluids, electromagnetism) is not necessary, as those aren’t used in games nearly as much.
Biology I and Chemistry I. Some aspects of game design are scientific in nature (consider that an advanced prototype that asks the question “is this particular mechanic fun?” is essentially a scientific experiment), so a basic understanding of the scientific method is useful. A good basic Biology and Chemistry class will teach you about the basis and methods of science. A bad class will just make you memorize a bunch of stuff and not tell you why it’s useful at all, but at least it gives you the opportunity to meet some Bio/Chem majors who can explain it to you if you ask. Your best bet is probably an intro course for non-majors, if one is offered at your school.

Game Design Curriculum: Math

When I mention math to most college students who are interested in design, it comes as a surprise to them. Game design is a creative field, and creativity and math go together about as well as, um, chocolate and broccoli. Right?

Except that any time you hear the words "game balance" (as in, "this game isn't balanced" or "I need to tweak the balance of this level") you're really talking about math. Game balance means that the game is neither too difficult nor too easy, and while it can be done by trial and error, it goes much faster if the designer can put together some good mathematical models. Game balance is the designer's job, so a good designer needs to know at least enough math for that.

Two examples should suffice. In Civilization, each unit has its own cost, strength, defense, speed and several other numerical stats. If those numbers are out of whack, then players will find one particular unit type (or strategy) to be better than any other, and the game will quickly become boring. Similarly, in Final Fantasy (or any RPG of your choice), there's typically a huge database of numbers: monster stats, player stats, level progression charts, combat formulas and so on. Those are all math, and they all need to be designed.

So, what math does a designer need? I've found the following courses helpful:

Calculus. Calculus teaches you the math to describe and analyze how fast something is changing. It is therefore necessary if you’re trying to describe a variable in a game that changes over time. If you’ve ever heard talk of game “pacing” or the “difficulty curve” of a game, that’s calculus. Also, the entire field of Physics is based on calculus, so taking Calc will help greatly in your understanding of Physics (I'll talk more about Physics, and science in general, in a later post).
Linear Algebra. This gives you the tools to solve systems of equations using matrices, which is useful when you have several variables or stats in your game that you need to relate to each other. It’s also useful for solving certain types of game-balance problems, like Rock-Paper-Scissors-like ("intransitive") game mechanics. It’s also used in computer graphics for rotation and scaling, which you might encounter at some point.
Intro to Probability. The field of Probability was created to study games (gambling games in particular), so this shouldn't be much of a surprise. Any game with randomness requires probability to describe the exact nature of that randomness. Rating systems (or any other form of player ranking) also require probability, to show if they’re fair or not.
Intro to Game Theory. Sadly, “Game Theory” has very little to do with game design; it’s a branch of mathematics that deals with particular kinds of probability questions (particularly those that involve multiple players making simultaneous choices). If you’ve ever heard of the Prisoner’s Dilemma, that’s game theory. It’s useful when designing certain types of multiplayer dynamics, especially in boardgames or strategic computer games.

Game Design Curriculum: Where We Are Now

To my knowledge, there are two previous attempts by the game industry to come up with a curriculum. I do promise to start writing about my own ideas soon, but first I'd like to comment on what has come before.

Tom Sloper doesn't exactly give a curriculum, but does give a list of courses he feels are necessary for a game designer to take. While I agree with Mr. Sloper on many points, this is not one of them. Realistically, there is no way an undergraduate can take all those courses and still major in anything, while still graduating in four (or even five) years. It's just too much. Also, he doesn't give the reasoning behind why those courses are supposedly important; from the list, I suspect he was considering the skills needed to design popular games. You can't design Civilization without having a strong background in history, so sure, all game designers should study history. But... what if you're working on Guitar Hero? Now those history courses don't seem so useful.

The field of game design is already broad enough that we're specializing: very few people are good at story design and level design and core systems design and technical design, even without expecting that every designer is somehow equally skilled to work on an FPS and a Tycoon Sim and a historical turn-based strategy game.


The other group working on building a curriculum is the IGDA, and they've put quite a bit of effort into their curriculum framework. This document has the lofty ambition of defining fields of study for all disciplines in game development, not just game design. As such, it is necessarily more high-level and abstract than I'm looking for here. Also, for game design it focuses on design-specific topics (core systems, emergent complexity, feedback loops, risk/reward cycles and so on) but doesn't draw any associations with existing courses in other departments. It doesn't say how much math a game designer should be taking, or how many courses in psychology or philosophy or history or what not, nor what kinds. The curriculum framework is an excellent starting place when thinking of how one would go about teaching a course with the words "Game Design" in the title, but it does not define a full liberal arts curriculum as I wish to do.

Some universities are trying to build entire game design departments with large heapings of course offerings. But if you're at a university that doesn't have a dozen game design faculty, what do you do? In the next post, I will start answering that question.

Game Design Curriculum

Suppose you were just entering college, and you already knew that you wanted to be a game designer some day. That's your career goal. In lieu of a game design major, what courses should you take?

Or, suppose you're a faculty member at a university, charged with designing a curriculum for a game design major. What courses should be included?

Hopefully the answers to these two questions are the same.

Unfortunately, the industry does not have any solid answers, yet. Part of the problem is that it's exceedingly rare for anyone to get a game design job fresh out of college. Also, game design is so interdisciplinary that it's hard to find a department that it naturally fits in.

So why bother coming up with a curriculum at all? Because there is demand for one from students, and from the game industry. Also, schools need consistency: if they graduate a student with a Bachelor's in Game Design, they need the industry to know what skills that student is expected to have.

Over the rest of the summer, I will write a series of articles on what I would hope to see in an undergraduate game design major. I will start by covering the work that has already been done and where I see room for improvement, and then I will give my own vision of what courses I've personally found useful -- and why.

EDIT: I'm adding a table of contents in this post, so that there is a central place linking everything together.
Where We Are Now
Math
Science
English
Fine Arts
Computer Science
Other Stuff
Elective Minors
Classes about Game Design