Teaching Game Design: The Problems

Game design is often taught by people who have no game design expertise, usually programmers who really want to be teaching programming but are using games to entice people into learning programming.  This is a problem.  I believe there’s also a basic contempt, amongst many non-gamers and especially many programmers, for the entire idea of game design, as in “oh, that’s kid’s stuff, anyone can do that” or “it’s just getting a few ideas” (which conveniently masks their lack of knowledge and experience, of course).  

Nothing can be done about the contemptuous people who are supposed to be teaching game design, but for those with a more open mind, I’ve tried to distill my experience as a game designer who is also a very experienced teacher (17,000 classroom hours).

First you have to decide, are you going to talk about game design and discuss it so that students have some idea what it really about but no clue how to actually do it, or are you going to have them begin to learn how to do it?  You can’t do both in one semester; it’s very hard to do both in two semesters.  Moreover, you can’t try to teach them game production in the same classes.  If you do, they’ll struggle with the game production and learn very little about game design.

There’s a big problem in conveying the difficulty of game design to students unless they experience it first hand (“experientially”).  I’ll try to use an analogy to explain. 

Most college and high school age people know intellectually that they can die, but emotionally they feel that they’re immortal, and sometimes behave that way as they take foolish risks such as driving while intoxicated. 

Similarly, they can be told that the ideas in their heads will not translate directly and accurately to what happens in a game (and even if they do, they often won’t be enjoyable to play); they may acknowledge this intellectually, but emotionally they don’t believe it. Instead they think that the game is going to work just as they conceive it and will be great fun (and further, that there will be more detail in it than they actually have in mind). 

There is no substitute for them making games and (inevitably) seeing that the game not only does not work as they anticipated, it usually does not work well at all.  To do that with beginning students you must use non-video (tabletop) games.  If they try to learn how to create video games at the same time as they learn design, the struggle to create will be so great that they learn virtually nothing about design.  This will happen even with tools such as Gamemaker that avoid programming per se.  And even if they one of the few who might succeed, it takes so much longer to create and repeatedly modify a video game (as opposed to a tabletop game) that they won’t have time even in two semesters to really understand how much happens after the playable prototype is created.  Nor will they have the opportunity to understand that the most important part of game design happens after the initial prototype creation. 

In other words, to understand game design students must “complete” games, not merely plan them or get to an (inevitably poor) working prototype.

Given that students today are impatient with theory and want to do "something practical", they’re likely to be more engaged if they start by designing games.  As you then introduce the “theory” they’ll be able to associate some of it with their practice so far, which will help both understanding and retention.

Another analogy: just as it is usually necessary for someone learning to write novels to write and discard a million words as practice, it is usually necessary for someone learning to design games to design many games that are not publishable but are good practice.

You'll have plenty of chances to teach design skills from the practical experience.  Don't end up like American basketball players:  "It's like what ESPN analyst ... Jay Bilas says all the time: In Europe, they teach skills, in America they play games. Teenagers aren't coached here so much as they're babysat and herded from tournament to tournament."  (Rick Bonnell)  But "playing" without teaching at least produces good basketball players. Experience without insight is of limited use, insight without experience is almost entirely useless for actual game designers.  You need to be the coach, but they need to make the games.

If the instructor has not actually designed games from start to finish, not just to the point of a playable prototype, then the instructor probably won’t understand what’s really happening either.  Most people don't complete games.  Instead they think that when the playable prototype stage has been reached, the job is about done, when in fact it's closer to the beginning than to the end.

I understand the notion, once posed to me by the head of the neurosurgery department at UCLA, that "I can teach anything I can understand".  The question is, can you understand game design without actually having done it?  Not well.  Teachers don't need to be professional practitioners, but they must be practitioners.

Yes, someone who has not painted could teach a class about painting, but the result is not likely to be good.  Someone who has never sculpted can teach a class about sculpture but the result is not likely to be good.  Someone who has not composed music can teach a composition class, but the result is not likely to be good even if they’ve played lots of music.  (That is, playing a lot of games doesn’t make one a game design teacher any more than it makes one a game designer.)  Games are more complex and less personal than paintings or sculptures or musical compositions, games are interactive and involve people other than the designer, games are more cerebral than these other arts and typically take much longer to complete.  So the teachers who are not professional practitioners but are teaching the classes are much less likely to have gone through the entire process. Someone who has not actually designed games from start to finish can teach a class about game design, but the result is quite unlikely to be good.

