IGF Student Showcase Winners Announced

A list (with most games available for download) is here. If you're going to GDC, be sure to stop by the IGF booth and play for yourself anything that you can't play now.


Students wishing to win the IGF some day should take a good, hard look. This is the bar you need to meet or exceed as a student project.


Note that you do not need to be brilliant at all aspects of game development. Crayon Physics and Poesysteme have rudimentary graphics at best. The Misadventures of P.B.Winterbottom was done using some very simple scripting in Flash. Mayhem Intergalactic isn't particularly original game design (it's basically a "mod" of the board game RISK).


I do not point this out to put down this year's winners. All twelve are outstanding games (and I judged some outstanding games that did not make the list), especially considering that they are student projects. Rather, I say this as a word of encouragement to those students who are intimidated. Yes, the bar is high. But if you can truly excel in one or two areas of game development, even if you are lacking in the others, you've got a shot. Design and create the kind of game that really shows off your strengths, rather than complaining about your weaknesses.

What Teachers Need to Know about Game Design (Part 2 of 2)

Last time, I talked about why games are fun, and why classes aren't. How can we apply the lessons learned from game design to make classes more exciting and engaging? (Presumably you already see the benefit of this, but just to spell it out for the rest of you: if students pay more attention in class, they'll learn more.)


Three ways to use games in class:

• Play games as a classroom activity. This is obvious and it's effective, but it has several limitations. Games are great at teaching concepts, especially system models, processes and cause-and-effect relationships. They're terrible at teaching content, making them unsuitable for content-heavy classes. Also, most games are made for 1 to 4 players, and don't scale well to a 25-student class. Lastly, these require a good deal of "game literacy" on the part of the teacher, making it not suitable for all teachers; most classroom games are some crude form of Jeopardy!, only because the teachers lack the game experience to go beyond.


• Discuss the games that students have played in relation to the course content. This is easy: ask "has anyone played a game that has ____?" and then compare and contrast between the content in the game versus that in the class. This also has limitations. Not all students are avid gamers, so the comparisons will only be useful to a subset of the class. It also requires game literacy on the part of the teacher, to provide examples when the students can't think of any.


• Modify your teaching style to be more game-like. Add elements to your class that make them just as engaging and interesting as a game (for the same reasons). This is the hardest way to use games, but by far the most rewarding and least limited.

Game-Like Teaching:

• Games are interactive, not passive. It is the interesting player decisions that make the game. Include interesting decisions in class. This includes classroom discussions, a choice of topics or homework problems (with varying tradeoffs so that the more interesting ones are also harder or contain other "fun" rewards), and asking the class questions (either to individuals or by having everyone "vote").


• Applying flow theory (making the content at an appropriate level of challenge) is not obvious, because different students have different skill levels. One way to do this is to include multiple layers of depth to your topics; explain first what's going on conceptually at a fundamental level, then go into the details every student needs, and then offer additional insights for the advanced students. Another great place to do this is homeworks and exams, offering a variety of basic, intermediate and advanced problems so that all students can find their own level of challenge.


• Use as many different kinds of fun as you can think of in your classes...


• Exploration fun is difficult when you're stuck in a classroom, but field trips (especially open-ended ones where students are free to explore the area rather than being herded like cattle) can tap into this. If you have computers in the classroom, you can ask students to search the Web for information relating to a topic, providing a kind of exploration as they navigate from one page to another.


• Social fun is easy: group assignments, class discussions, and other collaborative exercises.


• Collection fun is something that happens mostly at the K-6 level, where teachers hand out gold stars and stickers. If you're teaching at a more advanced educational level, you may have to be inventive.


• Physical fun: include various physical objects that can be passed around the room in your discussions. Include "eye candy" -- neat-looking photos or illustrations that you can show around. Try including some music or other interesting sounds if you can tie them to class topics. Get the senses involved! I once had a physics teacher who would bring "props" to just about every class, such as throwing around a super-bouncy-ball when talking about elastic collisions; I know another professor who would make the entire class get up and stretch when she noticed students nodding off.


• Puzzle solving fun: ask open-ended questions, especially those that students really have to think about before answering. Group discussions and case studies fit this nicely. Some classes have content that is inherently a kind of logic puzzle (especially in the maths and sciences). In these cases, it helps to approach these as puzzles or mysteries, rather than as problems or exercises. Who ever heard of having a "problem" that was fun? What percentage of your students enjoy "exercise" as a recreational activity? Why do we use such not fun words to describe a fun process?


