Report from Game Education Summit

I'm just catching up from the excellent Game Education Summit earlier this week. Here are my notes:

Donald Marinelli, keynote:

• Much of today's educational system is obsolete. Summer vacation exists to let young people go home and help their families with farm chores. How many K-12 students do you know that are planting wheat right now?
• If you are building a game for a class, build it for someone. Give it a purpose.
• ETC's "secret sauce" is that they let students teach each other.

Terrence Masson, on building Northeastern University's curriculum:

• Interesting way to structure a Capstone course with 10 people: first day people give their project pitches (most students pitch several alternative projects). Second day, students narrow the pitch list down to the two projects that the class will work on; students choose their teams (split into two teams of 5); each team assigns roles and chooses their project lead. Essentially, the students drive everything.
• Another interesting thing about this program is the requirement of two non-adjacent semesters in internships/co-ops. The benefit is that students keep the faculty honest: "What do you mean we don't have Zbrush on campus? That's what everyone is using now!"
• Note to prospective students: at this particular institution, the program is called "game design" but it is actually "game development". This points to the importance of schools and industry using a unified set of terminology.

Jessica Hammer, on how to teach creativity:

• First, you have to define what "creativity" is, because it is an overloaded term, and there are different kinds of creativity. She defined it as "appropriate novelty" -- something that is new, but within a given context/domain. (If you ask students to design a game and they write an essay instead, and try to define an essay as an innovative new type of linear-narrative game, this is not what we are looking for.)
• Creativity happens within a context or domain (i.e. within a set of constraints). There is a virtuous cycle within a field, where the domain influences individuals; the individuals produce creative work within the domain; and the gatekeepers who see this work then influence and redefine the boundaries of the domain to compensate. In the case of teachers, the classroom is the domain.
• One problem in practice is that we often measure creativity after the fact: we look at the final product and decide if it is creative. Unfortunately, this tells us nothing about the process used to create it... and if we want to teach creativity, we want to teach the process!
  There are three aspects to the creative process that students need to understand: the generation of novel ideas, the ability to decide what ideas to pursue (since ideas are a dime a dozen, once you learn how to generate them), and the motivation to follow through on your chosen idea and do the work to turn it into a final product. The class should focus on these.

Jessica's hints for course design:

• Begin with outcomes. "The goal of a course is not to deliver content, but to transform your students."
• Consider the length and pacing of the class. If there is not enough time to generate ideas, fail many times, and still finish, students will take fewer creative risks.
• "Personal attention is valuable currency." Keep class sizes small when possible. Group work can enable larger class sizes by having you deal with a small number of groups rather than a large number of individuals.
• Recruitment is rarely thought about, but is important. The more diverse your class (or, um, game studio), the more creative the ideas you're likely to see. When approached by a female and/or minority student, be supportive and ask if they have friends who would also be interested in taking your class. Also, consider the accessibility of your classes: if students can choose between written or verbal assignments, you will see higher enrollment among those for whom English is a second language.
• Use a lot of class time on playtesting and peer review. Professor should model appropriate feedback, to show what it looks like.
• Encourage uncertainty, in projects, classes and life. "Your game design education does not end when you leave this class. It has just started."
• Don't just have students solve problems that are handed to them, because this is not how real life works. Have them create and seek out their own problems to solve.
• There is a negative relationship between the time and emotional investment in a project, and willingness to take risks. In the middle of larger projects, consider giving smaller-scale "lightning round" design challenges that encourage creative risk-taking -- for example, email students with constraints of a challenge at noon one day, and they have 24 hours to post a short concept in an online discussion group. These are not a major component of the course grade; they are a chance for students to show off. Examples: "Design a game to be played in the waiting room of an ICU while you're waiting to see if a loved one lives or dies." / "Design a game for NASA that can keep astronauts alert and interested on a 3-year mission to Mars." / "Design a game for Obama's cabinet to help improve their effectiveness as a team."
• How do you assess creativity? Note that you get what you measure; students will game any system. If you want to reward risk, you have to give grading opportunities for it. Jessica splits the final project grade into three equal parts: the game itself (the final result of the process), the theory (students write a companion paper that shows the connections between the theory learned in class and its expression in their game), and the process (students submit a "process paper" that includes everything that was part of the project but not visible in the final form: raw data, early playtest results, early versions of the game, mechanics that were tried and abandoned... whatever the student wants the instructor to see).
• Divide larger projects into many feedback cycles / milestones. Iteration is part of the creative process, and class projects should reflect that.
• The nature of instructor feedback is important. If you just give a grade, that carries very little information. Extensive written feedback is much better, but can take a lot of time; to manage this, favor group projects or smaller numbers of submitted projects per-person.
• As the instructor, you are a strong influence on the culture of the classroom. You want students to feel comfortable taking risks, both in their projects and by raising their hand to make suggestions/comments in class. How you react when students say something "stupid" has a huge impact. Suggestion: draw from the "Yes, and..." technique of improvisational theater -- accept everything in class, refuse to shut down an idea or say that it's wrong, and instead challenge yourself to find the nugget of truth in there.
• Give students a sense of mission. People are more creative under stress when they believe in the importance of the final project. Because of this, fewer projects (reduction of workload) can paradoxically lead to students spending more time and doing more work... as long as the projects they have are the right ones.
• Self-efficacy is important: students must believe they can perform well in the class. Corollary: we as teachers must believe in our students. Research has shown that a teacher's belief in a student's ability to perform is often self-fulfilling.
• Praise students not only for their projects, but also for exhibiting personal qualities that we want them to continue: hard work, persistence, etc.

