Choosing a School: Ownership

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

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

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

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

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

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

Assessment and Evaluation

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

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

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

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

Notes from CTL

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

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

Keynote: Dr. Mark Milliron

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

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

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

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

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

Game Jams!

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

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

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

Textbook Review: Challenges for Game Designers

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

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

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

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

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

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

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

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

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

Textbook Review: Teaching Videogames

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

"Teaching Videogames" (Barney Oram & James Newman)

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

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

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

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

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

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

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

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

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

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

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

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

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

Difficult Assignments

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

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

Culture Shock: Student Passion (or lack thereof)

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

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

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

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

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

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

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

Random Teaching Bits

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

Here are some takeaways I got from the session:

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

The Importance of Keeping in Touch

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

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


The biggest takeaways I wanted from the conversation:

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

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

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

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

Updated Labels

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

I have a feed

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

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

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

Bloom's Taxonomy

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

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

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

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

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

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

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

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

New Blog on Game Design Textbooks

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

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

Challenges for Game Designers

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

Description:

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

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

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

Design Challenge on GameCareerGuide.com

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

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

Another class assignment

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

This particular assignment had two parts:

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

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

A Game Design Assignment

Another teacher of game design mentioned this at Origins:

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

This forces students to exercise the following skills:

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

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

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

Gender Pronouns in Writing