• Character advancement fun: is automatic in any class that builds on its own content over time (the kinds of classes where the final doesn't have to be "cumulative" because you need all the previous stuff to solve the latest questions anyway). At the beginning of the class, try showing the skills and concepts as a "tech tree" -- the same as you'd see in World of Warcraft or Diablo 2 or Civilization.


• Competition fun: here's where we see the old quiz-show standby. Formal debates can trigger this kind of fun too, as can informal debates that emerge spontaneously during class discussions on controversial topics.

As a parting shot, notice that most successful games are made with the players first in mind... not the creators, and not the content. Approach your classes the same way: design your classes around the students first, not the content and certainly not the teacher!

What Teachers Need to Know about Game Design (Part 1 of 2)

This is a summary of my talk at Origins this year. (Okay, I'm a bit late.) This information is targeted at teachers, although students may find it interesting as well because it explains why you'd rather play World of Warcraft than do your homework.

Games are fun. Most classes are not. You may notice students sitting at the back of your lecture hall playing with their DS rather than paying attention. It's worth asking the question: what does that silly little video game have that the lecturer doesn't? After all, it's just a game, but this class is important. Why shouldn't the lecture be getting students' undivided attention? And more importantly -- is there anything we can do as educators to change that?

To answer these questions, we first start by asking what makes games fun (and what makes classes less fun).

What makes games fun?

• Well, if we knew that, we wouldn't be a "hit-driven" industry (a nice way of saying that 90% of commercial games lose money). Still, the game development community has a better understanding of this than the teaching community, and there are a few useful theories that most game designers are familiar with. What follows is a small sample of a much greater body of work.
• Csikszentmihalyi's theory of "flow": you get deeply engaged in a task (any task, including "work") when it provides a challenge in line with your skills. Too hard and it's frustrating, too easy and it's boring... but if it's just right, it's magic.
• Corollary: as you perform a task more, your skills improve. If the task stays the same, you will eventually become bored. The tasks that keep you in the flow longer are those that increase in difficulty.
• Raph Koster's Theory of Fun: Games are fun because they're really good at keeping the player in the flow. Also, flow is fun because you're learning. (You may or may not be learning useful things from playing games, but you are learning something, and the brain finds that pleasurable.)
• Noah Falstein's Natural Funativity: Learning is probably fun because it's evolutionarily beneficial. The things that helped our ancestors when they lived in caves and trees are the same kinds of things that we find "fun" today.
• LeBlanc et al's MDA Framework: The word "fun" is not terribly useful because it isn't descriptive, and doesn't suggest how you create it. There are actually many kinds of fun: exploration, physical sensation, social experience, competition, advancement, collection, puzzle solving, and many others. These are all present to greater or lesser degrees in games; we're talking about a continuum, not a binary either/or composition of fun.
• Note that all of these kinds of fun can be traced back to hunter/gatherer survival skills. Social skills are important because we can work together to hunt animals that are too large or powerful for a single one of us. Exploration is important so that we can have larger areas of territory to find food in. Collection is simply the "gatherer" half of hunter/gatherer.

If learning is the source of fun, then, it actually seems strange that classroom lectures aren't inherently engaging. I believe the reason for the disconnect is that lectures are so far removed from the kinds of "learning" that ancient humans had to do for survival, that it does not trigger our play-instinct. Our pedagogy has outpaced our biological evolution.

Now you know the basics of what fun is and where it comes from. Next time I'll talk about how to apply this knowledge directly to the classroom. In the mean time, think about it yourself...

GDC: When it rains, it pours

From zero speaking engagements for the past two years, to two of them this year. I'm also on a panel ("Industry Veterans as Educators") at the Education SIG Summit.

I swear, leaving the industry was the best thing that ever happened to my game development career. Oh, the irony.

Pittsburgh Game Jam games available for download

As I've mentioned a couple times before, I participated in the 2007 Pittsburgh Game Jam. The games themselves are posted here.

In spite of the fact that the only constraints were technological (design for the XO platform, using Python and Pygame), and there was not a single mention of experimental gameplay or innovation in game design, a surprising number of games were highly experimental in nature (though sad to say, not mine). What follows is a rundown of, in my opinion, the most important games of the Jam and why students, teachers and professional developers alike should pay attention.

XO Maze (by Team Thailand), the winner of the jam, was a four-player cooperative maze game (if you've never heard of the "maze game" genre, think Pac-Man) with fog of war. Design lessons: Whenever a new innovation in gameplay is added to a genre (like fog of war in RTS games), someone should revisit all older games of all genres and see if the new mechanic will work with old games. In this case, it works beautifully. Another interesting thing: the developers originally wanted network play but it was broken, so they "settled" for having four-player on a single computer. The result was actually better than if they had network play -- it turns out, four players crowded around a single keyboard gives a uniquely satisfying experience when playing co-op. With all of the rush for modern consoles to have games that are all network-enabled, we must not forget the joy of sitting next to your friend and playing games on the same couch.

Caketown (by Team Argentina) is a puzzle game where you click on stuff to make other stuff happen; the object is to get the strangely cute zombie-animals to find each other, which lets them eat cake (don't ask, just see for yourself). Only two levels created during the Jam, but after playing them you can see the potential. Design lessons: This is a great experiment in UI. There aren't really any printed instructions or text, but the visual clues are still there to tell you what to do, and if you can't figure out the iconic signs you can figure things out experimentally by clicking on the stuff that obviously looks like it can be clicked on. If you're working on a game that requires the player to go through an hour-long tutorial just to figure out the basic rules of the game, try taking a look at this and seeing how the graphics and art (even environmental art) can do wonders to teach the gameplay.

Head Cat (by Team Brazil) is my personal favorite game of the Jam; the only reason it didn't win is that the judges were mostly 8 to 12 year olds, and the creators of this game admitted that they ignored the judging and just made the game that they wanted to make (it's clearly targeted at a slightly older audience). The gameplay is something between Lemmings and The Incredible Machine. The goal is to get your programmable robot to the cat; the cat then happily goes to sleep on the robot's head (anyone who has ever owned a cat will instantly understand this). Design lessons: This is a great example of what I unsuccessfully tried to teach my Capstone class last year -- namely, to attempt depth of mechanics instead of breadth (especially when working on a time-limited project, such as a Game Jam game or a semester-long class project). There are only a few player verbs in Head Cat: the drill (breaks blocks beneath you), the balloon (slows your rate of falling), the magnet (pulls you up if there's another magnet overhead), and the ability to detect running into walls and floors and reverse direction. Each of these was clearly easy to implement, and yet look at the variety of levels and challenges! The developers even had time to include a full level editor, and I imagine you could make 50 or 100 levels with just the mechanics that exist in the game, alone. Incidentally, it's also an example of how a cute theme can take a decent game and make it instantly memorable.

Honestly, all of the games were impressive for some reason or another. Fruitix (Team Ethiopia) is something like a retro-arcade version of Harvest Moon. Red Bird (Team Tibet) is a timing-based puzzle game, something like a Match-3 game where all panels are the same color and their position matters rather than their color. Star Catcher (Team Peru) had some very satisfying 2D physics and a full level editor (remember that these games were made in about 36 hours). Tumble Boy (Team Libya) did what I tried and failed to do: get scrolling to work on the XO at a reasonable framerate -- and it not only included a level editor, but made it accessible as a plaintext file that you could edit in notepad. Light Ball (Team Nigeria) was another impressive physics game, with the interesting mechanic that you're trying to prevent the sun from going out -- so you have to balance your limited ammunition with the limited time that the sun has left, and in the mean time the screen starts going dark (making gameplay more difficult). I guess what I'm saying is, download and play all the games; you'll be happy you did.

And play with the sound on. All of the games have sound; sometimes it's critical to gameplay, other times it's just amusing, but I can't think of any game that had actively horrible sound. Except perhaps my own, as I explained.

IGF Student Showcase 2008

So, I'm a judge for this year's IGF student division. (Due to an email mixup, I found out about this two days ago, so I've been frantically playing since.)

Some of the entries I've seen are so amazing that I can't believe it's a student team and not a commercial product. Others are so bad that I wonder why they even bothered submitting. Still others, I never even got to see because they crashed before starting. With this in mind, I present some advice to future IGF entrants (student and otherwise) based on the common mistakes I've seen this year.

Find the fun in the first 30 seconds. I was given 21 games that I had to judge. That means realistically, each game is not getting ten hours of play. If the really cool stuff is on the last level, I might never see it. If the really cool stuff isn't even in the game (say, you're making a demo for an RPG and all you've got is the first dungeon where you have to kill 50 rats), you fail -- make one of the later, more fun levels for your demo instead.

Include level select and other cheats. Suppose I'm playing through your five-level demo, and my machine crashes near the end of level 4. Do you think I'm going to replay everything just to see level 5, or do you think I'm going to assume I've seen enough and move on? If I can jump immediately to level 5 with a level select, maybe I'll give it another try; if I have to replay the entire game, forget it. Likewise, if the first level is so difficult that I lack the skills to make it past, give me "god mode" so I can at least see the rest of your content.

Include single-player mode. Not everyone has a gaming group they can play with. If I'm judging on my own, and you require 4 or 8 player simultaneous, I won't be able to review your game at all. If you add AI opponents that allow single-person play, this at least lets me play around with the mechanics somewhat. If you don't have the time or skills to implement a full AI, have the opponents sit there and do nothing and call it a one-player "tutorial". Either way, at least let me play.

Avoid mods. Just like not everyone has a group of gaming buddies, not everyone owns a copy of Unreal or Half-Life. If your game is a mod that requires judges to have software other than your game itself, it might not get judged by as many people. If you must make a mod, be very clear about it in the requirements list when you submit your entry; this is just courtesy, so that judges lacking the ability to play don't waste time on it.

Avoid crashes. It should seem obvious, but I saw some games that actually crashed on startup! Test your installer on a few "virgin" machines before submitting. These last three points can actually be summarized as one: let me play your game!

Don't overhype in your description. Each game has a brief text description. I read it when I'm waiting for the game itself to download. Some people are really full of themselves, telling me all about how original their game is or how great their graphics are or how fun the game is. Don't insult me; I should be competent enough to judge your game on its own merits, not on your opinions of your own game. This actually has the opposite effect for me; if you tell me how original your game is, it just makes me think really hard about what other game(s) yours is derived from. Unless your name is Peter Molyneux, leave the hype to the marketing people.

Make sure the player is having fun, not the computer. Sid Meier's immortal advice rings true in a surprising number of student games. Your game might have an amazing AI or some really complicated mechanics under the surface, but if I can't see, predict and understand them then I'm not really having fun as the player. Try giving your game to someone who knows nothing about it and has never seen it before, and after they play ask them what's going on. Anything they can't tell you is something you need to work on.

Grow a thick skin. Judges can submit anonymous feedback, and we're told that it's perfectly okay if we're harsh (as long as we're also constructive). No game is perfect, especially a student game, so expect everything you've put your soul into to be ripped to shreds. (If it makes you feel any better, you'll get to go through this again once you get into the industry, when some reviewer for IGN trashes the game that you put the last three years of your life into.)

Communicating With Students

I ran into a friend after the game jam, and we got to talking about (among other things) how teachers throw up red flags to students when they see project scope spiralling out of control.

Instructors say things like:

• "This looks like an ambitious project."
• "That's an aggressive schedule."
• "I think you're being very optimistic."

What students hear, respectively:

• "You're an ambitious student. You've got tons of initiative. You're a real self-starter. That's a valuable thing to have in the world."
• "You've got the guts to do what it takes, without letting obstacles get in your way. Go get 'em, you aggressive tiger you!"
• "You never lose hope or let things get you down, and you've got a positive attitude. I value your optimism."

What the professor actually means, in all three cases:

• "You don't have a snowball's chance in Hell of completing this project. It's way too much work and/or way too advanced for the time you've got available, and if you attempt it you're going to fail miserably... if you don't kill yourself in the process. Reduce your scope and bring things back to something remotely reasonable. But... if you insist on trying and failing anyway, in spite of my repeated warnings, it is your right and privilege to try. But don't say I didn't warn you."

I think we professors need to be a bit more clear. Next time I see an overly "aggressive" student project, I'll be a bit more direct when I say so.

The Life Cycle of Course Content

A "news" article today (I hesitate to call this journalism without adding quotation marks) suggests that few people understand how universities change their content to keep up with industry. In particular:

And that's what makes Qantm unique - we're not a university, because what people don't realise is that with a university it takes at least three years to change a course. If a lecturer now sees that companies are using a new language to program in, it'll take him three years to implement it in the course.

This is simply not true. There is a subtle but important difference between the content of a course, the course listings in the catalog, and the course curriculum. I will explain.

Course content is the stuff that actually gets taught within a single course. In my Game Industry Survey course, I have modified the content in minor ways on a day-to-day basis; for example, if the Activision/Vivendi merger happened the day before my talk about game publishers and how EA is by far the largest, you can bet I'd be modifying that content the same day. I certainly wouldn't be waiting three years before I started talking about it in class! Minor stuff like this gets incorporated all the time.

Granted, minor content changes like that aren't quite as drastic as, say, switching from Java to C# in an intro programming class. In that case, the instructor might have to wait until the next quarter/semester before changing the language around, but it can certainly be done. And even if the game industry suddenly decides tomorrow that every programmer absolutely must know C# from now on and it's the last week before finals, an instructor could still modify the last lecture of the quarter by talking a little about this newfangled C#, and how it's similar to the language we learned during this course and how it's different, and that all of the students should learn it on their own over winter break if they want to get jobs, or whatever. There's still no three-year delay.

Course listings, i.e. what courses are available for students to take, can obviously not be modified in the middle of a semester. However, they can (and frequently are) modified on a semesterly basis in the form of "Special Topics" courses. Special Topics is this wonderful catch-all that lets professors offer whatever the heck they want. Sometimes it involves the professor talking about their (very narrow) area of research; sometimes it's a brand-new course that should be added to the curriculum, but the professor wants to try it out just to make sure; sometimes it's a course that's important but offered so infrequently that it never got its own dedicated course number; and sometimes it's just an off-the-wall experimental course idea that a professor has just been dying to try out one of these days.

At any rate, there's always a selection of Special Topics in each department, and they change on a regular basis. Again, no three-year lag time here.

The course curriculum is what changes every 3 years (an approximation -- I'd assume that at a four-year institution it would change every 4+ years, while a two-year community college could modify their curriculum every 2+ years). These numbers are not set in stone, by the way: they are a practical consideration. How can an established university build a reputation for producing quality graduates if the core curriculum of this year's graduating class is different from last year's? This is not (entirely) about universities being slow, bloated bureaucracies... I mean, they are, but that's beside the point... this is about universities not kowtowing to every little whim and fad of the industry, and waiting for trends to become established before they force them on the unsuspecting student population.

So, let's suppose a new programming language becomes popular. C# is so 2005, today it's all about Ruby (not really, this is just a contrived example). Starting next quarter, a Programing in Ruby special topics course magically appears. Academic advisors let their students know that Ruby is the next big thing in the game industry, and they'd better learn it before they graduate if they want even so much as a job in QA or the mail room or something, and they're highly encouraged to take the special topics course if they don't just learn it themselves over winter break. Unfortunately, it only counts as an elective, but creative advisors might be able to substitute the special topics for the Programming in C# course that used to be a core requirement; for students who took that already, at least it's a programming elective. A few years later when it's time to revamp the curriculum, the Ruby course displaces the C# course, and all is well.

Until two years later when the industry suddenly decides that Ruby is so 2008, and the thing that everyone really needs to know is this newfangled C+@#$ (where you program by shouting profanities at the computer, with voice-to-text support in the IDE), and the cycle begins again.

Oh, and one other quote from that stupid article that I feel the need to correct:
Initially there was no master plan for SAE, for colleges and things, but it turned out that I invented practical education, because nobody before me was doing that. In a way I formalised education.

I'm supposed to believe that it never occurred to anyone in the thousands of years that humans have inhabited the planet, to have education that's actually practical? If David Braben invented practical education, then I invented the internet.

Bah.

Reinventing the Syllabus

It occurred to me the other day that my classes aren't traditional in any other way, so why do I keep handing out a formulaic syllabus? Here's the cover sheet I came up with for my class on the game industry; it remains to be seen whether I can get away with actually using it, but it was a fun exercise regardless... (click to enlarge, or download, or something to take a closer look at all the text.)

Culture Shock: Assumed knowledge and skills

Everyone thinks they're a great game designer. Even if they have no experience. Even if their idea of a great game is "the game I want to play, even though no one else will want to." If you tell people you're a game designer, one of the two typical reactions is "hey, I have this great idea for a game..." (the other reaction is "what's a game designer?"). Basically, it doesn't matter if you're a Junior Designer on your first gig or if you've got twenty years experience; everyone you meet thinks they're a better designer than you. This is something you get used to pretty quickly.


Strangely, I didn't see this much when I became a teacher. I don't think I ever had a single student who felt that they knew more about game design than I did. The student/teacher social dynamic is apparently stronger than the "everyone's a game designer" thought process. I have no explanation for this. (It's not just that I have the power of assigning grades; students who didn't even take my classes treated me with a respect that I'm totally not used to.)

Why GPA is Important (and why it isn't)

I have a confession to make. I gave the incorrect GPA on my resume, back when I included it at all. (Getting numbers wrong is an occupational hazard of being part math major.)

Here's what happened: For my first summer internship, I listed the most current GPA that I had at the time. For subsequent positions when I updated my resume, I never got around to updating my GPA. My actual GPA was about three tenths of a point lower than what I reported. This wasn't out of any malicious intent to deceive, it's just one of those things that fell through the cracks. I didn't even notice that I did this until just today when (for the first time ever) I managed to get my hands on my own unofficial transcript.

Now, here's the funny thing. In all the time I've been working, no one ever called me on this, which probably means that no one ever checked. It's possible that no one ever could check, that GPA is confidential and the most a university can do is to verify that so-and-so attended in such-and-such a year. When you apply for a university position, at least, some of them require you to send an unofficial transcript as part of the application package -- which is how I came to notice my own transgression.

This would seem to imply that I managed to get by in the industry on the strength of my experience and my interview skills, and little details like grades didn't matter much. To which some students will say "Great! Then I can stop spending all of my time studying, and just play more Halo 3, since it doesn't matter anyway!" and other students will say "You mean I can just put that I got a 4.0 on my resume and they'll believe it?"

I would say no to both.

Why not to falsify your resume: even if the odds are low that it will be checked, if you apply to the one company that asks for a transcript, you're in trouble -- it's a small industry, and people will talk. I at least had plausible deniability; if you're a C student pretending to be on honor roll, it's hard for you to say it was an accidental typo.

Note to people in industry: check references of new junior hires! Seriously. Some people will lie. Even if they don't, when I offer to be a reference for one of my students, it means I want to be contacted so I can give the honest dirt (and, honestly, so that I can then contact that student and let them know that this company checks references, which is a good sign that they might make fewer bad hires than average). You may not be able to verify their GPA, but at least verify what you can.

Why not to slack off and stop caring: because your education might not end when you get your Bachelor's degree. Maybe you'll want to head directly to graduate school, where your GPA is most certainly a factor in which places you can get into. Maybe you'll delay awhile and decide to go back to school later; even if you're burned out on school now and don't think you'd ever want to do that to yourself, time might change your mind. Maybe after your requisite 5.5 years in the industry you'll decide to go into teaching (like I did), where your previous degree(s) and your GPA are a factor. And yes, being able to put a big number on your resume might be the one last excuse a game company needs to hire you.

Oh, and I should add that the stuff you're learning in college is actually useful (even if you can't see why right now, since most teachers suck at showing the context of their subjects) and the same actions that get you an A are those actions that actually help you learn. Most of the time.

The Fairness versus Usefulness Tradeoff

Game designers love tradeoffs. Tradeoffs are one kind of "interesting decision". Life is full of all kinds of tradeoffs (it has in fact been argued that life is simply a massively-multiplayer game... with extremely realistic graphics). Teaching has its fair share as well.

Here's one that I'm discovering: the more useful an experience that some exercise (an in-class presentation, homework problem or project) is, the more subjective the grading is.

It's very easy to create a multiple-choice exam where each question has exactly one, clearly correct answer. The grading is easy and the grades themselves are inherently fair. But students don't actually learn anything by taking the exam, they merely show you what they've memorized. The same is true for homework questions that are direct enough to have exactly correct answers.

By contrast, essay questions, open-ended student projects and creative exercises all lend themselves to both student and teacher interpretation. Even if you think you know what you're looking for in order to grade objectively, some students will surprise you with unexpected answers and you'll have to revise your grading methods. Sometimes a student answer will, on reflection, be better than your own. Sometimes you will simply not understand what a student is saying, and they will be completely correct and it's your own fault for misinterpreting their answer (you can weasel out of this by saying "if I didn't understand it then it was poorly written" but I would consider that the height of arrogance in most cases).

And yet, these subjectively-graded exercises are the most valuable because they force the students to actually design something.

In terms of teacher evaluations, this means that any class where I score well on "relevance to the real world" is probably also a class where I score poorly on "fairness of grading"...

I Came, I Saw, I Jammed

Participating in a game jam is a very different experience than coordinating it. Each game really is like a full AAA development cycle, time-compressed down to less than 48 hours; spending a weekend on this can practically give you as much experience as working on a full game, so I highly recommend it to students and professionals alike. We even had a fair population of people who have never made a game before at all, so I would recommend this for instructors as well.

In true Post-Mortem fashion, here's how it went for my team:

What Went Right:

• Multiclass Developers. On a small team with such a short deadline, having people who only know how to do one thing can lead to some precious time wasted; designers must sit on their hands while waiting for the programmer to implement their designs, while programmers and artists have to wait at the start until they know what they're supposed to make. Since team size is constant over the project (you can't scale up after "pre-production" like you can in industry) you need to make sure everyone is occupied constantly. I was a programmer/designer for my team, along with two artist/designers and a designer/audio guy. We all collaborated to get a basic concept quickly, and then everyone had some content to work on once we were done. Lesson for industry: The value of generalists with multiple skills increases in proportion to the rigidity of team size.
• Research. The goal was to make a game for kids age 8-12, which none of us had done before. I took the liberty of scouring Gamasutra for relevant articles, and talking to colleagues about what kinds of design rules are different when designing for this age group. I'm glad I did; we did not have the benefit of anyone sharing tips on this at the start of the event, nor did we have the opportunity (or the time) to focus test. Lesson for industry: If your project involves targeting a demographic that doesn't exist on your development staff, make an extra effort to remedy this.
• Constantly Shippable Code. We had something playable within a few hours of starting. It wasn't complete but it did run. This gave us the advantage of flexibility; no matter when we ran out of time, we knew that we would at least have something to show for it. Lesson for industry: Always have something to show. I think this is even more important in a world where deadlines can change, and publishers can unexpectedly drop by and ask to see how far along you are.
• Concept and Technology. We first asked ourselves how we could keep the control scheme so simple and obvious that we wouldn't need any text to explain it; we came up with the idea that you controlled a paper airplane by "blowing" on it, using a flicking motion on the touch pad to blow wind that would cause the plane to move in that direction. I think we got that part of the game feeling pretty good. In the process we also managed some things that Python and Pygame (the required language for this hardware) were never intended to do: smooth-scrolling backgrounds, and adaptive background music that would gradually get more frantic and intense the faster you scrolled.

What Went Wrong:

• Scope. We designed a game that we knew we could finish within the allotted time. Unfortunately, it took exactly the alotted time, so we had no time remaining at the end for polishing the graphics, sound or gameplay. As a result, our final project was one of the least compelling games of the jam. Lesson for industry: Design games that can be made in far less time than you have, and then use the extra time in the schedule to polish what you have in an extreme fashion.
• ...And More Scope. Our audio designer went AWOL on the last day of the jam, with his work left unfinished. As a result, we had to divert some resources away from art just so that we had at least some background music, and what we ended up with was just thrown in at the last minute. The final game sounds horrible, even though it has the capability of sounding amazing. Lesson for industry: Avoid having people on your team who are irreplaceable, in case they get hit by the proverbial bus (ours might have been hit by an actual bus for all we know). Thank goodness we didn't have a multi-million dollar development project at stake!
• ...And Even More Scope. We originally expected to have 14 regions in the final game, because the artists were able to finish the first region in only an hour or so, and at that rate that left them plenty of time. But the artists couldn't sustain such a high rate of work after sleep deprivation set in, and cut down to 7 regions... and four of those were thrown in at the last minute, so we should have cut down to only three or four (and just made those look really good). We also lost a lot of time to an undocumented technical limitation: Pygame blows up if any sprite is more than 14400 pixels wide, so instead of having one massively wide background we had to break it up into several regions, with one screen-length overlapping from each region to the next. This forced the artists to re-work a lot of their original files, costing valuable time that wasn't accounted for in the original schedule. Lesson for industry: Design your core mechanics to have scalable content. If your game needs a large number of levels to be playable, and you run into scheduling difficulties, you're in trouble. If your game can support a short play experience but becomes boring and repetitive if you try to add an extra 20 hours of gameplay time, you're also in trouble. Best case is a game that works no matter how much content you have, so that you can add exactly as much as time allows and know that it will be fine.
• Concept is Nothing; Execution is Everything. Our execution was okay (especially considering we only had a couple of days) but not spectacular. A lot of great ideas were simply not implemented in a way that made them realize their potential. I tell this to my students over and over again, but saying it is one thing and experiencing it is another. The winning games were all very simple concepts with relatively little content, elegant mechanics and a high "fun" factor. Lesson for industry: Maybe the lesson here should be, make all of your mistakes in Game Jams rather than on big-budget projects. If you ever want to try a new development methodology (maybe you've always worked in Agile development and wonder what could possibly go wrong if you try to design everything up-front in a comprehensive design doc, or you've never done Rapid Prototyping, or you want to see the effect of a lengthy preproduction, or something), try it in Game Jam form, with the understanding that an hour of a Game Jam is roughly equivalent to a month on a large project if you're trying to compare schedules. You'll probably learn a lot about what works and what doesn't work, without wasting huge development resources.

I'll update this post with a link to the games, as soon as it's online.

Teaching Game Design in the Middle of Nowhere

Columbus, Ohio is not exactly a hotbed of developer activity, but we do have an official IGDA chapter. Michigan is in a similar state, and they sent a very interesting meeting summary to IGDA's Game_Edu list a few weeks back. The results of their meeting are relevant to teachers and students alike. To paraphrase:

• Students living in locations with few (or no) developers should accept that they will need to move out of state in order to find work. (I would add: even students living in big game dev areas may need to move out of state from time to time, if they have trouble finding local work or if they get offered a dream job at a studio halfway across the country.)


• Finding qualified teachers is difficult everywhere, but especially in out-of-the-way areas (most professional developers who want to become teachers would not like to move to the middle of Michigan for the privilege, especially when there are perfectly good universities local to you no matter where you are). Universities in out-of-the-way areas can offset this somewhat by paying to fly guest lecturers in on a regular basis, but this can get expensive. Many universities require their professors to have at least a Master's degree, which is rare in the industry, and just makes a difficult thing harder.


• The industry can change quickly, obsoleting course material and even entire courses in the curriculum... but universities tend to move slowly when it comes to curriculum adjustments, which can be problematic in the medium term. Suggested way to deal with this: make course titles and descriptions general in nature so that the content can be modified on a per-semester basis as needed.


• The often-asked question: is it more important for art students to know fundamentals or tools? (I would add that the same question applies to programmers and designers.) The unhelpful but still correct answer: both!


• Game development is incredibly interdisciplinary, but most universities have these huge walls between departments. How do you overcome this obstacle? No easy answer, other than "design the program to address this issue from the beginning" -- suggesting that incremental additions (start with one game-related course, add a couple more courses next year, eventually expand into a full program) is doomed to be restricted to a single department and will not capture the interdisciplinary nature of real-life development.


• As university programs get established, we want to start thinking about ways to push this further down the education chain into high school. Several universities reported success with offering one-week summer camps: they serve the triple purpose of community outreach, exposure of the field, and recruitment.


• One of the hardest things when dealing with students is to convince them to work on small games and complete them, rather than working on a single huge sprawling mess that dies under its own weight. It's also hard to convey the 80/20 rule, that 20% of the work gets you the first 80% of the game... but getting that last 20% of the game (which is the polish factor) takes a lot of time after the game already feels like it "should" be done, and pressing on when you're sick of working on the game already is what separates the developers from the wannabes.


• Interestingly, the bar for entry into the industry is getting higher because of the high quality of university-level instruction. Ten years ago, some modding experience and/or a single completed game was enough to set a student apart from the rest of the pack. Today, it's more like 2 to 3 games. I see this as a good thing (it means that at least some of the universities out there are doing their job). I also see it as implication that we should start requiring some business courses integrated into any game development curriculum... because we'll need more students to start their own game studios to make more jobs to soak up the excess supply of talented individuals.


• Schools should give all of the rights to student-created work to the students themselves (sadly, not all universities do this). Schools should also have policies in place to determine IP ownership if a professor makes a game (or collaborates with a game studio in some way); ideally this policy should be very friendly to the individuals in question, to encourage industry/academic relations. In any case, work this out first, before it becomes an issue that must be solved on the fly.

Creativity

I was thinking the other day about the question that is the tagline of this blog: can you teach creativity?

I'm afraid to say that the question may itself be flawed. There's a deeper question here: do we even need to teach creativity?

Everyone in Hollywood, even the janitors, has their own idea for a movie script. Everyone in the game industry, down to the lowliest of the QA staff, has a game idea. Yes, most of these ideas aren't worth the paper that they'd be printed on, but that's not the point. The point is that each idea is creative. Maybe not particularly innovative, maybe not fun... but creativity, it would seem, is an ability that all humans are born with.

I have precious few traditional art skills. I can't draw, sketch or paint to save my life. But I still can form images in my head that I think would make great pictures -- I just lack the technical skills to express them. Technical skills can be learned. They can also be taught.

I think that game design is the same. Maybe you have a great idea for a game, or a lousy idea... but it's an idea. All you need are the tools to express it. In my case, the tools are not paints or pencils or canvas; they are Word and Excel. My technical skills do not require an understanding of perspective or vanishing points or character rigging; rather, I need to understand the fundamentals of pacing, flow and game balance. All of these are skills that can be taught, and then it is up to the designer with those skills to go forth and design a game worth playing.

Of course, this all leads to the question: how does one know if a game is worth playing while they're designing it? The same question could be asked of the painter: how do you know this painting will be any good once you've finished it? That is much harder to teach (although it does come with experience)... but that's not creativity, that's craftsmanship.

So, perhaps I should rename the tagline of the blog. Is it possible to teach craftsmanship (without a ten-year one-on-one master/apprentice relationship)?

Speaking at GDC

In news that I'm sure will be completely unsurprising to any who read this blog, I'll be holding a roundtable entitled Breaking In to Academia. Session info is here.

This is a huge honor for me. Five years ago, if you'd asked me how I would know when I finally "made it" in the industry, I'd have said "when I'm a speaker at GDC." Ironically, I get my 15 minutes of fame after I stop working full-time in the industry (arguably, I get my 15 minutes because I left the industry). Life is strange that way, sometimes.

Anyway, I hope I'll get to see at least a few of you there.

New Teaching/Design Blog

Another one joins the field.

Brenda Brathwaite, a former co-worker who headed from industry to teaching about half a year before I did, just started a blog about her adventures in the strange land of academia:

bbrathwaite.wordpress.com

Welcome to the blogosphere, Brenda!

Pittsburgh Game Jam

This November 16-18, I'll be attending the inaugural Pittsburgh Game Jam. If any readers of this blog happen to be in the area, drop by and say hi!

This is exciting on multiple levels for me. For one, I haven't been back to my alma mater since I graduated (the ETC didn't even exist last time I was on campus, and I hear we eventually got a new Student Union too). Also, for all the talk of how great Game Jam events are, and even though I've coordinated one of them, I've never actually been a participant... and I'm looking forward to seeing what I'm capable of under extreme duress. Lastly, this particular Game Jam requires making games for young children -- a demographic I haven't had much experience with to date, so it will be nice to gain some additional understanding of the design constraints for this market.

Strangely, I'm signed up as a Programmer, not as a Game Designer. An event coordinator told me that they have a shortage of Programmers, which surprised me -- back when I was an undergrad, even the English and Humanities majors knew some programming (not typical of most college campuses, but CMU is a haven for computer geeks of all stripes). This is a school where they gave out free floppy disks to boost attendance at football games. And there's a programmer shortage? Well, it gives me an excuse to learn Python, which I've been putting off for a couple of years now, so I can't complain about the hand I'm dealt.

Textbook Review: Break into the Game Industry

This is part of the series on book reviews.

"Break into the Game Industry: How to get a job making video games" (Ernest Adams)

I almost didn't want to review this book. After all, it's obviously a vocationally-oriented book that has no place in the classroom as a text, right? While there is certainly a strong focus on the "breaking in" aspect, it turns out this book has a surprising amount of overlap with my Game Industry Survey course topics, suggesting that it may have more use than the title suggests.

This book starts with a reasonable (if brief) look at the history of the industry and then goes right into the bits of how the industry is structured today: platforms, game genres, business models, job roles and responsibilities within a developer. This is important stuff for any aspiring developer to know, and it takes up about half of the book.

About a third of the book is devoted to what the title implies: what kind of education and experience to give yourself, and the actual process of applying for a job. This strikes me as the kind of thing that students should read on their own, rather than something that's part of any course material.

Lastly, the book ends with a short section on the minimum everyone should know about legal issues (IP, NDAs, and how to read an employment contract) and a final wild guess on the probable future direction of the industry.

It should be noted that this book was published in 2003. This has the obvious implications: some of the information is woefully out of date. Notably, this was written before the downsizing of E3 and before the ea_spouse letter. Some of the companies mentioned are no longer making games. That said, a surprising amount of the practical information in this book is still valid, although it is definitely living on borrowed time -- I'm not sure how many more years it will be useful before the obsolete material outweighs the usefulness of the rest.

Students: If you are interested in getting into the game industry or you'd just like to know a bit more about what it's like behind-the-scenes, this is a great book to read. I can't say that it's fun to read exactly, but the information contained within is obviously practical and useful which might give you the incentive to keep reading anyway. At least for now, most of the obsolete material involves things that can easily be checked online, so for any specific piece of information you'd do well to confirm it by firing up your browser.

Instructors: It doesn't have any end-of-chapter exercises so you'll have to make your own, and you'll have to supplement it with modern history (the current generation of consoles, the effect of World of Warcraft, etc.), and it has a title that will make other academics glare at you if you use it as a required text in a class. But it still has a lot of useful information about the industry, so if you teach a class about the game industry you might at least consider making it an optional text in your syllabus. And if you have no industry experience, you could do with reading it yourself to supplement your existing course materials.

Professionals: If you already have a job in the game industry, then you probably know most of this stuff already, so it's not really worth your time to read the whole thing. That said, if there are aspects of game development that you don't know much about, this is as good a primer as any to show you what the heck it is that those people in that other department are doing all day; I learned tons about art and game audio, which were always something of a mystery to me.

Emergent Design: Freedom is constant?

Had an interesting discussion awhile ago with a student where we came up with a theory that has probably been discussed elsewhere, though I'm not immediately aware if it has (the subject came up recently in another class I'm taking, and it reminded me of this):

