10. Thou shalt not give tests in game development courses, nor be dogmatic in thy doctrine, for even thou knowest not all.

As far as I’m concerned, game development students should be developing games, not regurgitating facts or opinions from textbooks. They should be using their creative and analytical skills, not their memorization skills. I would be delighted if you adopted my book for your classes, but for God’s sake, don’t use the multiple-choice questions.

This raises a fundamental question about the nature of the work itself. Unfortunately, websites persist in categorizing news about video games under Technology rather than Entertainment. To them, “entertainment” means film, TV, and theater. But calling us “technology” makes about as much sense as calling filmmaking “photography.” We use technology in the same way that filmmaking uses photography, but there’s much more to it than that. Programming is a form of engineering, and in some forms of engineering tests are appropriate. But programming isn’t one of them. A programming course shouldn’t end with a test, it should end with a final project.

And if that’s true for programming, it’s at least as true for art, animation, music composition, and game design. Knowing the names of terms in game design is the least important thing about game design. We don’t have a common vocabulary yet, so insisting that yours in the one right one, and testing the students on it, is just arrogant. Don’t give tests at all. The one exception I can think of might be in some kind of history of interactivity course – but even then, an essay would be more appropriate than a test.

9. Thou shalt reward precision and punish hand-waving, for the Lord loveth it not.

In my game design workshops, I ask people to think of the actions that an avatar character will perform. What I’masking for are lower-level details: what specific action is assigned to each button on the controller? The “verbs” of the game. But again and again, I get responses like, “defeat the enemy,” “solve the puzzle,” “escape from the dungeon,” and so on – high level responses, and when I ask for the details, I get hand-waving.

It is imperative that your students understand that hand-waving will not do in a commercial environment. To get a product finished and out the door, they must be specific. In the industry, I’ve worked on several projects where the lead designer or the producer’s overall vision was so vague that it was impossible for the rest of the team to know exactly what they were supposed to be working on. This usually stems from a desire to make a game that can “do it all,” and a reluctance to commit to any one particular approach, genre, or style of game. Making that commitment means limiting the game, and the problem is, these guys are mesmerized by the boundless potential of the medium. If they were sculptors, they would sit all day, staring at the uncarved block of stone, spellbound by the infinity of beautiful sculptures that it potentially contains. But they’d never carve a thing.

I understand that fascination; I’ve felt it myself. But the fact is, making a sculpture requires commitment to a final result, to an actuality rather than a potentiality. And creating a game requires commitment to limits on the game, because almost every game is a simplification of something else. If you were the greatest real estate agent in the world, who knew everything there was to know about property, you might find it hard to pare down the details of the business to the simple essentials of Monopoly. But you have to do it.

Now, in the context of a university course, where time is limited, it is also possible for students to go too far in the opposite direction, and amass a huge pile of circumstantial detail – for example, the student who works out the exact performance characteristics of 27 different unit types when there’s really only time to implement 5 of them. Or who does far too much research. When they do this, it almost always happens at the expense of something else. He’s got the 27 unit types down, but he never got around to designing the user interface. So it’s possible to go too far in the other direction, and amass too much detail. But I think that’s not as big of a risk as hand-waving and lack of precision is.

Hand-waving is one of the classic faults of producers and other managers who don’t actually do the work. It requires someone else to figure out their vague plan and implement it – then that person takes the blame if it doesn’t work. It’s unfair to the developers and extremely detrimental to the project.

As instructors, I encourage you to reward precision and punish hand-waving.

8. Except ye teach a master’s level course in experimental interaction design, thou shalt not emphasize aesthetics or story at the expense of interaction, i.e. gameplay.

If your BA degree is aimed at teaching people to make commercial video games, then gameplay comes first, period.

In every genre of commercial game, players buy the game primarily to do things, not to look at the pictures or watch the story. Emphasizing aesthetics or story over gameplay is a distinct risk at institutions whose primary concentration is Art-with-a-capital A rather than technology or games specifically. The fuzzier your program is – in the sense of “fuzzy studies” – the more likely this is to happen. This doesn’t mean that you should tolerate disharmonious, incoherent artwork, or stupid stories. But they need to start with gameplay.