Game designers do a lot of writing. So do teachers. And students, for that matter. So, I thought this writing tip that I picked up at Origins would be useful to most of you. (If only I had known this before finishing the writing on my textbook. Well, there's always 2nd Edition...)

Gender pronouns are always tricky. Use a gender-neutral he/his/him all the time and you've unwittingly added male gender bias (this is particularly insidious in game design documents, if you inherently assume the player is always male -- which perhaps explains why there are so many female characters in games wearing chainmail bikinis). Use she/hers/her and it looks like you're using feminine pronouns just for the heck of it. The dual him or her / he or she is unwieldy. The slash-based s/he looks ugly. The fusion hir looks downright alien. What's a writer to do?

Here's a simple solution: make it contextual. Use male pronouns for certain kinds of things, and female pronouns for others, and use them consistently.


The example given at Origins was in the writing of a rulebook for a tabletop RPG. The designer used female pronouns for the GM and male pronouns for the players. This not only caused the writing to be more gender-balanced, but also made the manual easier to read because it was clear who each pronoun was referring to!

Giving Great Game Demos

Alex Yeager of Mayfair gave a great seminar at Origins called The 2-2-2 Demo. What follows are my notes. There are several applications:

• If you regularly introduce your students or colleagues to new games, it helps if you can explain the rules succinctly. This is the direct application.
• Explaining the rules of a game is no different than teaching any other course material. If you can explain how to play a game, you could use the same basic framework to explain your course material.
• The process of creating a game demo has similarities to the process of designing an actual game.
• You'll probably see other parallels as you read on.

What is a "game demo"?

In this particular context, it means a way of introducing someone else to a game they haven't played before. There are many reasons you might want to do this: to simply familiarize them with the game for educational or historical purposes, to get them interested in the game enough to play it, to convince them to buy it, etc.

There are many types of demos, but Alex gave three types: Two-sentence, Two-minute and To-play (hence, "2-2-2").

The Two-Sentence demo

In the game industry, we would call this an "elevator pitch." In just a couple sentences, state the basic theme and goal of the game. The purpose here is not to explain the rules, but to gauge and generate interest. It gives the other person an opportunity to bow out without you wasting ten minutes on a full rules explanation before saying they're not interested. If they are interested, this provides a context for everything that follows.

The Two-Minute demo

Discuss the type/genre of game, general flow of gameplay, win conditions and other important core mechanics. Take the two-sentence demo and add detail. Emphasize the important decisions that players are making.

Again, the purpose here isn't to give the other person everything they need to play, but it makes a full explanation of the rules go much faster if they already have a mental framework to put things in context. The purpose is still to generate enough interest to proceed to a full demo.

The two-minute demo has another purpose. People who have played the game, like it and want to evangelize it can use a version of your two-minute demo when they show the game to their peers. This provides a way for you to "deputize" players so that they can generate interest in the game from their friends, who can all them come back to you. (Think about this. Do you teach any courses where your students are actively recruiting on your behalf for next semester?)

It's worth mentioning that some games do this for you automatically. If a game has neat-looking components that make players go "wow... what's that? Can we play that one?" then you can safely skip the short version and leap into the rules. Not many games have that kind of "curb appeal" but a few do.

The To-Play demo

When game enthusiasts want to demo a game, many of them leap immediately into a full explanation of the rules. For some people (e.g. other hardcore gamers who have already agreed to play) this is fine. Other people (especially non-gamers) may still be tentatively deciding whether they want to play at all, and launching into a full-blown rules description can quickly overwhelm them.

Use this demo to teach the game to people who have already decided to play. They are actively engaged and they've got the time and opportunity. Otherwise, start with something simpler.

The best to-play demos are things you've practiced before. Become intimately familiar with the rules yourself before teaching them, ideally. Think of ways to present the rules so that they're easy to understand, flow well and can be explained in a minimum amount of time.

Personally, I've found that for most board games, the following framework tends to work well:

• First, state the object of the game, unless it's really obscure or needs other information to be understood. It provides the context for why the player should care about other rules. Frame all other rules in terms of "how can you use this to win?"
• Then, talk about the progression of play. How do turns work? What can you do on your turn? Start with the things you do most of the time, and just briefly touch on exceptions that only come up once in awhile.
• Next, mention the game end condition. What causes the game to end, and how (if at all) do players have control over causing the game to end or continue?
• If you can just set up the game yourself without having to explain initial setup as a series of rules, do so. Otherwise, explain the first part of the game last, after the players already understand the general flow of play and can make intelligent decisions during setup.

Implications for playing games

When explaining games to people who aren't gamers (like friends or family), start with very simple explanations. Don't continue into something more complex until you see the other person's interest, or else you may bore or overwhelm them.

Implications for teaching

Start each course topic with a general "why should I care?" / "why is this cool?" overview, then layer on some basic details and the overall flow of what you're about to learn, and then go into the gory details once you've got the class interested. Once your students see why the stuff you're teaching is important, they'll pay a lot more attention.

Implications for game design

Don't create a game (either digital or non-digital) where your players must understand and master all of the mechanics before they make their first move. Try to create play situations where the player is slowly and gently introduced to new mechanics, allowed to feel through the general flow of the game in a relatively safe environment. Then, add the details once the player is hooked.

Bonus insight: Implications for curriculum design

According to Alex, there's a pattern when introducing Eurogames to kids who are unfamiliar with them:

• When you teach one game, that's all they want to play. "I played Settlers of Catan before, it was fun, I want to play it again." There are, apparently, no other games worth playing.
• When you teach a second game, there's a choice: play X or play Y. "We played Carcassonne last time, let's try Settlers again."
• But when you teach a third game, something magical happens. The players start seeing connections and comparisons that go beyond simple either/or choices. "Let's see... I'm in the mood for a trading/auction game, and Joe says he has to be somewhere in an hour so it can't be more than that, and Sarah hasn't played before and wants something easy to learn... how about Modern Art?"

I think education may work like this in general. Take a Biology 101 class where they force you to memorize all of the structures of the cell, and you assume that the entire field is just memorization. Take Genetics and you might think that the field is part memorization, part math. Take a microbiology course... and suddenly you realize that it's actually a really diverse field, and all those other courses aren't just repeats of the same stuff you've taken already, they're starting with some basic concepts and taking them in a whole new direction, and how cool is that? But only the people in the major get to see this. Implication: the "101" or "Survey" courses, especially those aimed at non-majors or prospective majors, should be designed to expose them to at least three different areas of the field. In these classes, focus less on laying a foundation for the major, and more on the diversity and overarching patterns and common problems that they will see in the field.

Back on regular posting schedule

First there was Origins. Then I came back to find that I had a week to finish up final review for my first book. Then I got some short-term industry contract work. So, things have kept me busy, but I'm now back. In the coming weeks I'll follow up with what I learned at Origins this year in terms of teaching, game design and more.

One thing I've been thinking about for a little while now is the similarity between education and game design. I'm starting to actually read some books on education, and an awful lot of concepts are identical, they just have different names. I heard this from several teachers at Origins as well -- after seeing my presentation, they remarked that some general concepts of game design are the same as in the professional literature for education, except that they are perhaps easier to understand in the context of games (if the teacher happens to be a gamer, at any rate).

For example, one of the concepts most game designers are familiar with is the MDA Framework, which says (among other things) that there are many different kinds of fun, that different games offer different combinations of these kinds of fun, and that different players find some kinds of fun more or less engaging than others. There's a parallel to different kinds of learners in a classroom environment: audio learners, visual learners, kinesthetic learners and so on, where each student is engaged by a particular type of activity. It's not much of a stretch to find links between the kinds of classroom activities and the kinds of fun in game that people find engaging.

A more interesting example is rubrics. I'd never heard the term 'rubric' before becoming a teacher. Essentially it means making a list of skills, and then grouping and classifying them. For example, a grading rubric for a class would list all of the things students are expected to be able to do after taking the class, and then what skills the students must build in order to do those things, and then what the students must demonstrate (and at what level) in order to achieve an A, B, C, etc.

Most teachers I know hate developing rubrics. It's a chore that involves tons of paperwork, and defining all these tiny details about a class and the concepts that you're teaching and how they all relate to each other and how you plan to measure everything. It's something that teachers do only when forced at gunpoint.

And yet, there are designers of computer/console role-playing games that do essentially the same thing. What are the capabilities that I want the players to be able to take advantage of in and out of combat? What are the skills, abilities and magic spells that I can make available to the players to allow them to accomplish these feats? How should I group these skills and abilities and spells -- by function, by elemental sphere, by character class? How do players gain access to these skills -- leveling up, completing quests, finding items? And this is the kind of content design that RPG designers absolutely love. It's the really fun part. It's a hoot. They'll go back and design more of these skills for fun, on their own time, rather than doing the important work like testing the combat system for balance.

Somehow, there has got to be a way to make rubrics as exciting as RPG design. I haven't figured out how yet. But it's the same freaking task.

Origins 2008

It's that time of year again.

I'll be speaking twice:

• Friday 6/27 @ 9am, room C215: "Game Design for Teachers" - basically a repeat of last year's presentation (I posted a two-part summary here and here). Last year I ran out of time, so I streamlined the content a bit for this year, concentrating on the theory more than the practical.
• Saturday 6/28 @ 9am, room C215: "Advanced Game Design for Teachers" - new this year, includes the practical aspects (some case studies that I wouldn't have time to present in the other session) and a short workshop where we'll take some content from the attendees and find ways to present it to the class in a more game-like way.

I'll also be taking a lot of photos and meeting with some game publishers for the book, so I expect this year to be a bit different in that I'll be spending as much time doing work as I will be playing games.

This year will also be different in that I know some of my students will actually be there. (It helps when my students from this last year live in the same city, as opposed to 80 miles away.)

If anyone out there is in the area, feel free to find me and say hi. And if anyone out there happens to be a teacher in the area (this includes anything from homeschooling to K-12 to grad student TA to college professor), bring your credentials and you get in the door for free.

Why You Hated Your College Teachers

Okay, there were probably a handful of professors that were incredibly inspirational to you, but these stood out in a sea of instructors that you've long since forgotten. (Even if you're currently a student.)

Having compared three different schools that I've worked at, I think I know why.

A full-time teaching instructor is expected to teach four classes at a time. From my experience, teaching a class takes about ten hours a week (this includes about 4 hours in class, plus extra time for prep work and grading). So far, that's a 40-hour work week, which is expected.

But then you have office hours, typically anywhere from 4 to 10 additional hours per week. If your students don't show up then you can use this time for grading, but it seems to me that if you're counting on your students never visiting you then that's a greater problem... but it's certainly not something you should be encouraging as a teacher.

Then there's academic advising, which is nothing most of the time but makes for a week of hell somewhere near the end of each class, as you get a flood of students with paperwork. So far I haven't been involved in this process enough to say what the time commitment is, but I think I can reasonably say that it's not zero.

There are department meetings, which is an extra hour or two every week or two. Already we're somewhere around 50 hours per week. If you want to do anything extracurricular, such as be the sponsor of a student club or perform community outreach to local high schools or offer seminars to your faculty colleagues or what have you, that's extra. Some schools mandate that you put in a minimum number of these kinds of extra hours, others don't.

Now, those of you in the game industry are scoffing at me here. I'm concerned about a mere 50 hours, when it's not unheard of in game development to pull 90+ for extended periods? Ah, but here's the rub: game developers are, by and large, a passionate bunch. We got into the game industry specifically because we love games and want to make them. I'd say that of the professional developers I've worked with, somewhere around 90% of them have a passion for their work and are more than willing to put some extra time in if it'll improve their project, or if it'll give them a chance to improve their own skills and hone their craft.

Teaching is different. Of all the professors I've met, maybe 5% are passionate about teaching, so very few are going to willingly put in the extra time unless forced at gunpoint. And the thing is, with both teaching and game dev, the quality of the final product is proportional to the amount of work you put in.

There are other things that modify a teacher's workload:

• Studio/practical classes take significantly less time than lectures. You just have to design assignments, so the amount of prep work before class is minimal. Strangely, it counts as the same, so loading up on studio classes is a way to game the system. Of course, someone has to teach the lecture-based classes, so you're just reducing your workload at the expense of your colleagues (who are probably not as passionate about teaching as you).
• Online classes are insidious. They seem like they should take less time because there is no lecture, but I think they actually take slightly more time because you have to log in, check email and contribute to discussions on an almost-daily basis. Think about how much time you spend just checking your email, RSS feeds and discussion forums in the morning and you'll see what I mean. The time flies by so it doesn't feel that bad, but the total time per week is a little more than a typical lecture class, so you have to be careful. Some schools recognize this and actually pay a slight premium to online instructors; others treat online as equivalent to a "normal" class.
• For lecture classes, my above figure of 10 hours per week depends on two major factors: amount/intensity of grading, and amount of previous course prep. If your assignments are easier to grade (e.g. multiple-choice as opposed to essay questions) that will reduce your time commitment, at the expense of having assignments that are meaningful -- the Real World rarely gives you multiple choices, after all. As for course prep, a class requires more time the first time you teach it. Some schools give you a break if one of your courses is brand-new and developed by you (say, only teaching 3 classes instead of 4), while others make no such allowances.

There's a common theme here. Almost everything that a teacher can do to make their own life easier, does so only at the cost to the quality of their students' education. Which means that the teachers who are passionate about teaching and really care are the ones who spend 60+ hours per week, and everyone else is going to do whatever they can to bring their hours worked as close to 40 as possible.

From Gamer to Designer

Most of the people I knew in the game industry who were game designers, were that way from a very young age (myself included). We would make games, even if they weren't very good. When we played games, we would think about the rules. We would write design documents in crayon. It's just something we did naturally, without having to be prompted.

I'm sure that in the game industry, that made game designers easy to screen out. If you ask a question like "what's your favorite game" and then start analyzing that game -- what were the design mistakes (no game is perfect, even your favorite), what would you have done differently, what elements of the game make it so compelling -- the discussion flows naturally with the right candidate. For the people who are more gamer than game designer, though, this kind of question is anathema. "What do you mean, critique my favorite game of all time? It's awesome, it's great, what more is there to say?"

Because that's clearly helpful in a design document, saying that the game should be "great" and "awesome."

Now, I'm in the position of teaching people to be game designers, and it's just occurred to me that my classes have a high proportion of gamers in them, and not everyone sees the distinction. I didn't notice the dividing line in my classes either, until just now when grading the final exam. One of the questions goes something like this: "Write a one-paragraph game concept for a video game that has the following constraints: blah blah blah." And the answers that I get fall into a few different categories:

• "My game will be just like a combination of this game and this other game." Great, but what if I haven't played those games? And how do you plan on being innovative if all of your ideas are based on earlier video games?
• "My game has this story..." Okay, maybe you have a future as a story writer, but my class is in game design, specifically core mechanics. What does the player do?
• A full paragraph with all sorts of things describing how great and fun it will be, with maybe two words to give some clue as to the actual gameplay. These are the fanboys (or fangirls, I suppose, but in my experience it's always the guys that do this). It makes me sad to see that after ten full weeks of learning about how to speak critically about games, as soon as I ask someone to apply it then it all goes out the window and they revert to their earlier fanboy status. I suppose there are some kinds of people that I haven't figured out how to reach yet.
• And every now and then, I see a student who writes a concept that includes a description of mechanics and gameplay. Apparently, it doesn't occur to them that the question would be asking for anything else (and they're right).

Generally, the students who answer in the latter category are the ones who tend to do well in the class overall. It's making me wonder if this is something of a litmus test for game designers: ask an open-ended question that involves designing a simple game concept, and see what people do. Maybe I'll try that on the first day of class next time, as opposed to on the final exam...

And then for the students who aren't getting it on Day One, I need to work out some strategy to get them to abandon their lifelong gamer mentality for long enough to start thinking like a designer.

Spelling Lesson

Game designers have to do a lot of writing. As a teacher of game design, this means I see a lot of student writing. I don't know what they do over in the English department, but whatever students learn over there, it seems like it doesn't always stick. Maybe it's because no one ever draws the parallel between writing in English class and writing for other classes, that you use the same skills. I don't know.

There are a few errors in particular that I see more frequently than others in game writing. Given the importance of writing to a game designer, I think it's fair to say that these are the kinds of errors that could lose a job opportunity if they appear in a cover letter. (Programmers probably get slightly more leniency.)

This is my list of Most Frequent Student Mistakes. If you're a student, learn these, because you might not get marked off in your game design classes but you certainly will in your job application. If you're a teacher of game design, feel free to add your own frequent student mistakes in the comments.

• Bored vs. Board. If you're doing a dull task, you're bored. If you're playing a game like Chess, you are playing on a game board. If you say that you're "board" it means that you feel like a non-digital game component. If you call something a "bored game" it is an insult to the game's designer.


• Lose vs. Loose. If you fail to win a game, you lose. If something isn't tight, it's loose. There is no such thing as "loosing" a game, and you never "loose" a life.


• Roll vs. Role. If you want to throw a pair of dice to get a random result, you roll them. If you are acting in character, you are playing a role. If you "role" dice it means you're trying to behave as if you were one of them. If you are playing a "roll-playing" game you're implying that you do more die-rolling than actual role-playing, which is generally considered an insult.


• Suit vs. Suite. Each card in a standard poker deck belongs to a suit. Hotels and office buildings have large rooms called suites. If you refer to Clubs as a "suite" you had better be talking about a swanky dance club and not a deck of cards.


• To vs. Too. If you could substitute the word "also," use too. Otherwise, use to. Not specific to games but a lot of students seem to have a problem with this and use "to" for everything.


• Affect vs. Effect. For the purposes of describing gameplay affect is almost always a verb, and effect is a noun. A special ability in a game may have an effect on the game, and it may affect your chances of winning. There are rare exceptions to this which can generally be ignored if you're writing about games.


• Know vs. No. If you understand a piece of information, you know it. The opposite of yes is no. If you say that you "no the rules of the game" then... um... well, I'm not really sure what you're saying, but it's not what you think you're saying.

Note that a spelling/grammer checker will often not help you with these, so proofread your own stuff even if Microsoft Word says everything is fine.

I also see some common misspellings, which surprise me in their frequency given that they would be caught by a spell checker:

• Obstacle. Not "obsticle."
• Strategy. Not "stragety" or "stratagy." And learn to pronounce it correctly. I blame Bugs Bunny for this one.
• Ridiculous. Not "rediculous."
• Sense. Not "sence."
• Experience. Not "experiance."
• Explanation. Not "explination."
• Definitely. Not "definately."

Culture Shock: Retention and Turnover

In the game industry (and in fact, in any professional industry), employee turnover is expensive. If someone leaves the company and you have to replace them, there's the expense of interviews (which take a lot of time away from senior people) and then the extra time it takes the new hire to get productive. Companies that realize this do what they can to retain their employees. Indefinitely.

Being a professor is different. In my case, "turnover" means that a student has graduated. It means I'm doing my job correctly. It also means fighting against the instinct of "gotta keep our best people around" that I'm used to from being in the industry.

Choosing a School: Focus on Games

Question: Can I see a syllabus for some of the game classes this school offers?

What to look for: In the syllabus, see if the topics are specific to games, or more generalized to other media. If you want to make games, specifically, then you'll want classes that have readings and homeworks that involve games -- not movies, not literature, and not the World Wide Web. Of course, the reverse is true if you want game development to be only one option of many.

What to do: Look through the syllabi that you receive, paying close attention to the assignments (readings and projects). If there is a textbook, find it at your local library or book store and skim through it. If a syllabus is not available, ask some students who have taken the classes if they might have an old one; at the very least, ask them if the class is about video games or if that's only part of it. Also search the public website; occasionally you'll find that certain parts of a course are unrestricted access.

What to watch out for: A lot of classes (and majors!) have titles that sound like they focus on games, but then you find out that they don't. A few examples (feel free to post others in the comments):

• Nonlinear Storytelling. This might be a class about interactive stories in video games. Or, it might deal with stories in other media that are told out of order, like the movies Memento and Pulp Fiction.
• Digital Media Production. Could mean game production, in the sense of actually creating a video game. Or it could be game production in the sense of teaching you how to be a producer (dealing with scheduling and budgets). Or it could be either of those things for other media, like movie production. Or it could be special effects, like audio/video post-production for movies.
• Introduction to Interactive Multimedia. This might be an obfuscated way to say "intro to video games" or it might be a class in Web page design or Flash programming.

In short, if you know exactly what you want from your program of study, make sure you're going to get it!

Choosing a School: Diversity

Question: How diverse is the student game developer population in this school, overall? How about the top 10% or so?

What to look for: Ideally, you'd like to see a wide range of socioeconomic backgrounds and demographics, but in most cases you won't. At least shoot for more diverse than the game industry.

What to do: Schools generally know the demographics of their student body. They also know who the top students are. Not all schools put the two together to see how they overlap, so you might have to do some detective work on your own. Grades of individual students are confidential (as well they should be), but you can see if the Dean's List is public, and then take a guess based on names and any other information that happens to be there. When you visit campus (you are going to see the place for yourself before you commit to spending four years of your life there, aren't you?), you can also get qualitative information from existing students.