The sum total of the freedom of a game designer to create the world, plus the freedom of the player to alter that world, is a constant.

An RPG like Final Fantasy that has more or less a linear, established plot gives the player relatively few choices in terms of affecting the game world; the player may have different strategies for beating monsters over the head with sticks as efficiently as possible, but at the end of the day they're going to save the world, rescue the princess and kill the evil wizard all the same.

Compare to Fallout or the Elder Scrolls games where the player has more control over the game world, but now the game designer is constrained: it's easier to create a world, but harder to tell a compelling story within that world.

I think this is, by and large, the difference between Eastern and Western RPGs.

Textbook Review: Chris Crawford on Game Design

This is part of the series on book reviews.
"Chris Crawford on Game Design" (Chris Crawford)

Chris Crawford is an interesting character of the industry. He's been in the industry since its very beginnings. He is so animated as a public speaker that it is physically impossible to be bored while listening. He is outspoken, highly opinionated and quite curmudgeonly. He can be egotistical at times; some would say he's earned the right. The industry owes him a debt of gratitude for starting the first incarnation of GDC in his living room. (Personally, I considered this debt paid in full when, at GDC 2006, he told a room full of game developers that games were dead as an artistic medium. Which left me to wonder what he was doing in the Game Developers Conference if he no longer wishes to be a game developer. But I digress.)