A poor teacher who is a practitioner may not get results as good as a good teacher who is not a practitioner; but a good teacher who is a practitioner will get much better results than a good teacher who is not.

Example:  several years ago one of the local community colleges used their Game Design I class mostly to teach students how to use Gamemaker, that is, they were really teaching game production.  Then they used Game Design II to divide students into randomly-determined groups and have them make five Gamemaker games in 16 weeks.  (Once again, game production was the main objective.)  So a game barely reached playable prototype stage, with barely any design involved, it was mostly a production struggle, with the Gamemaker "programmer" having by far the most influence.   Students got absolutely the wrong ideas about game design, as well as great frustration with the concept of working in groups in such limited time-frames.


When I say design and complete games, I don’t mean write game design documents.  There are too many curriculums that teach students how to write game design documents but don’t let them learn how to design games, so what goes into the GDD is likely to be garbage.  A game design document is just a plan, and when people who have no experience of actually doing something try to plan to do it, it can be a train wreck.

I have just read yet another syllabus for an introductory game design course where the students are not actually learning how to design games.  Instead they're learning how to write brief pitch documents describing a plan for a game.  (The documents are much too short to actually be a plan; they're a description of the most notable parts of the game for marketing purposes.) This may sound like designing games to you, if you never designed a game, but to me the students are only being asked to express an extended idea.  And if you have not yet learned how worthless ideas are in game design then there are many articles you can read, such as "The Idea is Not the Game", http://www.gamecareerguide.com/features/614/the_idea_is_not_the_.php and "Why Your Game Idea Sucks"
http://www.escapistmagazine.com/articles/view/issues/issue_221/6582-Why-Your-Game-Idea-Sucks .

Furthermore, when beginners write extended descriptions of their ideas for video games they tend to focus more on what they wish the game to be rather than on how the game is going to work.  See "When You Start a Game Design Conceive a Game Not a Wish List" http://gamasutra.com/blogs/LewisPulsipher/20111014/8668/When_you_start_a_game_design_conceive_a_game_not_a_wish_list.php .

Writing these brief documents doesn't even teach students about game structure, let alone about the process of game design.  It teaches them nothing about the iterative and incremental process of taking an inevitably poor prototype and turning it into a good game.  The way to learn about the process of game design is to design and complete games.

Example of how this begins to work: the first day of an intro game design class–I don’t discuss the syllabus until the second day–I talk with students about Monopoly, try to get them to understand why it is a poor game even though they may have fond thoughts about it (because they were doing something enjoyable with their families), and (if there’s time) put them into groups to start devising ways to improve the game.  As soon as we can, I have them play their version to see how their ideas turn out in practice.  (Of course, usually the new versions are a mess.)  This gets the attention of the serious people, at least.  It may be disappointing for the students who think they're going to play video games all the time for class. . .

(And a related note:)

I was a peer reviewer once for a textbook for an introductory database class, with a strong leaning toward Oracle.  The book began with a lengthy discussion of normalization of databases, which is a process of making sure that you don't have more fields in a database than are necessary aimed at avoiding duplication of data.  The book then talked about entity relationships and other details of creating database applications.  Finally the book got to actually using a database to do something.  I told the authors that typical college students would quickly switch off at the beginning of the book because it would seem irrelevant to them.  I suggested having the students make and use databases first so that when the students got to the discussion of normalization and entity relationships they would have some experience to apply it to and could understand why it was important.  

This bears considerable resemblance to the situation in game design.  Beginning students have a lot more experience of games than of databases.  Nonetheless, if they have no experience of designing a game then the theory of game design will mean much less to them.  They'll associate it with fantasies that it all will happen very easily that I discussed at the beginning of this article.  They will still think that game design is all about getting good ideas, not about the execution of those ideas.

(Another related note:)

The intellectual/emotional split between the “theory” of game design and the practice is a little like the split that’s part of teaching beginning students to program: if you try to have them both solve the problems that are posed, and write programs to implement the solutions, they’ll fail at both.  You need to either present them with a solution and have them program it, or have them figure out a solution to a problem and then show them how an efficient program to this end works, without the students trying to figure it out.  When they’re more experienced then they can do both the problem-solving and the program creation.

Lew Pulsipher