Now I admit there is useful research to be done on low-interaction media (for example, novelist Kate Pullinger’s work Inanimate Alice); on play spaces that do not offer gameplay (Second Life); on interactive artworks; on interactive narrative. But if that is where you start your students off, they’re going to miss the point, and you will be doing them a disservice. Those are master’s level topics.

Students often come in with an expectation that video game design is about telling linear stories. They describe their game progression as “first the avatar does this, then he does that” and give you a series of narrative plot points. They tend to wave their hands about the actual interactivity, the puzzles, the challenges, the actions. Students’ natural tendency to tell stories – which is easy and fun – has to be shunted into designing interactive experiences instead, which is not as easy and not as fun.

Teach them interaction design, gameplay design, first, and only then let them worry about storytelling.

7. Thou shalt teach not only game development, but also the history of games, the analysis of games, and the sociology of gaming.

Be sure your students understand the roots of the medium. First-year student projects nowadays often build 1980s arcade games that are actually as good as anything we built back then. Fortunately the students don’t have to do it in assembly language and 4K of ROM, but the principles of design are still the same. So they might as well know about those old games and learn from them. Of course they’ll all want to make massive role-playing and real-time strategy games, but that’s not realistic in the context of a 10 or 15-week course full of newbies, and the sooner they learn it, the better.

The medium is now sufficiently old that some students are younger than the games they are studying.

Analysis of games is an excellent way to observe the principles of game design in practice. It’s one thing to try to design them according to those principles, but being able to see why a hit was a hit is essential groundwork for the field. And, for that matter, why a failure was a failure. You don’t become a composer of orchestral music without first dissecting the works of Bach and Mozart and Beethoven to see how they work – or Salieri to see why he was no Mozart.

As for the sociology of gaming, that’s a question of understanding the relationship of the medium to its consumers. We don’t build games in a vacuum, nor do we built them to please wealthy patrons. We build them to sell to people, and so the question is, who are those people and how and why do they play?

You realize, of course, that I’m dangerously close to endorsing teaching them marketing, but if I call it sociology of gaming I can stomach it better.

6. With industry shalt thou build relationships; yet also shalt thou remember that “industry” explodeth in all directions, and meaneth more than PC and console games for the West.

Relationships with industry are key to getting your students placed in jobs after they graduate, and as you know, this is one standard by which your program will be measured. Developing these relationships pays dividends in various ways:

- First, it increases your program’s credibility both with the students, with their parents, and with industry itself.

- Second, if a company has an internship program, your students get work experience before they enter the job market.

- Third, you get a potential source of guest speakers to come and give talks. I know this sounds self-important of me to say it, but again and again, faculty have told me, “They don’t always believe me, but they’ll believe it when you say it.”

Even if the visiting speakers don’t know any more than you do, they bring a level of street cred that instructors find it hard to match. Bringing them in for the students will not only drive home your points (assuming that they agree with you), it will also make your students grateful to you.

Bite the bullet and pay them to come and teach. Yes, you shouldn’t have to – industry benefits from the academy and doesn’t give much back. But the truth is that many professional developers aren’t going to see any upside to going off to teach for a day – they’re extremely busy. But a lot of them would be happy to have another $500 now and then.

You have to pursue these relationships. Industry doesn’t have the time to come to you. You have to go to them.
Industry rarely contacts higher education institutions looking for potential employees – they know all they have to do is put an ad on their website to be flooded with applicants. So instead of expecting industry to pull, you need to push.

But don’t construe the industry narrowly as PC and console games for the West, and don’t let your students do that either. Always remind them that “games” now includes PC, console, MMOGs, handheld, mobile phone, location-based entertainment, serious games, arcade games, alternate reality games, persuasive gaming, web-based casual games, indie gaming, gambling machines, and on and on and on. Furthermore, there are markets set to explode in India and China, and the Middle East won’t be far behind. These people will need games tuned to their own cultures.

One last related point: I used to hear my teachers say that his and other universities shouldn’t be admitting too many graduate students, because the jobs aren’t there for them. I disagree.

Some people might just want a Ph.D. in anthropology for its own sake, and I don’t believe it’s fair to deny them the opportunity to get one on the basis of how you perceive the job market for them. This goes double for the game industry, which is very entrepreneurial. Nobody knows how many jobs there are in the game industry, because nobody knows how many indie developers there are. Furthermore, nobody has any idea how many jobs there will be in three or four years, when the students graduate.