What to watch out for: If all of the students in the program look like they were all cloned from the same genetic material, it could mean several things. It could be that the school is actively selecting people that fit specific criteria, which could signal that they're more interested in being a factory that churns out degrees than actually caring about you as an individual. It could be that the school has difficulty attracting women and minorities, which means you'll be less sensitive to diversity issues than you should be if you're white/male/straight, and you'll be feeling slightly uncomfortable (at best!) if you're not. If the student body within game development is diverse as a whole, but the top students are all white/male/straight, then that suggests the program is set up to reward certain types of students -- likely because the faculty look like clones, even if the students aren't.

In general, a diverse population means that a wide variety of people can succeed at the school. Without it, the implication is that exactly one type of student succeeds, the one who can Fit In Here And Be Just Like Everyone Else. If you feel like you'll fit right in, this might be okay... but take a Women's Studies or Minority Studies course anyway, will ya?

Choosing a School: Why Question At All?

Students choose schools for all kinds of reasons. At the community college level, it's often based on proximity to home more than anything else. With four-year schools, it could be anything from geographic location to campus size to how pretty the campus looks to which school one's boyfriend/girlfriend is attending. It's easy to ignore the quality of the school.

Complicating things further, schools have a process set up where you have to apply to attend there, which immediately puts the prospective student in a position of perceived weakness. After all, you can't attend at all unless they say you can. If you are accepted, you should thank your lucky stars (because there's a line out the door and around the block of people waiting to take your place) and not ask any questions. Interviews for game industry jobs can feel similar to first-timers.