Walter Rotenberry (Wake Tech), on the challenges faced by Community Colleges:

• The ideal case for a Community College is that you are based in a "hub" of the game industry, so that your graduates have immediate local employment and internship opportunities. What if there are no game companies in a 100-mile radius?
• An alternative: focus on entrepreneurship. Require your students to take classes in business, enough that they would be comfortable building their own startups. Give students the tools to start their own local studios.
• Wake Tech's approach to a two-year program is interesting: cover a little bit of everything (at least one or two courses from programming, design, art, production, audio, business, game studies, etc.) to give a well-rounded background. This provides a foundation for transfer to any four-year school. I thought this was an interesting approach -- in my experience, usually with only two years to work with, Community Colleges focus on art or programming. I'm not sure that one approach is "better" than the other, but I can see the use of both.
• Encourage students to take courses in other relevant areas and departments: theater/drama, history, storytelling, etc. - the bonus is that in many cases there is no need to add specialized "game" classes, you can work with what is already there.
• Wake Tech got an $800K grant from NSF to develop their curriculum. This money is not allowed to go to new hires, but can be spent on curriculum development and new equipment. Other schools may be able to get similar money, so it is worth looking into.

G. Michael Youngblood on Computer Science-focused game research:

• Students can get involved through an NSF program called REU (Research Experience for Undergrads).
• It's easy to get academics involved; this is what many of us do. Biggest challenge is collaboration across departments, since games are so interdisciplinary.
• If you're working in industry and want to get involved, the easiest way is to visit. Invite some local researchers to lunch. Look at their stuff, read their papers, ask questions on what you don't understand.
• You can support students for your own benefit! If you have an idea you'd like to test out, $1100 per month for a grad stipend x 5 months = $5500 for a prototype and white paper. This is a pretty good deal if you're a large studio with an R&D budget! Note that some schools and some researchers will ask to charge overhead (to cover costs of building maintenance, utilities, etc.) that is as much as 50% of your grant. You do not have to put up with this; operations costs are not required for non-governmental grants, and you can offer the funding on a take-it-or-leave-it basis. Most universities would rather accept money than turn it down.
• Be on a university's Industry Advisory Board. Suggest that they research difficult, interesting problems.

Michael's list of things that the industry should keep in mind when dealing with academic researchers (particularly in Computer Science):