It is important to understand at least a little bit of the man when reading this book, because the author projects a lot of his personality into it. This is not a stuffy, academic textbook by any means; this is 100% pure Chris Crawford opinionated ranting. In short, the book is exactly what the title says -- no more, no less. This makes it worthy of study, but also of limited use.

So, what is in this book? Roughly the first half talks about general game design concepts: the nature of play, challenge, interactivity and so on. The second half includes a chapter on every game that Crawford ever designed, and the lessons he feels he learned as a designer. Somewhere in the middle there's a chapter devoted to recommended books to read, and another on games to play, for the aspiring designer -- which both include an overly-biased dose of Crawford's own work. The book ends with a wonderfully entertaining (if not necessarily educational) chapter called "Old Fart Stories".

Anyone who reads this book needs to keep a box of salt at the ready, to take one grain at a time with each sentence. Some of Crawford's assertions are bathed in wisdom. Some are a bit off the mark. Some appear to be the ravings of a madman. It is not immediately clear which are which; readers must make up their own minds. As such, it helps to have a solid academic foundation (if not outright experience) in the field before reading this book; you'll need it to make your own informed opinion.

All that said, it's an easy read, so it's probably worth the weekend that it takes to skim through it. Different people will get different things out of it, but it's worth at least taking a look at so you can decide for yourself what nuggets of brilliance (if any) are embedded in the book. Unless you have absolutely no respect for Chris Crawford, in which case you're not going to buy this book anyway. (I've met developers who worship Crawford, others who despise him, and a few who are in between. Hmm. Maybe you should try meeting him in person before deciding whether to read his book?)

Students: Do not read this until you've already done a lot of other study and practice; otherwise you're likely to just get confused when the things that he says start contradicting what you'll learn in later classes. When you think you're ready, go ahead and read it, being prepared to have your own debates with him in your head.

Instructors: Since this is not a comprehensive text (nor even a particularly focused one), I can't see it being used as the basis for an entire course. As part of a higher-level theory course where students are expected to compare and contrast various designers and their rhetoric, this could be one of several books... although depending on the length of the course, again, it may not be practical to have students read more than an occasional excerpt (and forcing them to purchase five or ten books just to read one chapter from each is just cruel).

Professionals: If you work in the industry you probably know the author, by reputation if nothing else. If you've seen him speak at GDC, imagine all of that dropped into a book and you know what you're in for. You'll probably read about some obscure games that you've never even heard of (mostly Crawford's own) which I suppose has value in itself, and debating the finer points of this book with other designers could be an interesting exercise if you can convince them to read it at the same time. But due to the large amounts of questionable material in this book, I'd leave it until after you've covered the more important works.

Evaluating textbooks is easier than game engines

It just occurred to me why I've had no problem reviewing dozens of texts for my classes but I haven't gotten around to evaluating even a single game engine for classroom use (even though I have about five on my to-do list).

Evaluating a textbook is easy. I'm already familiar with most of the content I'd be looking for, so I can skim chapters. I'll typically read a few key areas closely (those that I plan to emphasize the most in class), which gives me a good idea of the author's general approach. I can usually get through a textbook this way in an afternoon or two. If I'm assigning readings in a course, I can read the passage myself the night before we talk about it in class, so the details can be spaced out.

A game engine, by contrast, demands that I learn something that I'm unfamiliar with (the particular capabilities and syntax for that engine) and then create a couple sample projects with it in order to get a feel for how easy it is to develop with. It takes me an afternoon or two just to read the documentation, and then another couple weeks or so to get used to developing games with this particular tool. And if I'm going to demand (or even suggest) the use of a game engine in a course, I should be proficient from the beginning since students will likely have some advanced questions as soon as they start. So, the time commitment is much larger and also must be given up front -- two things that are the bane of a full-time teacher.

I haven't yet found a way around this. I'm not sure there is a way around it; I (and the other teachers I've talked to) use the tools in class that we're familiar with.

Textbook Review: Introduction to the Game Industry

This is part of the series on book reviews.

"Introduction to the Game Industry" (Michael Moore)

(No, this wasn't written by that Michael Moore. I think he's generally too busy making movies to do much game development. Not that there's anything wrong with a documentary filmmaker creating a video game.)

Now, with that out of the way...

From the title of this book, I would have assumed it would be looking at the past, present and future of the game industry (without getting into the gory details of actual game development). But it turns out this book is more like a "lite" version of Rabin's "Intro" tome... with a stronger focus on game design, production and business. There is some history of gaming, but it is more of a sidebar to the rest of the book.

The timing on this book's publication was unfortunate. It was finished in late 2006 and published in early 2007, at a transition point in the industry (with the upcoming release of the Wii and PS3 and downsizing of E3, among other things). This means that any modern examples in the book already appear dated, and the poor book hasn't even been out for a year yet.

Maybe I'm a stickler for details, but I was disappointed at the editing of the book. There were a number of embarrassing mistakes; in the first few chapters I saw a comment on the steady decline of the physical boardgame industry in the 1990's, without any mention of the Eurogame resurgence; "A game is a series of interesting decisions" was attributed to Sid Meiers; and the heroine of Tomb Raider is apparently named Laura Croft. These may be little things, but they're exactly the things that end a conversation between a student and some professionals. I could understand sloppiness from an author with no experience who just wanted to cash in on the whole games-in-education trend; I would expect better from an industry veteran who teaches at DigiPen.

Perhaps more dangerous is that in 2007, this textbook largely teaches that games are created through the Waterfall model. It does acknowledge rapid prototyping very briefly, but makes no mention of Agile development that was all the rage as of the time of printing (and still is, to my knowledge).

On the bright side, there are a variety of exercises at the end of each chapter that range from basic multiple-choice regurgitation of the chapter content to some nice design exercises and thought-provoking questions. Also, this book introduces a fairly complete set of industry jargon, which is important to a student who wants to hold a conversation with a professional; however, the terminology is scattered throughout the book and has no unifying quick-reference table or glossary as a reminder.

Students: If you're looking for a basic, high-level overview of game design or production with a little understanding of what those strange artists and programmers are doing (without having to actually learn art or programming), this book will give you a reasonable starting place. As you read, make sure to not take anything as gospel; this book has equal parts good and questionable advice. I'd recommend reading this only as a supplement to other texts, either to fill in some blanks or as a second opinion.

Instructors: Use of this book in the classroom has similar problems to Rabin's book: by covering all disciplines of game development it can't really fit in any of them. Added to the other problems above, I can't see this being useful as a textbook for any course. However, I would definitely recommend picking up an evaluation copy for yourself and taking a look at the end-of-chapter exercises for the chapters that apply to your classes; you may find a few good questions and activities for class discussions, exams and homeworks.

Professionals: As this book explains the game industry to the uninitiated, you are really not the target audience. If you're a programmer or artist who wants to know more about production or game design you might give those sections a read, but you're probably better off finding other books that go more in depth into those respective fields.

Textbook Review: High Score!

This is part of the series on book reviews.
"High Score! the illustrated history of electronic games (2nd Edition)" (Rusel Demaria & Johnny Wilson)

I've used this book in my Game Industry Survey class, but it's not a textbook. It even says on the cover that it's a coffee table book for game geeks, and that's exactly what it is: a trip down the memory lane of the game industry, in full color, featuring much box art, screenshots and developer photos. The authors give a very candid look at the industry, talking not just about the games but also the developers: what it was like to work at Atari in the early days, for example. The writing style is conversational, not academic, making it an easy read (not to mention that the subject material will be interesting to most student game developers).

This book has two glaring weaknesses, and neither is the fault of the authors. The first is that it was published in 2004; the current generation of consoles did not exist yet, nor did World of Warcraft, so there is a period where the information just stops. Second, the book is unfortunately out of print, which makes it impossible to use as a required text. (Luckily, it can still be found used on Amazon and the like, as of the time of this posting.)

Students: If you're a game geek, you'll probably enjoy reading this book anyway. The fact that you'll actually get a great sense of the history of the industry (which will help you appear serious when you start applying for jobs) is purely accidental.

Instructors: If you teach a course about the history of the game industry, this is a great supplement. Being out of print means it's not required, but you might at least pick up a copy for yourself to supplement your lecture material, and suggest that interested students find their own copy for out-of-class pleasure reading.

Professionals: This is more of a game geek book, so it won't exactly help you make better games. You might like to pick it up for fun, or not, depending on your personal taste in books.

The Field Widens

I recently found that there are now two other blogs about teaching game design:

Boardgame designer and professor Lou Pulsipher has a new blog at http://teachgamedesign.blogspot.com/,

and game programmer Mark Doughty apparently created a blog at http://teachinggamedesign.blogspot.com/ (although this one is currently inactive).

I'd like to welcome these new players to the field. (I say "new" somewhat tongue-in-cheek, as Lou at least has been teaching far longer than I have.) I originally started this blog because there were no other resources for teaching game design on the Web; it looks like pretty soon there will be!

Textbook Review: Introduction to Game Development

This is part of the series on book reviews.

"Introduction to Game Development" (Steve Rabin)

This ginormous book is a fairly comprehensive look at all aspects of game development: art, design, programming, production, audio, business and even a little bit on academic game studies. (As with the rest of the industry, QA is largely ignored.) It's actually a collection of essays and articles written by a wide variety of experienced game developers; Rabin is the editor, not the author. The list of topics was developed according to the IGDA Curriculum Framework and there are exercises at the end of each section; newer editions include a CD-ROM with pre-fabricated Powerpoint presentations ready to use in the classroom... if you're the kind of teacher who likes to read bullet points off of slides. Anyway, this was very clearly meant to be a textbook, possibly the textbook (as in, One Textbook to rule them all, or perhaps the Ultimate Textbook Of Ultimate Destiny).

As might be expected, Programming and Art get the most attention; those disciplines are more quantifiable, have more direct and better understood application outside of game development, and they are the most common entry-level positions (other than QA). As a result, most academic programs already focus on either Programming or Art, so a grand-unified-theory textbook such as this would want to put its attention on the same areas that schools do.

The book's size and scope is in some ways a disadvantage. No single course can cover the entire text, and its sheer bulk is inherently intimidating. It is expensive, and its generality means that any given course probably has other textbooks with a tighter focus that are more relevant.

On the other hand, if several instructors collaborate and agree to use the book in all of their respective courses, this one text could serve as a constant companion to students across an entire curriculum. While Introduction is inherently weak in some areas (notably game design), it gives a solid list of references to other works; any question that a student may have about any aspect of game development is probably either answered in this book, or in one of its direct citations.

Students: Personally, I think every student should own this book as a reference guide, the same way everyone used to own a dictionary and thesaurus before the Web made those obsolete. That said, I went so far as to make this textbook required (and even assigned some readings from it) in several of my courses last year, and for the most part my students ignored it -- whether from the intimidation factor or the expense, I don't know.

Instructors: If you require this book, be prepared to go all the way with it: make sure there are enough assigned readings and problem sets that supplement your existing course that it's worth the trouble. Ideally, work with other professors so that the book is used across several classes. That said, for game design in particular, I think there are better books out there; this is best used in a more general program, or especially an art- or programming-focused curriculum that has a Game Design course on the side.

Professionals: Even at the professional level, this is still a decent reference text. It would come in most handy if you're asked to do something outside of your specialty (a graphics programmer being asked to do some AI, for example) or if you just want a better understanding of what your co-workers do all day. It's probably best to just ask your manager to get a shared copy for the office, rather than having to own your own personal book.

Textbook Review: Fundamentals of Game Design

This is part of the series on book reviews.

"Fundamentals of Game Design" (Ernest Adams, Andrew Rollings)

This book covers the core concepts of the field of game design, and for good measure adds an in-depth look at a large number of currently-popular genres and the design elements specific to each.

I love the structure of Fundamentals; the topics flow nicely into one another, and the exercises at the end of each chapter make it easy to design lessons around. The coverage of game genres may be unique to this book; on the other hand, as new styles of gameplay are invented and others lose favor, this book will eventually date itself.

As for the content itself, the majority is (more or less) the sole opinions of the authors, and as such should be taken as a set of theories – not scientific laws. Like a programming code or religious text, this book is meant to be interpreted and discussed, not blindly followed.

Students: This book is absolutely worth reading once you’ve already studied the basics of game design and want to get into specifics. Do not read this as your first book; you’ll be tempted to assume that everything in here must be taken as gospel, and it has the danger of tainting your own artistic vision for years until you un-learn it. But as your study advances, you can properly see this as one approach of many, and the content will give you a valuable perspective.

Instructors: The worst way to use this book is to lecture directly from the text in an introductory course. I have great respect for the authors, but our industry does not need a new generation of Adams and Rollings clones; it needs creative people who can think for themselves. My preferred use of this book would be in an advanced, conceptual class where students already have a foundation in conceptual and practical game design; class time would consist not of lecture, but of moderated discussion. Everything in the book is subject to heated debate (even from the beginning with the definition of what a “game” is) and the debates in an advanced class would be wonderful.

Professionals: Experienced game developers will probably get little out of this book. If you have always been highly specialized and want to learn more about other areas of design then this book can help you, but that’s about it.

Rant: The Need for Accreditation in Game Design Programs

I just saw a job posting on the HR website of a university that I will not name here, for a "Digital Game Design Faculty".


Requirements for the position:

• Bachelor’s degree in education with experience in graphic design and animation.


• Proficient with Maya, Swift3D, Adobe After Effects, Adobe Flash, Photoshop, Illustrator, InDesign, Final Cut Pro, Motion, and DVD Studio Pro.

No. No, no, no. A thousand times no. When I say that a game designer is an artist, I say this metaphorically, not literally. Game design is its own field.


The really sad thing is, these people probably have no idea what they're doing, nor will the person that they hire. And this will ultimately be a black mark on all education, not just this particular school, as the industry sees just how many schools mis-name their academic programs... and if the name isn't even right, what would you assume about the quality of instruction?


The only way I see out of this is industry accreditation, probably through the IGDA. Because universities can only be honest with students if they know enough about the subject material to proceed honestly in the first place.

Textbook Review: Game Design, Theory & Practice

This is part of the series on book reviews.

"Game Design, Theory & Practice (2nd Ed.)" (Richard Rouse III)

This relatively well-known book was an early stab at a book about game design for non-designers (by “early” I mean that it’s more than five years old, thus predating many of today’s college curricula and the majority of other textbooks I've reviewed). It includes an eclectic mix of game analysis, best practices, and interviews with influential designers.

Most of the content is at a pretty basic level, making it an easy read. Of course, this also limits its usefulness to more experienced designers. Each chapter is mostly self-contained; this also makes it easy to read (one chapter at a time, and if you put it down for a few months you don't have to repeat old sections that you'd forgotten) but also makes the book feel a bit disjointed.

Students: This book is a great place to start for self-study if you know you want to design games but you don't know where to begin. It will help you understand the field, by showing you how some designers approach their craft, and you will come away with a variety of new perspectives on how to make games.

Instructors: It’s probably my own inexperience as a teacher, but I haven’t figured out how to include this book in a class (much as I’d like to). The topics don’t flow well, every chapter seems disconnected from the others, and there are no exercises or questions at the end of any chapter, so using this book would require a lot of extra prep work on the part of the instructor. This is perhaps not so surprising; it was never written for the express purpose of being used as a classroom text, after all.

Professionals: If you’ve already got a couple of shipped titles under your belt, most of the practical advice in this book will be nothing new to you. You may still find it entertaining, but it will probably not be of great help in honing your craft.

Textbook Review: The Game Design Reader

This is part of the series on book reviews.

"The Game Design Reader" (Katie Salen and Eric Zimmerman)

This companion to Rules of Play is simply a collection of important essays and other written works about games. It includes pretty much everything that I'd call "foundational" to the field: Costikyan's I Have No Words, Church's Formal Abstract Design Tools, Bartle's Player Types, and so on.

Unfortunately, it tries to be a little of everything; there's some New Games Journalism, some pieces on players and gamer culture, and other things that don't really have to do with designing a game. And most of the articles are freely available online anyway, making me wonder why I should force my students to pay some exorbitant amount of money for a textbook.

This is not to say that the articles (design-focused and otherwise) aren't useful. They are still important works in their own right, many people in the industry have read them already, and any serious student should read everything in this book. It's just that no matter what the subject of the course, the majority of the works in this book won't be relevant. I suppose you could build a course around the book, "Important Readings in the Game Industry," but I'm not at liberty to do that right now. An alternative is to require this book for several courses in game design and game studies, with each course covering different readings… but that requires a bit of coordination between professors to ensure minimal duplication, and pity the poor students who take half the courses only to have to purchase the same book again if it ever goes to a Second Edition.

Students: If you’re serious about games, you should have at least a passing familiarity with everything in this book. Buy it on your own and read it over a summer when you’ve got nothing else to do. Or, if you’re on a tight budget (and what student isn’t?), find the book in your local bookstore, copy down the table of contents, and track down all of the articles online. For those few readings that can’t be found online, you should be able to check out the appropriate works from a library, or just read them in the bookstore.

Instructors: I’ve gotten by with just assigning relevant online readings, without forcing students to buy this book. I do suggest to my students to track down additional relevant readings from the book on their own time.

Professionals: At the very least, take a look at the table of contents and see how much of it you recognize. If you haven’t seen anything mentioned, you’ve got some wonderful reading experiences ahead of you. More likely, you’ll recognize some important works that you’ve encountered before, and the rest won’t be relevant to you. Take a look and decide for yourself.

Textbook Review: From Blue Sky To Green Light

This is part of the series on book reviews.

"Game Design: From Blue Sky to Green Light" (Deborah Todd)

This relatively short book covers everything that happens in preproduction; it gives a reasonable treatment to game design documents and the iterative process, and it even has a section on pitching a game to a publisher. It also covers the creative aspects of game design that I myself am weakest at: storytelling, character design and level design.

Overall, the book delivers what it promises, and not much else. You won’t find a lick of material on technical game design, content development during the actual creation of a game, or anything like that.

The only real weakness of the book is that it’s extremely current and uses a lot of very recent examples (as of the time of publication). This means it is likely to obsolete itself in a fairly short time, as the games within become dated and the business of the industry (hopefully) moves beyond the developer/publisher royalty-with-advance model. Although perhaps that’s intentional, if the author hopes and expects to make new editions every few years.

Students: Odds are, the first project you work on will already be in full production by the time you’re hired. Preproduction work, concepting and pitching are usually reserved for experienced design leads (not always, but usually), so this will not be immediately applicable to your first job. That gives you time to read it after you break in to the industry, if you're the procrastinating type. But if you’re curious what the early stages of a game project are like, you’ll get a pretty good overview by reading this book. It’s also not terribly big or intimidating, so reading it while still a student might not seem like such a daunting task.

Instructors: This book is rather specific to the earliest phases of game development, making its use limited in most classes. If you’re teaching a practical game design course where the deliverables include a one-page game concept, a slightly larger game proposal, a game design document and a verbal pitch to a “publisher” (i.e. the instructor), this book will cover you. If the only practical development course you teach involves all of that in the first three weeks and then it’s straight into prototyping, you might not have enough time to make the book worthwhile as a required text.

Professionals: Designers in the industry are still very guild/apprentice-like. If you do indeed start your first design job in the middle of a project, you’ll probably experience a few preproduction cycles vicariously through your leads before you’re forced to do it yourself. Depending on how you look at it, that either makes this book redundant with your experience, or it will reinforce it. In any case, it’s probably worth a read just to see what others have to say on the subject. And if you happen to find yourself in a small studio where you’re thrown into the role of Lead Designer on your first job fresh out of college… then you should read this just so you have some experience backing you up (even if it’s not your own).

Naches / Kvell

I just received news that one of my students (well, ex-student now, I suppose) just got his first game industry job as a designer. That makes two success stories total. Given how difficult it is to find an entry-level game design job, this makes me feel fulfilled in exactly the way I was hoping to be when I first became a teacher.


Interestingly, the two students who are now working as game designers were also the only two students of mine who attended GDC this year. I don't believe this is a coincidence at all. I tell all of my students that GDC is pretty much a mandatory step for anyone who wants to "break in", and now I have stronger evidence than just my own say-so.

Much as I'd love to take total credit for being such a great teacher, my students this year were pretty amazing. All I did was point them in the right direction, but they did all the legwork to reach their destinations.

For those unfamiliar with the terms Naches and Kvell, a description can be found here, on page 6 (the rest of the document is well worth reading too, especially if you're a game design student).

Textbook Review: Rules of Play

This is part of the series on book reviews.

"Rules of Play" (Katie Salen & Eric Zimmerman)

I’m really glad this book was written. It was the first book ever written about game design that actually looks like a textbook. It’s big, it’s heavy, it has lots of small-print writing with exercises at the end of each chapter and a bunch of appendices at the end. Its very existence gives the entire field some modicum of academic merit.

The content does not deal so much with how to design games per se, but instead gives many different ways to critically analyze games. For example, if you consider a game as a system of rules, you are going to see it differently than if you look at that same game as a narrative, or as a sociocultural activity, or… well, you get the idea. It is therefore useful to game designers only in the most abstract sense of gaining a deeper understanding of what these things called “games” are, these things that we work with every day.

As a bonus at the end of each of the four sections, there are the rules for a game you can play (I found most of them to be quite good). In addition to the game itself, we can also see the designer’s notes about how the game started out, what kinds of things were found in playtesting and how (and why) the designer addressed the game’s shortcomings. This insight into the brain of a designer-in-motion is most interesting, and practically worth the (hefty) price tag of the book on its own. There’s also an essay by Reiner Knizia, which also makes for great reading, even if it doesn’t necessarily fit the theme of the rest of the book.

Unfortunately, this book has a few weaknesses in its presentation. The writing is a bit on the long side. As a game designer, I found that if I just read the bullet-point summary at the end of each chapter, I usually got all of the information I needed; actually reading the chapter itself was a waste of time. (Yes, I read every chapter first, just to make sure.) I’m not sure if this is just from my experience; if there are any students in the audience who can say whether this was true for them as well, please post in the comments.

Also, the authors have this unfortunate tendency to create their own vocabulary. Their new terminology mingles liberally with established industry jargon, but with no mention of which is which. I can’t fault the authors for this (what else could they do?) but it does make it more difficult to use this as a textbook: my students who go to GDC should know what an Avatar is, but if they start talking about “schemas” and “constitutive rules” and “transformative social play” they’re just going to embarrass themselves.

Students: I doubt any student would choose to read this on their own. Most of you don’t enjoy reading to begin with, and a book this abstract would probably bore you to tears. You may be forced to read it as part of a game design class (and if so, you have my sympathy) but otherwise, you’re safe avoiding it for the time being if you want to be a game designer. If you’re more interested in game critique or game studies, you’ll probably find this quite useful and fascinating. I could never figure out game studies people.

Instructors: This book would be perfect for a “Critical Game Analysis” class that acts as a dual requirement for Game Studies and Game Development students. I’d expect it to be an upper-level class, simply because of the highly academic writing in the text. For any course focused entirely on game design, there are better texts; as noted above, this book does nothing to explain how to actually design games.

If you do use this book for a class, be sure to differentiate between the terminology used that already exists, versus that which was created by the authors. Your students should be able to speak clearly about games to people who haven’t already read Rules of Play.

Professionals: This book took me about half a year to read through from cover to cover (in my spare time, granted). You can get all the same benefits in a fraction of the time by just skipping to the end of each chapter and reading the summary, then going back and looking up anything that doesn’t make immediate “well, duh” sense to you. Also read the Knizia essay and commissioned games, of course. Do that and you’ll finish reading it in a few days.

Textbook Review: Game Design Workshop

This is part of the series on book reviews.

"Game Design Workshop: Designing, Prototyping & Playtesting Games" (Tracy Fullerton, Chris Swain, Steven Hoffman)

This book covers the core concepts and best practices of game design. It is organized into three parts. The first part gives a formal description of all of the different aspects of games, to build a framework for discussing how to design them. The second part talks about the iterative process as it applies to game design (in particular, how to prototype, focus test and playtest, and respond to feedback); in fact, this is the only game design book I've seen so far that does so. The last part gives an overview of the game industry and the job roles and responsibilities of the game designer.

The first part of the book gives a reasonable breakdown of games into their component parts. The second part gives great practical advice on the process of game development from a designer's point of view. The third part is easily the weakest link; it starts out worthless (everyone reading a book like this already knows what a game designer is, why else would they read it?) and proceeds into the realm of actively damaging (giving the waterfall model of production, and a design document template as examples of best practices). It is best for everyone with this book to just pretend the third section doesn't exist; thankfully, the rest of the book is worth the price of admission.

Sprinkled throughout the book are numerous interviews with famous designers, offering many (often conflicting) perspectives on the field; these make great discussion fodder for classes, and also provide some insight into what aspects of game design are universal (where many designers agree) versus those that are a matter of personal style (where designers give opposing answers to the same questions). They don't seem to have much relation to the section of the book they appear in, they're just diversionary sidebars... but they make interesting reading nonetheless.

Students: You can read this book on your own, but you'll probably get the most out of it if you take a class that uses it as a textbook. If no such class exists, reading the first two parts is still a worthwhile use of your time -- certainly better than nothing.

Instructors: The book contains many exercises, some highly conceptual and some quite practical, making it very easy to use as the basis for an intro course in game design. This is, in fact, the book I used myself for just such a class, and I was quite happy with it. I found that, while it does involve a lot of reading, the reading goes quickly; the students taking a game design class are already motivated, and this book contains the material that they want to know. I encouraged students to read those parts of the book that we didn't get to during the course, on their own time... except for the third part of the book, which I advised them to rip out of the book on the first day of class.

Professionals: The first part is worth a read if you're a practicing game designer; many of the concepts will probably not be news to you, but it might give you a few new conceptual ways to think about the design of games in the abstract. The second part is worth reading for both game designers and producers, especially if you're not working at Maxis or Firaxis or some other place that already embraces iterative design; it gives great practical advice for doing so. The third part is even more worthless than it would be for a student; you're already a practicing game designer, so the last thing you need to be taught is "what it's like in the game industry".