If you're a student looking at game schools, it's worth remembering a few things:

• You're paying an extreme cost in time (4+ years) and money (more than a new car, unless you have really expensive taste in cars). It's one of the largest expenses you'll have in your lifetime.
• You wouldn't buy a new car without at least kicking the tires and taking a test drive. You wouldn't buy a house without taking a tour and getting it professionally inspected. Do your due diligence the same way you would for any other big-ticket item.
• Screw this up and you'll graduate with a degree that makes you unemployable. Or you'll drop out and owe tens of thousands of dollars in exchange for no degree. Think about your next steps after you're done with school, and realize that your options change based on your school experience. It's worth taking the time up front to make sure you'll get what you're looking for.

Choosing a School: Student Projects

I've already given a few things for you to consider when choosing a school, but I think it's worth including some things you should not consider too much. One of the common themes of recruiters is to show off cool-looking student projects.

Be wary of student projects. At the DDAF, almost every presenter on the Education Panel showed a lot of work from their past and present students. The work looks impressive, and the implication is "we'll show you how to make something cool like this." But when I thought about it, it didn't really tell me anything about the school itself.

Every school has a few brilliant students who will produce phenomenal work, on their own, with or without faculty assistance. The work certainly reflects on the quality of that particular student, but may or may not have any correlation to the quality of the academic program.