• Academics are extremely "paper-focused". If there's not a publication in it, then it doesn't matter.
• Academics are always behind and have too much to do.
• Like any programmer, academic researchers will overstate their ability to deliver for nearly everything.
• If a study involves humans in any way (such as, say, using college students in a playtest of your game), learn about the IRB process.
• The field of games research has matured quickly. Two years ago, "I'm working on a game" was good enough to get published. Today, you must also be able to show why your game research is cool or useful in some way.

Random tidbits from side conversations:

• Games and learning are both negative feedback loops: once you have learned something, you don't want to learn it again. This drives students to learn something and then stop. We need to find a way to counteract this by including a positive feedback loop, so that great students will want to keep learning and to learn more.
• I wonder if a school has ever hired an entire small development studio. Granted, not everyone has teaching skills, but you would get complete coverage of all subject areas and you'd be hiring people who already know how to work together as a team.
• Giving students a general literacy of classic games is important. One approach: have students write "reviews" of classic games. How do you get them to play older arcade or console games in the first place, when the original hardware is hard to come by? Several alternatives: first, many companies are repackaging their classic games for sale on modern systems (Atari Flashback, Midway Classic Hits, original NES games downloadable on Wii, etc.); second, with questionable legality, you can download emulators such as MAME; and third, particularly useful in class, you can find short gameplay videos of just about everything on YouTube to show what some of these games looked and played like.

Topic for Discussion: Beating a Course

Recently, someone wrote me about my book, claiming they had finished all of the challenges. I'm not sure if the person was serious (there are over 300 of them, after all), but it got me thinking about books and games, and the difference at the end of each.

It struck me that when most students finish a class, there is a sense of relief. "Finally, it's over. Now I can sell my textbook, throw away my notes, and forget all the stuff I just spend three months cramming into my brain." We approach games very differently. Maybe you just beat God of War 2 or Bioshock or Fallout 3 or whatever, and there is a sense of closure there... but there are also a bunch of locked Achievements, secret levels, more intense difficulty modes, different character classes or progressions, all kinds of other things that give the player incentive to keep going after it is "over".

What would classes be like if they had this kind of incentive system? Where students voluntarily chose to go back and read the chapters that weren't covered during the main course (the way they would explore optional levels after completing the main storyline of a game), do all of the end-of-chapter exercises that weren't assigned (like optional sidequests), write their own material summary to help other students (like writing a FAQ or Walkthrough of a game), or discuss the class and some of their ideas about the material with their friends?

"I just beat the final boss in Vector Calculus yesterday. But I was thinking of going back and collecting all the secret bonuses in each chapter, building up my Trig skill, and maybe going through the book again on Hard Mode and unlocking the bonus chapters on Differential Equations at the end. And I'm totally pre-ordering the sequel class, I hear they're releasing it in the Fall." It sounds ridiculous, but really, why not?

Student Post-Mortems

In a class I taught that just finished, I had the students make a complete, full-featured, production-quality board game from scratch over the course of a month (this was the major project in the middle of the course). At the end, I asked everyone to do a personal "post-mortem" by listing the things that they felt went right and wrong in development.

The list of things I see are astonishingly similar to the professional post-mortems that you see on Gamasutra when people make video games, and I feel echoes of previous classes I've taught where students made video games. So, I think a lot of these lessons are generally applicable, and worth sharing.

Rather than breaking it down into things that went "right" or "wrong" in this particular class, I'll list these as general points of advice that were repeated themes throughout the class. Some students listed these as things they did well and were thankful for; other students listed the same things as weaknesses that they wished they had paid more attention to. For our purposes it doesn't matter; this is the advice that my class would give you and your students.