In short, by all means reject those students who don’t have the talent or the ability to do the work, and don’t try to teach more than you can handle – naturally you don’t want either the quality of your program or the quality of its graduates to suffer. But don’t worry about the job market. That’s not your problem.

There’s a real possibility that there are now so many game programs that we are training more game developers than the conventional PC and console industry can absorb. But as I said, the industry isn’t just PC and console any more.

Admit as many students as you can reasonably handle with the resources that you have, but don’t limit their numbers artificially.

5. Thou shalt require teamwork. Thou shalt teach project management, and gently discourage over-ambitious projects.

From talking to industry people, teamwork experience seems to be the number one thing they want an academic game program to teach. And the number one reason why game projects fail is lack of management skills and failures of internal communication. It is imperative that you make students work together in teams and learn how to do it efficiently.

Let me talk about team sizes for a moment. Team sizes on first-year projects at the University of Skövde tend to be in the range of 8-10. Two or three programmers, two or three artists or animators, two or three designers, a writer, and a team leader. If someone has music composition skills, that person may often be shared among several teams – which in fact mimics the situation at real companies. Team sizes at the University of Ulster are similar. Be sure the teams are big enough to include some redundancy. You can’t allow teams to have just one programmer or just one artist; if one drops out, it tanks the whole project.

Teach your project managers or team leaders:

* To know the state of their project at all times.
* To know what each person on the team is doing at all times, and what they will do next.
* To be able to stand up in front of a group and explain it.
* You might even teach them to use Microsoft Project, although that’s usually overkill if you have teams of three or four.

These are skills that few people emphasize, except perhaps the military, where an officer is expected to be able to deliver a concise and accurate situation report at a moment’s notice. But they’re valuable.

Above all, emphasize the importance of finishing – the need to complete and ship. The most fantastic, amazing, wonderful, game is worthless if it can’t be shipped.

4. Thou shalt permit failure in thy students’ first-year projects, and encourage them to learn from it.

The fact is, on a first-year student game development project, especially a group project, the students have been thrown in at the deep end of the pool. They’re really not prepared for what it demands of them, and many projects will fail to complete their work. That’s all right. We learn far more from failure than from success. But you should also punish those who do not learn from their failure, and continue to fail.

Require each student to write a reflective report on the project, and to keep a project diary. They must attend the build meetings, and of course they must have actually contributed to the work. But the quality of the resulting game is not relevant. As you probably already know, you will get some students coming in who think a game degree is going to be all fun and games, what we used to call a Mickey Mouse course. One good way to weed them out is by not allowing any game development at all in the fall semester of freshman year. Stick to your history, analysis, and basic skills courses then; they’ll get annoyed they’re not diving straight into games, and leave.

3. In their final projects, thou shalt encourage thinking outside the box.

College is students’ best and perhaps only opportunity to do really strange things. Nobody in the industry is going to pay them to be weird. We’re too busy trying to meet the product plan to tolerate any weirdness, so let them be weird while they still can. This is an art form, not civil engineering. There are good and bad design principles, but almost any design rule can be broken under certain circumstances.

Juvenile satires aren’t true weirdness, however. You will undoubtedly have to put up with some of that. There’s a game development contest for students called Dare to be Digital, with teams coming from all over the world. A team from the University of Ulster wanted to make a game called Bathroom Buccaneers, about tiny pirate ships in a toilet bowl – along with the kinds of things one might encounter in a toilet bowl. I told them, “Look, do you actually want anyone to fund and build this game, or not? Because you’re not going to get very far with that idea. You might think it’s amusing, but nobody will ever turn it into a real product.” I told them to move it to the bathtub, which offers more opportunities for gameplay anyway. They did, and they ended up representing Ireland in the finals. If you want to be taken seriously, you also have to take yourself seriously – at least to some degree.

Their final project is also the most important part of their portfolio. You need to offer them some freedom here, and to encourage them to express themselves to the best of their ability. They will naturally want to do things that will be most impressive to the conventional game industry, and sometimes that will mean being conservative – it won’t do to force them to be radical if they don’t want to be. But emphasize that they need to stand out from the rest of the crowd. A hiring manager is going to be looking at a stack of DVDs and they need theirs to rise above the others.

2. Thou shalt require thy pupils to study other arts and sciences besides the craft of game development, for the ignorant developer createth only the derivative game.