It's also easy to get distracted by quantity. Some schools have large programs and lots of students, so they will likely have more student work to show than a smaller school. Take the size of the program into account.

Also be wary if the most impressive student work is more than a year or two old. Schools with quality programs and a steady stream of incoming students should be producing cool stuff every year. Showing one or two works from four years ago is an indication that the school just had a handful of outstanding students that year, not that they have a great program now.

Lastly, if the student work isn't similar to your area of interest, that should be a red flag. For example, if you want to be a game designer or a programmer and the only student work available is animated video clips (not playable games), you're probably dealing with an art/animation program that doesn't focus on games.

I'm not saying you should ignore student work entirely. But treat it the way a hiring manager at a company would treat personal references for a job. The applicant chose their best references so of course they're all going to say great things, so this shouldn't really persuade you. But if someone applying for a position can't even find a decent friend or two that can say something nice without reservations, maybe that's a signal you should be looking elsewhere.

Choosing a School: Job Placement

Question: What is your job placement rate out of all incoming freshmen? (This is tricky, and you might have to do the math yourself. Figure out the percentage of incoming freshmen make it all the way through the program and graduate, and multiply by the percentage of graduates who get jobs.)

What to look for: High numbers. What's good? I actually don't know. It's relative.

What to do: Compare the numbers of several schools.