• Playtest your game regularly, several times a week. Start as early as you possibly can. The earlier you start, the more time you have to make radical adjustments. You can never playtest too early or too much.
• Playtest with a variety of people, not just the same group of friends. Test with family, classmates, complete strangers, anyone you can think of. New playtesters offer new insights. The wider variety of testers you have, the broader the appeal of your final game.
• Start with a simple, strong core concept. If you don't know the purpose of your game or where the fun is supposed to come from, you'll have a hard time getting there. On the other hand, if you have some basic gameplay constraints that you create for yourself, a lot of gameplay will come naturally from that and it will feel like the game is making itself.
• Be wary of oversimplification. In general, it is harder to simplify a game than to make it more complex, and you should strive to make your game as simple as possible. There is a flip side to this: if you are overzealous about streamlining the rules, it is possible to accidentally remove player interaction, interesting decisions, and strategic options. When you remove rules from your game to simplify, pay attention to the play to make sure you are not removing a critical element.
• Observe people playing your game, without interfering. The learning curve of a game is critical, and the only way to gauge this is to have new players sit down and try to play without your assistance. Watch them struggle and see where they fail. This is one of the only ways to identify critical holes in your game in the end stages; as the designer, you are too close to your own creation to see the obvious flaws yourself.
• Don't neglect theme. In an effort to build the best gameplay possible, don't forget that a strong theme that fits the mechanics can make the game easier to learn, and a fun theme can generate player interest from the start. Include something that players can personally identify with in the game, to make it easier for them to feel like they're "in the game."
• Some mechanics are higher risk than others. If you are doing something that has never been done before (or has only been done rarely), the final project will take a bit more time, and you should be prepared for that. There is probably a reason why it hasn't been done before, and the reason is probably that it is hard to get it to work! If you are heading into uncharted design territory, expect to spend at least double the time on the project that you would have otherwise.
• Pay attention to readability. Some color combinations make your game difficult to read (I've seen black text on a dark blue background which was nearly impossible to read, and also yellow text on a violet background which was just painful to look at). If you haven't studied color theory, at least look at all of the text and icons in your game and make sure you and your playtesters can read them without eye strain. Test in both bright light (e.g. outside in the sun) and low light conditions.
• Leave time for "polish" at the end. When you have a month or two to make a game, it feels like you have forever. Realize that you would ideally like to have everything "done" earlier than the final deadline, so that you have plenty of time to make the game look more professional. Little details matter in the final presentation, but you will only have time for them if you don't procrastinate and if you build this expectation into your schedule. (Even then, it is often hard to do.)

There were also a couple of hints that are specific to board games:

• If you are making any custom components, do "proofs" before paying to print the whole thing. For example, if you're printing many sheets of cards, print a single sheet to make sure everything lines up right and that the colors don't bleed.
• Avoid printing double-sided if you can, because it's hard to get everything lined up. If you must, add a thick border which will help mask any cutting errors.
• Allot plenty of time for creating final game components. Even if your rules are finalized and you know exactly what you need, the process of actually building everything (which might involve painting wooden pieces, printing at a local copy shop, cutting pieces, and any number of other things) takes a lot longer than you think it will, so don't leave it for the last minute.

Design versus Marketing

Students who are hardcore gamers (i.e. most of them, if you're teaching game design) are used to seeing the marketing-speak on the back of a game box (we call this "box copy"). You've seen it before: "Over 30 levels! 300 weapons! Epic, engaging storyline! Intuitive combat system!"

Most of these students have never seen an actual game design document before. This would be the document that actually describes the details. Exactly what are the contents of each level? What are the names, damage, speed, accuracy and other effects of each weapon? What happens in the story, when exactly is each bit of story revealed to the player, how much is text and how much is voice acting, what is every last line of dialogue? How, exactly, does the combat system work and what are the controls? And so on.

It is, apparently, easy to get these mixed up. Box copy is useless if you're giving it to a programmer to implement. How does a programmer write code for "intuitive combat system" exactly? The answer is that they don't -- they kick it back to the designer until they get the details.

I'm seeing this more and more with students lately, and I'll be taking additional steps in the future to warn them of the difference between design and marketing. I wonder if other teachers see this as frequently as I am... and what, if anything, they do about it.