There’s an issue about this commandment – in some cases it will be unnecessary, and in others it will be impossible.

At American institutions that offer a bachelor’s degree, this commandment may not be necessary, because an American BA includes distribution requirements for a degree of breadth – that is the nature of the American, four-year system. So you Americans don’t necessarily need this advice. However, I don’t apologize for making it. Don’t take up your students’ time with so much game stuff that they don’t have the chance to study other things.
As you design your curriculum, don’t concentrate too much on technology and practice. Make some of art, literature, music, history, economics, anthropology, psychology, sociology, and classical physics part of the requirements. You might even consider things like military history for strategy designers; ballet, or gymnastics for animators; political science for those interested in Civilization-type games.

On the other hand, European institutions may not be able to provide these things. The European undergraduate model assumes that the students already got an adequate high school education, so students expect to study only one subject for their bachelor’s. They don’t have the distribution requirements that American schools do.

As a result, many European universities are not actually universal at all. Because they are centrally funded by the state, they often concentrate on a few subjects to avoid duplication. For example, the University of Ulster Magee is particularly strong in computer science and integrated systems, and nursing! Still, do the best you can with what you’ve got.

In addition to basic game development courses, some universities require the following: dramaturgy, human-computer interaction, cognitive science, game analysis, hypermedia, digital culture, online cultures, and the history of games.

1. Thou shalt integrate all the disciplines of game development unto the utmost of thy institution’s capacity.

One of the most extraordinary things about this medium is the number of fields that it draws together – even more than the movies. It uses fields that seldom talk to each other in the context of higher education. How often do the people in the English department talk to the people in the music department? At least they’re both in the College of Arts and Sciences. Computer science is often stuck off in the College of Engineering. Art is in the art school, while animation is probably in the film school – if there is one.

One of the hardest things about setting up a game development education program is getting all these people together, especially if there is an entrenched bureaucracy and an old guard of tenured greybeards who see video games as a frivolous waste of time. It’s particularly difficult at the grass roots level, at large institutions, and at old institutions. It’s easier at smaller and newer institutions that don’t have so many traditions already in place. It’s easiest still if it has a powerful champion of some kind – an important leader who has the support of the university administration and the resources to make it happen. But, champion or no, you’ve got to do it, or your game program will be lopsided and poor value for your students.

Skövde has a peculiar situation in that the school is named “Humanities and Informatics” – Informatics being a catch-all European term for “computer stuff.” The fact that they came together is an accident of history and bureaucracy, but it turns out to be very fortuitous for their game development program that it includes humanities in the same school.

I strongly believe you should make the students all learn each other’s tools – not necessarily the high-end tools, but the basic ones. Make everybody learn to use a simple audio waveform editor. Make everybody learn to use a paint program like Photoshop if you can afford it or GIMP if you can’t. Make everybody learn to use a 3D modeling tool like 3DS Max if you can afford it or Blender if you can’t. Make everybody learn a little programming – not C++, but Python or Lua or maybe Java. Yes, even the artists!

Don’t fail them if they suck – they’re going to suck. That’s part of the point. The idea is to get them to understand what their other colleagues do. They have to realize that they have complementary talents and they need each other. That’s critical for communication on team projects later on. Don’t fail them for not being talented at everything; fail them if they refuse to try.

I realize that some of these may be difficult to achieve. Audio engineering is not a traditional university subject. But look for workarounds. For example, DeVry University’s program is heavy on programming but light on art. At the Phoenix, Arizona campus of DeVry, they cooperate with the Art Institute of Phoenix so that people with art skills can come and work on their game development projects.

Finally, as this is a programming-related discipline, I have in true programmer-fashion, incorporated a zeroth commandment:

0. Thou shalt NOT take an existing computer science, art, animation, media studies, English, or other program, add a game course or two to it, and call it a game program, for that is an abomination unto the Lord.

I cannot emphasize this enough. We’re all familiar with fly-by-night outfits that make unrealistic promises to students because they’re offering a half-baked program. If you do this, you are doing a terrible disservice to them. You’re cheating them. I realize that I may have insulted some of you just now, but if you have reason to feel insulted, then you probably deserve it. Build your curriculum properly, from the ground up. The latest edition of the IGDA’s Curriculum Framework Document just came out, so there are plenty of resources to help you design a solid program.