What to watch out for: Schools that boast abnormally high job placement rate of their graduates... but only because their program is so obscenely difficult that only a tiny fraction of incoming students actually make it through. Or, schools that have low placement rates in the industry (indicating they aren't taken seriously by people who know how to judge talent and ability). Or, schools that can't tell you their placement rate because they don't track those numbers (indicating that the school might not care about you in the long term, as long as they get your tuition money today). Or, schools that inflate their job placement rate by encouraging students to start their own studios fresh out of college -- make sure their people are being hired by someone else, not themselves (I have nothing against starting your own studio, but if it happens too often at a particular school that's an indication that a lot of their graduating class couldn't get jobs at established companies that were hiring).

Choosing a School: Faculty

Question: Who are your faculty?

What to look for: Industry experience, doing work that is related to the classes they are teaching. Preferably at least one teacher who did the job that you want to get yourself some day.
What to do: Again, verify. Look up credits on Mobygames for games that were published. If a professor can't explain to you exactly what work they did on each title they worked on, find out yourself if you can, and view with extreme suspicion if you can't. Ditto if the school (or a particular professor) says they worked on "lots of games" but can't tell you which ones.

What to watch out for: There are a lot of "teachers" out there who are supposed to teach you how to make games even though they've never made one themselves. Would you want to learn how to cook from someone who's never been in a kitchen (no matter how many cookbooks they've read)? Would you pay money to take music lessons from someone who's never picked up an instrument? Would you take a skydiving course from someone who has never been in a plane? Someone with no experience can teach you the theory from a textbook, but they won't be able to guide you any further... and with so many bad textbooks out there, how would they know that what they're teaching is even valid?

Choosing a School

At the DDAF this week, I saw a lot of high school and community college students who were interested in studying games. I was actually a bit disappointed with the Education panel; great representation from six schools that have game development programs, but it basically amounted to each school giving a 15-minute recruitment pitch, with no one actually commenting on what to look for in a school or how to find the program that's right for you.

In fairness, "how to choose a school" isn't necessarily what the panel was supposed to be. But it struck me that a lot of students in the audience were skipping a few steps in the process, and would benefit from some more basic information, like what criteria are important in school selection, and even how to know if they should be considering a game school in the first place.

So, I was inspired to start writing a series of questions that are worth asking. If you're a student, I hope these will help you in selecting the best academic program to fit your needs. If you're an educator, give some thought to how you'd answer these questions, and if your program would stack up favorably. If you're in the industry... well, this might not be of much use unless you're on an advisory board for some college or university, but if you ever get asked by a father's brother's nephew's cousin's former roommate about what's the best school to go to, you'll have at least one URL to send back.

To start things off:

Question: What degree do you offer, what classes do you offer in that degree, and what jobs will that qualify me for?

What to look for: You should see a lot of classes, not just a traditional Art or Computer Science curriculum with a couple of "game" courses tacked on (this is assuming you're looking for a game-focused curriculum). You should see at least one course where you're working with people outside your major -- if you're an artist, you should be working with programmers. Obviously, the courses should be in your area of interest.

What to do: Verify that the school is giving good information. Check out the IGDA Curriculum Framework and see if the school's curriculum is in the general ballpark. Read the IGDA Breaking In website, and see if the courses you'd take are related in any way to the job you'd be doing.

What to watch out for: Some schools call their course of study "game design" even though it is actually a programming or game art curriculum. If the school does not know the simple difference between the various fields of game development, how valid is your education really going to be? Also, a lot of students haven't yet discovered their area of interest; they equate game development with playing games, or at least they haven't figured out that there are many fields of study. Know your own passion before you go to school for it.

The Joys and Frustrations of Grading

Having just graded another midterm, I realized something.

My favorite part of grading is when I ask a question that I know is difficult (but meaningful), and I see a student just totally nail the right answer on the head. It makes me feel... validated, like here's someone who was paying attention, here's something that I was able to teach.

My least favorite part is when I see an answer that's totally unintelligible, like the student was answering a question that I didn't ask, and it's clear that they either misunderstood the question or else that I'm misunderstanding their answer. On the one hand, I teach game design, not communication, so if the student understands the question and has the right answer and just has difficulty communicating then I feel bad about taking off too many points for it. On the other hand, I can't justify giving points for an answer that I don't think is right. So, I have to dock the points and hope that if I'm wrong, the student has the guts to call me on it (which actually happens a lot less often than I imagined it would). But I just hate the uncertainty.

Speaking next week: DDAF

For once, I've got a speaking engagement at an event that I don't have to travel to. The event in question is the Downtown Digital Arts Festival in Columbus, taking place May 7-9, right on the campus where I teach.

In particular, I'll be co-hosting a workshop called Game Design Improv with colleague Brenda Brathwaite. I'll post a report on it here when it's done.

If you're in the area, stop by. And if you're a student, also check out the panel discussions about the game industry as well. I don't think we've ever had so many game developers in Ohio at the same time before, so take advantage of this opportunity while you can!

Amusing Student Quote

It's the little things like this that I'd never anywhere else, that remind me why I like teaching so much. Paraphrasing a couple of students:

A: "So, from your definition of the word 'game,' real life would be a game."
B: "Yes, I think life is a game."
A: "Then, is death Game Over or just a checkpoint?"

The Industry Veteran vs. The Karate Kid

Matt Sakey says:
One of the challenges for a games-based classroom is transitioning learners from their onscreen experiences to real world applications. A game that teaches algebra should keep that fact well-hidden. Kids immediately get suspicious when threatened with something that seems too much like a learning tool. Instead, conceal the algebra training inside an economic or management sim along the lines of Zoo Tycoon (which conveniently would also teach about animals, basic geometry, problem solving, etc.), and ramp it up gently. But at some point you have to help the learner make the mental connection, the “oh wow” moment… to realize, essentially, that skills learned in interactive zoo management work in life as well.

That "oh wow" moment is key for learning, but not just for game-based learning as Matt suggests. It's critical to draw the parallels between what you're doing in a classroom and how it's actually used in the Real World, whether you use games or not. Without that connection, you run into all sorts of problems:

• Students learn rote facts and methods without understanding them in a broader context. When it comes time to apply their classroom knowledge, they'll have to go back and learn it again, because they never thought before of how to actually use it.
• Humans are inherently good at understanding and remembering stories, moreso than random factoids. Course content is the latter; showing how it's used is the former. Without the context, it's harder and more inefficient for students to learn the material.
• More to the point, a lot of students won't even pay attention if they don't see the value. If your class is perceived as just being an arbitrary hoop to jump through so your students can get a piece of paper, let's just say that you're not going to have your students passionately learning your subject.

And honestly, students are hungry for this understanding. If you teach a class, try this, if you don't already. One day, just take two minutes at the start of class to tell a story about how the stuff you're learning in class today was actually used to do, well, anything useful or cool. See if your students don't pay a whole lot more attention for the entire day.

And this is a problem with a lot of college classes. Many professors have no idea how their course material is used in practice (career academics are especially vulnerable to this), or they know but they aren't telling. When I first took Linear Algebra, we learned everything except practical application, so I did the familiar cram-for-the-exam-then-forget-everything method of study. Then I took Computer Graphics, which was really cool, and I realized that maybe I should have paid more attention since we were using scaling, rotation and translation matrices on a regular basis. And then I took another neat course where we learned about the math behind sending a space shuttle into orbit, which required a whole lot of dealing with vectors and matrices. And then I worked in the industry as a game designer of all things, and found that you could use matrices to solve certain types of game balance problems. This would have been nice to know when I was taking the course!

It's like a lot of professors out there imagine themselves as Mr. Miyagi from The Karate Kid. Wax on, wax off. Do that a few thousand times. After you're done, then I'll tell you how to kick the other guy's face in. That makes for great storytelling, but lousy pedagogy.

So, I see this as a huge advantage for professors who have actual, honest-to-goodness industry experience: we can share that experience with our classes. Why am I spending perfectly good class time talking about something abstract and obscure like positive feedback loops? Glad you asked, let me tell you about a game I worked on that had game balance issues because of a feedback loop that was unintentionally embedded in the core mechanics, and here's what we did to fix it. I'm not teaching you this stuff because the IGDA Curriculum Framework says I should, I'm teaching you the stuff that I've actually used myself on the job. So pay attention. (And they do, most of the time.)

Now, there is a danger here: you have to have the context but also the content. There is a perception in academic circles that the only thing an industry person does is come into the classroom and tell a bunch of entertaining war stories. You've gotta deliver the goods, too, so your students actually have the knowledge and skills that they're supposed to apply. But in my own experience as a student and as a teacher, there's more danger of too little context than too much.

The Paradox of Student Failure

Reading over my notes from GDC, I just realized that I commonly hear two pieces of advice for teaching:

• Encourage students to fail early and often. Being in school is the one time where you can do this without losing millions of publisher dollars in the process. BUT,
• Punish students harshly for failure. It's a tough industry, and classes should reflect that.

These aren't necessarily mutually exclusive, although it seems like it at first glance. The former is primarily concerned with taking creative risks: trying forms of gameplay that have never been done before. The latter mostly involves setting and achieving reasonable goals: controlling the scope of a project, keeping to a schedule and meeting deadlines.

However, the two viewpoints collide when you're teaching a studio class where the output is a complete game -- if the students try hard, but end up making a game that is just not fun or interesting (in spite of their efforts). As a teacher, do you grade them harshly, because a comparable professional project would mean that their studio would be out of business and they'd all be looking for new work? Or do you grade them generously for their ability to try hard, stick with a process and complete the project? Either way would seem to send the wrong message.

Teaching Portfolios?

One common mistake I warn students about (especially art and audio students, and to a lesser extent game design students) is to never include substandard work in a portfolio just to show how much you've improved. Game companies don't care about how much you've improved, they care about how good you are now, and whether you can help them make a great game now. If you put mediocre work in your portfolio, the message you send is that this is the best you can do.

It occurred to me the other day that this might not be the case for teachers. I've never heard of an instructor putting together a portfolio of their own students' work to show how much their students have improved under their tutelage, but I don't see why something like that wouldn't be valuable if you're marketing yourself as a first-rate teacher.

Likewise, a university might consider this for its promotional materials, the same way that the beauty industry likes to show lots of before/after photos so you can see how much of a change their products can make. Again, I've never seen this before, but at the moment I'm having a hard time thinking why not.