Notes from GDC

Most of my notes that are relevant to teaching game design came from the IGDA Educational SIG during the Monday and Tuesday before the main conference. However, there were occasional sessions where I picked up something for this blog during GDC proper. Here are my notes:

From the Academic Group Gathering:

• Note that GDC 2008 is in February. Students working on projects for the IGF this year will have less time to submit.
• There is still interest in 24/7 game development with one team in America, one in Europe and one in Asia. Groups of students who take a quarter/semester hiatus to participate in this project is the most likely way it could happen. Personally, I think the game industry would be very interested in seeing if this works. The results of such an experiment could be used to significantly reduce time to market (with slightly greater cost).
• I doubt anyone in the industry would be willing to stake their current project on this, so if anyone tries it should be college students. Any takers?
• As an educator, talk with companies that give tests when hiring. They won’t give you their test, of course… but you can ask for a sample test that gives the general kinds of things they’re looking for. Collect enough of these from different sources and you can build a pretty solid picture of what the industry wants from your students.

From the Quality of Life roundtable:

• Some people are willing to make sacrifices (including their own QoL) to get a job in the game industry. Most of these people are recent college graduates.
• Problem: everyone who makes these sacrifices becomes part of the problem for everyone in the industry.
• Universities: make sure that your top graduating talent goes to game studios with good business practices, regarding QoL. Do not reward abusive studios with good talent; if the really bad places find they can only hire mediocre talent, it will make that business model much harder.

By the way, if anyone is interested in my notes from the other sessions that have nothing to do with this blog, email me (ai864 at yahoo dot com) and I'll send it to you.

Random Tidbits from GDC for Students

As I mentioned earlier, some of the best conversations at GDC happen between sessions. Here are my notes for students, and student mentors among the faculty (or in industry):

• Consider making a “job/idea board” at your school. Students with game ideas can post their projects, others can pitch in to help if they find a project that sounds good. Forces students to convince others that their idea is worth anything – good practice for industry.
• Apparently, something called “XSI Base” is already a de facto standard for this. I haven't investigated the matter yet.
• You can never remind students enough that they should keep their project scope small and achievable. Attention student game developers: Geometry Wars is fun. So is Tetris. Neither one needs an advanced degree in Computer Science. If you're having trouble coming up with ideas that are small in scope, study retro games!
• Many universities have some kind of “Capstone” experience – students working together in groups to make a complete game. A good rule of thumb: 8 to 18 students per team; one semester pre-production (with final deliverable being a functional prototype), one semester production (final deliverable is a 5 to 10 minute mini-game).
• Amusing suggestion to teachers: “Make all students cancel their WoW accounts at the start of the school year. If they don’t, call their parents.”
• There are lots of game engines out there now, with varying degrees of power versus ease-of-use. Game Maker is great for those with very little technical experience, although it’s mostly limited to 2D retro-games and its framerate and collision detection are only so-so. Torque 2D and GameBrix both seemed popular, and they offer academic discounts. Game Studio A6 interfaces with C++ and supports graphics pretty easily, but has some bugs. With any game engine or authoring tool, having good documentation is key. Others that I heard mentioned later at the conference: ConsoleClassics, Click N Play, The Games Factory. I'll likely spend a good chunk of summer evaluating any demos I can find.

Random Tidbits from GDC for Teachers

Some of the most interesting things I learned at GDC came from hallway conversations, outside of the sessions themselves. I'm glad I carried a notebook with me at all times to record the best ideas. Here are my notes:

Possible assignment for a game design class:

• First, have each student create a game concept.
• Next, have each student create a design document based on the concept of another student who got the same grade as they did.

For a Capstone (student project-based) class:

• In addition to developers (programmers, designers, audio, producers, artists) consider adding one business student in a BizDev role. It’s their job to figure out how to market the current game that the team is working on… and how to fund the next one. This will likely create a number of uncomfortable constraints on the rest of the team, which they will find very familiar once they start working in the industry.
• Suggest to programmers to use generic names for their objects. If you have a flying enemy called a Hawk, call it something like CFlyingEnemy. Often during the course of development, names and art will change – maybe it will become a Vulture or a Biplane or something instead of a Hawk, and the code becomes confusing to anyone who doesn’t know the history of the game’s development. Amusing anecdotal example: in one project, the programmer called all enemies “Baddies” in the code. Some people found this unprofessional… but you can bet any new programmers working with that code know what’s going on!

On Game Design and Architecture:

• Game design is very similar to architecture. In both cases you’re creating the plans for a team to build something.
• So… why do game designers ignore this? Why is Architecture not a required class for all game designers? (I have no answer for this. Anyone want to suggest why this would be a good or bad idea?)

Call for Collaboration:

• Educators who teach game-related courses: post your syllabus online. Got to http://www.igda.org/, log in, then go to Wiki (under the Community heading in the menu), then click on Game Education. There’s a link to add your course to the collection. Follow the instructions from there.If you’re unfamiliar or uncomfortable with editing a Wiki, you can send your course info to the Wiki admins and they’ll post it for you.
• Even if you don't contribute (and shame on you!), the EdSIG Wiki is a great resource if you're setting up a course (or a curriculum) to see what others are doing with the same subject material.

Another Course for Game Design Students

The IGDA Educational SIG at GDC showed me another course that deserves to be part of my proposed curriculum for Game Design majors: Game Appreciation.

Any student who wants to be an artist should take Art Appreciation. Film students take Film Appreciation. Music students take Music Appreciation. Game designers should, therefore, take Game Appreciation.

What would a Game Appreciation course look like? It would involve playing lots of games -- pretty much every game that is widely known in the industry for its gameplay (good or bad). I could offer a list of games, but first I'll welcome all of you to do the same in the comments. At any rate, students would play these games as homework and in class, and then discuss them in class: why the games were important, where the innovations are, what was derivative of what.

Why would this course be useful? First, it's needed as a basis for understanding the art form. Second, it provides the closest thing we have to a critical vocabulary -- "this game is like that other one" -- so it's good to know the right games to compare new ones to. Third, anyone who wants a job in the game industry (especially as a designer) should be familiar with the great works of the past (and present) in order to not appear uneducated. Fourth, it gets your enrollment numbers up because it's an entire course about playing games.

Ohio Game Jam finishes a success

This last weekend was the Ohio Game Jam. We had nineteen brave students... some from across the street, some from as far away as Baltimore. Over a mere 24 hours they created a total of seven working games from six groups, a 116% success rate. I'll post the games and a list of participants on the website as soon as I have everything collected in one place.

As expected, the theme "Nature and Technology" had wildly different interpretations among teams. We also had a number of game types: sim, turn-based strategy, real-time strategy (!), action-arcade, two game-like interactive stories, and one turn-based/real-time action-strategy hybrid.

Lessons learned about game development:

• Keep your scope constrained. Start with a small game whose core mechanics are fun, then expand it as time allows. You end up in a much better position if you already have a working game a few months before alpha, and it's just a matter of polishing, balancing and figuring out what features to add... rather than not having enough time and deciding what to cut. Every project at the game jam was in this happy situation with a few hours to spare; if only more commercial game projects followed suit!
• Not everyone was a jack of all trades, and several groups found themselves in the position where the Game Designer had finished with the initial design, and had to just sit around and wait for the Programmer to reach a first-playable state. One team's designer decided to hover over the programmer and comment on implementation, something akin to the oft-maligned "pair programming", and found great success with it. I suspect this has applications in the industry; pairing up two programmers is questionable because they may not be twice as productive working together as they would be individually... but designers are less expensive than programmers, so having a "programmer and a half" (in terms of payroll) is a much easier pill to swallow. Especially if the designers have nothing else to do on the project anyway.
• Having a balanced team helps. If your team doesn't have any Programmers, you'll be very limited in the kinds of games you can make. If you're missing a Designer, you're in serious danger of not having anything particularly interesting or experimental. Lack of an Artist or Sound person makes your game seem less impressive, and more importantly takes away time from your Programmers and Designers while they're forced to make or find some placeholder art and sound.
• Learn some kind of rapid-prototyping / game-authoring tool ahead of time. Over half of the games used Flash. Others used Game Maker. I've heard good things about (but not evaluated) Torque 2D, Blitz Basic, Dark Basic and Game Brix. Whatever you choose, but learn something. If you're a programmer, you'll probably get stuff done faster using an engine than if you have to write everything yourself from scratch in C++. If you're not a programmer, these tools will give you something to mess around with during downtime when no one's demanding art/music/designs from you.
• The visceral feel of a game matters, so much that it's hard to overstate. The fun of a game has no correlation with the time spent on it. These two concepts together mean that it's better to rapidly prototype a large quantity of crazy ideas, rather than spend lots of resources on the first idea you come up with. This isn't news, but it was demonstrated quite well at the game jam: the overwhelming favorite project of the event was a quick little arcade shooting/dodging game that one person put together in an hour or two while he was was waiting for the rest of his team to wake up.
• That said, the overall level of production values definitely does correlate with the amount of time spent on it. Generally, the best-looking games had been worked on for the longest periods of time. It's important to not confuse production values with fun.

Lessons learned about running a Game Jam, since this was the first that any of us had attended (including me, and I'm running the thing):

• Actually organizing the event is trivial. All you need is to declare a venue and a date/time. "Game jam, my living room, next Saturday" is all you need; the rest is just a bonus.
• Of course, that also limits participation to just you. While some people have no problem with this, I personally think it's more fun if there's a group of people working collaboratively, and getting the word out is the greatest challenge. Especially if you live in Ohio. I found more success promoting the event in my classes, at GDC and on the IGDA's Game Edu mailing list than other methods. Also tried were viral marketing (i.e. asking everyone I knew to tell everyone they knew -- apparently a month isn't long enough for this to take hold), and media coverage (only received two days prior to the event).
• Asking for sponsorship helps, if you know who to ask. We had generous donations of pizza from Papa John's, and some books from AK Peters. Being well-stocked with food, drinks and snacks ahead of time helps greatly.
• For a 24-hour event, allow some time for people to sleep. I had thought that college students would have no problem staying awake and productive the whole time, but it turned out that just about everyone had at least a few hours' sleep, no matter how much caffeine they'd imbibed. (Next time I'll encourage teams to work in shifts, to make sure everyone gets some sleep.)
• Send a reminder email a day or two before to everyone who RSVP'd. I didn't do this, and about five people didn't show even though they'd previously sent me email saying they'd be there.
• Have a guestbook for everyone to sign on their way out. I thought of this, but forgot to actually set it up at the end due to lack of sleep, so I never got everyone's comments.
• Nametags were useful. Color-coded dots so people could identify themselves as Programmers, Designers, Artists and/or Musicians was helpful when people formed groups were also useful.
• Having a theme that's open to interpretation helps you to get a wider variety of games, since teams can go in so many directions, and their first question is always "okay, what does this mean?" If you have a theme in mind ahead of time, however, it makes it much harder for you (as event coordinator) to participate, since you have an unfair advantage. In the future I might find some random way to choose a theme, so that I can be as surprised as everyone else.
• Actually coordinating during the event didn't involve very much effort; there was a lot of down time. Mostly, teams were autonomous, and my role was to foster a spirit of collaboration: "How's it going? Oh, you're having trouble with a bug in Flash? There's a few guys on that other team over there that seem pretty good at Flash, let me introduce you." I also probably should have been the one to make runs for sodas and snacks, but the teams handled this on their own... and it may have been better that way, as it gave participants an excuse to take a five-minute break with a quick walk outside.
• Internet access is very useful to have, mostly because teams can search for stock art and sound effects for placeholders faster than making it themselves. Wherever you run your game jam, make sure there's wireless... or a few hubs and routers.
• Other hardware we found useful: a scanner (lets artists sketch on paper), some basic sound equipment for recording music and voice, and a coffee maker. Participants provided all of these on the fly, as needed; next time I'll try to have them ready beforehand.
• Don't advertise big, elaborate prizes. Any judging you do will be subjective anyway, and you want to give teams incentive to collaborate rather than sabotage. The goal is to have some great games by the end of 24 hours, and it's much easier to have that if everyone's working together.
• Definitely favor small teams over one big team. Extra people don't help you make a better game, so you're better off making more games and increasing the chances of having one that's brilliant.
• Don't be afraid to change teams on the fly if people are having creative differences. Some of our most interesting games came from teams that separated. For a future event, I might consider running slightly larger teams (4 to 6 people) and having each team work on two projects simultaneously, with each individual going back and forth between them to break up the monotony.

Game Designer as Event Host

It occurs to me that if game design is about creating an enjoyable player experience, it must share something in common with other fields that have similar goals: hotel guest services, cruise ship directing, wedding/party planning, and special event hosting. The abstract idea of "customer-centric" thinking and design applies to all of these.

Yesterday, we were fortunate enough to have a special event on campus that was one of the most terribly-run things I've had the misfortune to attend. It was a great case study for my design students; I hope they come back in future years to provide such a powerful object lesson for future classes.

The event was run by some promotions company that was apparently hired by Microsoft to push the Xbox 360, but in the process picked up game-friendly sponsors like Best Buy and (for some reason) Suzuki. They were certainly well-funded; they came with a pimped-out car and a large bus with sponsor decals all over, and they brought forty 360's (I suppose that makes one Xbox 14400, har) and so many plasma screens, and all kinds of giveaway swag. The guys running the event had an average of about ten years experience each. So, they had all the tools and potential for a massively successful event on any college campus. Which makes the whole thing that much more disappointing (and informative).

Among their errors:

• No advance promotion of the event. They had people scattered across campus handing out fliers the morning of. No one I talked to knew anything about it beforehand, in spite of there being rather prominent television, radio and newspaper media all over the place.
• Very loud music was playing at the event, making it impossible to hear any sound from the games themselves. This made the new Dance Dance Revolution game impossible to play.
• All those consoles and not enough controllers. Dance Dance Revolution (a game meant to be played socially) had one dance mat per console, so you couldn't play with a friend (and it was one of those cheap $10 pads too, so you couldn't play any advanced songs). Fuzion Frenzy 2, a party game meant to be played with four people, had two controllers. Gears of War, a first-person shooter known for its excellent multiplayer mode (and equally known for its mediocre one-player) had one controller.
• Some guy was trying to be an emcee, walking around with a microphone and taunting the people who were trying to play. In the words of one of my students, "he was trying way too hard to look like he was cool."
• Overall, the whole thing just felt like it was put together by people who knew a lot about promotional events... and absolutely nothing about games or gamers. The result is similar to what happens when an all-male team of game developers tries to make a game for little girls.

What lessons do we learn about game design from this? Well, that's an exercise I left to my students!

Kurt Squire on Curricular Models

Another wonderful talk from the IGDA Educational SIG at GDC, courtesy of Kurt Squire. These are my notes:


A few years ago, we had: Game Dev programs (DigiPen, Full Sail); “Art and Design” schools (but with few game-specific offerings); ETC at CMU (grad school only); Computer Science; Media Arts & Sciences; Instructional Design; and for college dropouts, the School of Hard Knocks.

Today, we have game design degrees! Why? Popularity (or, increased enrollment); Intellectually interesting; Training for the game industry; Core disciplinary issues: interactivity, teamwork, etc. (carries over to many other fields).

There are lots of different ways to study games.

All faculty who teach games ought to play them, regularly.

Consider a “boot camp” introduction model: low-level courses that show that game development is very hard work, to turn away the students who aren’t self-motivated or serious about making games their career.

What happens outside class is more important than in class. Set up your academic program to encourage out-of-class work. One thing that can help a lot: have your university provide an open lab space where students can work on their own game projects – ad-hoc, informal, driven by excited students.

Have students work in teams. Have your faculty understand (and teach) cooperative learning.

You and your students will have many iterations for everything: individual projects, courses, and overall curriculum. Learn from failures.

Create opportunities for celebration, community ritual. Example: student project showcase at the end of each year.

Game Research Case Studies

There isn't a lot of academic research in the field of game design, and what little there is, I have trouble relating to. At the IGDA Educational SIG at GDC, it was refreshing to see a number of different takes on research that focus on gameplay -- exactly the type of research I'd like to do myself, in those hours when I'm not teaching. Here are my notes from the session:

Jesse Schell (CMU ETC):

• Industry/Academic bridges are mostly 1:1.
• One major problem: many universities can’t hire people with just a BS/BA degree, regardless of industry experience. (Example from last year’s GDC: the Lead Artist for World of Warcraft is unqualified to teach art at many universities. Wait… unqualified?)
• There’s a huge bonus on both sides if this problem can be solved. As people cross borders between Industry and Academy, there is a transfer of technology and information.
• The universities that build the best programs will likely be the ones that are able to find loopholes in the system, creative ways to get experienced industry people teaching their students in some capacity.

James Dargie (EALA):

• Internally, EA has a process that’s something like rapid prototyping, but with artists instead of technical designers.
• Pre-rendered trailer video, takes 1 to 3 months.
• Shows visual style, quality bar and gameplay features at the start of a project.

Jeremy Gordon (Secret Level / SEGA):

• Undirected R&D is attractive to industry since we’re all trying to solve the problems we don’t know about yet.
• But… it requires overtime or extra funding (or both), and there’s no immediate ROI.

Doug Whately (Breakaway Games):

• Breakaway has an interesting funding model internally: Serious Games and Entertainment Games divisions. Serious provides funding for Entertainment, which is treated as funded R&D whose results can be used by Serious.
• (I found out later that there’s a similar symbiotic relationship between Wahoo Studios and NinjaBee, with Wahoo creating AAA games that fund NinjaBee’s low-budget indie games, which in turn are treated as R&D to help Wahoo.)
• Working with universities is hard because of scheduling. Universities work around the academic calendar; game studios work around fiscal years.
• Suggested that some studios might do better if they have rotating undergrad internships throughout the year, encouraging Seniors to take a quarter or semester “sabbatical” to work in the industry for 3-4 months during the school year. In this way, a company can have a steady supply of student interns year-round… not just in the Summer.
• In classroom learning games, expect to see a huge battle between professors. Half will love it because it gives them new tools to teach; half will hate it because it’s an outside intrusion into their acutely-honed, time-tested lesson plans.

John Hopson (Microsoft Games User Research Group):

• Developers are inherently distrustful of anyone trying to tell them how to do their job. This includes academic researchers. If you approach a studio saying “my research shows exactly what you’re doing wrong”… prepare to be ignored.
• Start out with one-on-one: “Give me half an hour of your time, and we’ll show you how to make a better game.” After that works and you’ve built up a small amount of trust, ask for a little more… one baby step at a time. Build long-term trust.
• Schools need to promote their technology to the industry: make sure you show up on a Google search when the industry is looking for you!
• Build cool stuff. If you write a paper for the industry that you think is so great, why don’t you use it? Better to make a working demo, then write a paper that explains how you did it. (Façade is a good example of this.)
• We all have the same concerns as any other field of research that tries to interface with industry. The only difference is that our industry is relatively new.

Doug Church on Academic/Industry Collaboration

The great Doug Church gave a keynote at the IGDA Educational SIG at GDC. Here are my notes from his session:

Research:

• The things the industry wants done, it’s doing already.
• The things the industry doesn’t know it needs… well…
• There is no pattern of discovery in gameplay, i.e. no way to build on previous work. Game AI is in a similar state. (Graphics and Physics do have a pattern of discovery; that’s what SIGGRAPH is for.)
• There is no design publishing culture, and no design or game-analysis critical vocabulary. We’re stuck describing game mechanics as “it’s like this other game”.
• Not much “software publishing” culture at universities.
• Ideally, it would be good to enable undirected research in the Academy.

Sharing Tools/Engines:

• Academics are always asking to use industry game engines to help with their work.
• Industry doesn’t want to inflict their barely-working engine on poor unsuspecting academics. (Engines are usually coupled with the team and processes that built them; just handing an engine to someone else won’t be much help.)
• Also, some companies treat their engine as IP.
• Memorable quote: “If someone stole all the code from Electronic Arts, it would probably hurt them more than help them.”

Knowledge Transfer:

• The people in the industry didn’t learn from textbooks.
• The industry is guild/apprentice like. No shared context, philosophy or vocabulary.
• When an academic tries to approach someone in industry, the response has more to do with timing than anything else: a developer under crunch won’t respond to your emails even if they’d really like to help you.
• The industry has a hard time with long-term commitment. The Academy can’t easily promise specifics or results by a given date. This makes it hard for the industry to fund formal academic research.
• Also, developers are skeptical of formal training, while academics are skeptical of the academic value of games. (Hopefully both of these will change in the future.)

What Next?

• Students are the key stakeholders in everything; put them first.
• More industry/academics working together; for now this is limited to 1:1 collaborations.
• Universities must understand that a game-focused curriculum is not just an interesting backdrop for the “real” education, or a diversion from it; game development courses are an invitation into a community and a chance to choose a future.
• Use iterative processes on different ways to collaborate:
• Lightweight participation is easy. That’s what we do now. We need more 1:1 successes until we get some critical mass.
• Bidirectional placement! Can a developer teach a course in their spare time (or take a year off to do so full-time)? Can a professor work in industry during their sabbatical year?
• Developers need to give academics more access to their efforts, so that good practice can be studied and documented.
• More student group projects! (Amusing possibility: each year’s crop of students must not only create their own game project, but also support the previous team’s software.)
• We need formalized grammar and vocabulary, but it’s uncertain where this will come from. Previous tries from academia were forced/mandated and didn’t work. Not coming from industry, either.
• Overall: we need energy, motivation, mutual respect, and people who understand both sides… like today’s students!
• Both sides need to balance reality with idealism.

Q: How valuable is it to teach students methodologies (e.g. agile development, time estimation)?
A: Specifics are not as important as the experience of trying – and understanding that game development is hard and can go horribly wrong!

Q: How can academics study the industry when it’s so secretive?
A: Indie studios may be more willing to open their doors. Or, cultivate relationships with many individual developers, and contact someone who just shipped a successful game and has some pull in their organization.

The Critical Vocabulary Problem

I saw this touched on briefly at GDC this year, but no solutions were given. That's a shame, because it's not something that I can see solving itself anytime soon, and game designers really need to make some progress here.

The problem is that we really don't have a critical vocabulary in the field of game design. When we talk about game mechanics or dynamics, the best we can do is to compare it with what's been done before: "It's like the sandbox mode of GTA with the combat system from Halo, and the mini-map from Ratchet & Clank."

This is limiting: it prevents us from describing new innovations (I remember people trying to describe Everyday Shooter at GDC, and the best we could do was "you have to play it, then you'll understand"). It also limits us even when discussing purely derivative works; if I haven't played Okami, then you can't compare it to another game and have any real understanding between us.

So, we need a better vocabulary. Which leads to the next problem: everyone writing a game design textbook is trying to solve the problem at the same time, each with their own proposed language.

None of these get absorbed into the collective consciousness of the industry, because no single textbook on game design has been read by enough game designers. But designers in the field aren't trying to create their own vocabulary, either.

As a teacher, this creates additional problems. Suppose I use a textbook that uses a combination of existing industry jargon, and new terminology coined by the authors. I've yet to see a book that makes a distinction between the two, so I have to manually warn my students about which terms are okay to use if they're talking with a designer, and which ones they should ignore (or at least use cautiously). But then, if enough students who studied one particular textbook find themselves in the industry, this terminology could start getting used... and then I'm in the position of trying to predict which of the many textbooks will see widespread adoption in the next few years.

And then there are the teachers out there who have no game design (or game industry) experience, and couldn't tell a good textbook from a bad one, and won't be able to make the distinction between "currently in use" and "proposed" terminology in their classes. My students will be competing with these, and the other students may even sound smarter, with their talk about operational versus constructive rules... even though my students might be better prepared for the industry.

Ultimately, I'm not sure what direction a long-term solution can come from. Industry is too busy to figure this out on its own, and too insular to listen to suggestions from academics. Today's students may carry some critical vocabulary with them, but it's so scattered across many different texts that there's unlikely to be a consensus. I suppose it will ultimately take a single game design book that is so much better than the rest, that it gets adopted by every class overnight. Any volunteers to write it?

I now have a reputation for strange finals...

On Tuesday, I gave the game design final. Students in small teams learned to brainstorm game concepts over the course of the last ten weeks. This time I threw in a few twists. Three times, I changed the requirements. Once, I had one student from each group rotate to a new group (to simulate losing a team member and having to train a new one). Towards the end, I suddenly reduced the time limit, and then added it back when it would no longer do any good.

The students loved it. They totally understood that this was inspired by real-world events, and that all of the new requirements were drawn from previous projects they had done. I was afraid I'd hear a lot of complaints of unfairness, but my fears turned out to be unnecessary.

I did hear of a similar mechanism from another game design teacher at GDC. Instead of having pre-scripted events like mine, she used a "wheel of misfortune" to choose events randomly. I prefer that solution as a way to deflect students' ire (if there is any) -- it's not my fault, it's the wheel!

Conflicting Goals for Game Schools

As I recover from GDC, I'll be posting all of the stuff I learned about teaching and game design. I probably have enough material to keep me busy for the next few months.

I'll start off with an inherent conflict within any sort of game-related program: the desire to attract students, and the need to only graduate the best ones.

On the need to attract students:

• If you're at a liberal arts college that's experimenting with its first game curriculum, you need decent enrollment numbers to show student interest. If your numbers are too low, the program gets canceled.
• More students means more funding, which translates to better equipment and more resources to help your students make great games.
• If your school has a reputation for a 90% dropout rate because you're just that harsh to your students, you'll have a hard time attracting anyone -- even skilled students who can make it, but who might not have the self-confidence to try.
• Failed attempts hurt students a bit too much. If you have two semesters' worth of F's, it would take seven years' worth of straight A's to get back to a 3.5 GPA (which is a requirement for some grad schools and scholarships). Without some kind of grade amnesty/forgiveness, this seems a bit harsh for a program that will obviously interest many students who aren't prepared for it.

On the need to only graduate a few:

• The game industry is still very skeptical of game-related academic programs. Simply slapping a label like "Game Design Major" on your students will not give them any legitimacy when they look for jobs.
• Because of this, your students are effectively representing your school and in fact all schools with game programs whenever they interact with the industry in any way.
• Since it's such a small industry, word gets around very fast. If one company hires one of your students and later finds out they have no idea what they're doing, it will be an uphill battle for any of your future graduates since all of the major studios will "know" that your program isn't preparing its students.
• Even applying for a job is enough to soil your school's reputation. If a student shows a game-specific Major on a resume, attached to the worst cover letter ever written, what does that say about your school?
• The game industry is a harsh world. Treating students gently does not prepare them for cold reality. Better for students to get used to it in school, and those that can't handle the abuse will be happier in the long run to not enter the industry in the first place.

I can see both sides. So far, I've been erring on the side of helping students as best I can, because low enrollment numbers puts my department out of a job. In the future, as our program gets better established, I'd like to shift towards a "boot camp" mentality, with some low-level classes that are overly harsh. This allows students to self-select out of the sequence before they do too much damage to themselves, and guarantees that only the ones who are really serious will continue on to the more "fun" parts. But by then, we may already have a reputation for being too easy on our students, and it will take time to reverse that.

Welcome, new visitors

I've met a lot of new people at GDC already. The two-day workshop on education was an absolute blast, and I enjoyed meeting so many people struggling with the same challenges that I did. This is exactly the spirit in which GDC itself was originally founded -- we're all isolated from each other, forced to reinvent each other's wheels, so let's just get together and share our knowledge so that we can all benefit.

If you're new:

Most of my posts are not time-sensitive, so feel free to browse the archives (and even comment on them). A logical place to start would be my original welcome message, followed by my series of posts on building a game design curriculum.

For those of you looking for the notes from today's talks, the notes from the undergraduate game design session is here (thanks, Beth). The notes from my five-minute case study aren't online in the Education SIG blog right now, but my final exam rules are posted here, and my after-the-fact comments on the final exam are here.

Lies I Tell My Students

I'm not much of a party animal or night owl anyway, so I'll just finish grading all of the assignments at GDC after the day's sessions are over.

Yeah, right.

This would have worked last year when I was a newcomer. This year, I know far too many people in the community. I didn't realize this until last night, when I found enough people at the Marriott ("the new Fairmont") to keep me entertained until past midnight... and this is on Monday, before most people are even here.

Oh well, it seemed like a good idea at the time...

Off to GDC

Well, this is it... I'm leaving in about half an hour for the airport.

For those of you who are going to GDC as well, I hope to see you there. Look for a guy in glasses with a gray hoodie and a backpack, with 1d3 students in tow at any given point in time, and the name "Ian Schreiber" dangling from his neck.

For those of you who aren't going, I'll try to keep this blog updated on the normal schedule... but no promises. Maybe I'll be so busy that I can't post anything. Maybe I'll see so much cool stuff that I'll post much more content than normal.

Teaching: Recent Advice

Recently, another (far more experienced than me) professor gave me some unsolicited advice about teaching. This is the first time that this has happened since I started teaching, and I am grateful for it:

• The best use of student evaluations (especially the numeric parts, i.e. "rate this professor from 1 to 10 in the following areas") is to identify my own relative strengths and weaknesses. There are no absolute criteria to base the numbers on, so knowing that I got a "7" in one category isn't that useful... unless most of my other numbers were significantly higher or lower.
• Sitting in on another professor's class in order to observe their teaching style is fine, but it's considered polite to warn them first and schedule in advance. No, I haven't committed a faux pas here... but I might have, since it never would have occurred to me. If someone sat in on my class unannounced I'd be flattered.
• College students aren't fully alert until around 10 or 11 am. If I get stuck with a 9:00 class, there is absolutely nothing I can do about this; it's a fight with human biology.
• (Corollary 1: If I ever have a say in such things, insist that the earliest classes of the day start at 10, even if it means that the afternoon classes end at 6 instead of 4 or 5.)
• (Corollary 2: If I can't do that, insist that the early-morning classes are the most useless and expendable in the entire curriculum.)
• It's good to end class with a game. It reminds the students why they took my class in the first place; it reinforces what we've learned during the class; and amount of time spent on the game can shrink or expand based on how fast we got through the rest of the content.
• It's good to ask students lots of questions and keep them engaged throughout. As time goes on, I'll learn to spend less time speaking and more time asking good questions and then moderating the conversation. (Should be a useful skill if I ever moderate a GDC roundtable.)

Culture Shock: Information Sharing between Peers

When I was working at a game company, there were always a lot of people looking for information. Different people would read Gamasutra, GameDailyBiz, Game Developer Magazine, or any number of other websites, blogs and publications.

If you found something interesting, you would generally send it around to the other people at your company who might also find it interesting. Usually this meant one Game Designer would send an article on Game Design to all the other Game Designers, but there was no rule against crossing departmental boundaries; maybe an Artist would find an incomprehensible document on Graphics Programming, and forward it on to the Programming department.

And this was fine. We're all on the same team. If you find something that helps another teammate do their job better, you get social points for it.

As a teacher, I find myself continuing to do this out of habit. I hear a story on NPR about indie bands and I mention it to the professor who teaches audio production. I see an article on game writing and forward it on to the professor who teaches nonlinear storytelling.

And it just occurred to me, after half a year of doing this, that I've never received anything like that from anyone else on the faculty.

Maybe it's just that no one I work with is actually keeping tabs on the game industry as much as I am, or that everyone else is too busy to be thinking about it. But I'm wondering if there isn't a different culture in academia -- it feels less like we're a team, after all -- and maybe when I do this it's construed as me telling my colleagues how to do their job, or implying that they need my help or something. Not my intention at all, of course, but I have to wonder.

Students: Reading between the lines

For many companies, especially large ones and especially those that are public, a lot of attention is given to PR, corporate image, etc. that leads to a tendency to try and appear perfect. Every public statement is whitewashed, the language sanitized for their protection.

This causes interesting conflicts within the game industry. One conflict commonly cited is game reviews by magazines: it's tough to write a negative review when the game's publisher is taking out a full-page ad for the same game in the same magazine.

Another conflict that's more immediately relevant to students is the stuff they read online, particularly Gamasutra's post-mortems of projects. A large game publisher might not want to air their dirty laundry, saying everything that went wrong on the project that's currently selling in stores. As such, one has to read the "what went wrong" section very carefully to get to the real story of what happened.

It's particularly fun when you can be your own example, as I'm finding out now for the first time. A student pointed out to me that GameTap's Rick Sanchez had responded to my letter criticizing his treatment of episodic content in games. The man works for GameTap, so he clearly can't say anything negative about their business model; yet, he says that he agrees with some of my points, so a student following this dialogue would have to expertly read between the lines to decide what Rick really thinks. And that's a skill worth having.

Emergent Design: The Generic Genre

In the industry, you're often focused on a specific genre of game, not thinking about the broad spectrum of games as a whole. So perhaps it takes a student's eye to spot larger industry trends.

Such it was today in class, when my Game Design students came to the conclusion that you could make a "kart racing" game for any IP, any license at all... while still respecting the original story. We were unable to find an exception. It would seem to be an entirely generic genre.

Teaching: Tradeoff between ease of grading, ease of cheating

It occurred to me that as I make homework assignments easier for myself to grade, I also make it easier for students to cheat on them.

At one end of the scale there's multiple-choice questions which are absolutely trivial to copy, and impossible for me to prove any shenanigans unless I use high-powered statistical software.

At the other end of the scale is an original essay, which is basically impossible to copy without it being obvious (I can even type key phrases into Google to check for copying from outside sources), but original works take at least half an hour to grade each... which adds up in a 30-person class.

I want to narrow the scope of the essays, perhaps even reducing them to bullet-point lists, next time I teach the class. But now I'm realizing that the more time I save on grading, the more time I have to put into making the assignment cheat-proof, so I'm not sure if I can actually save time at all.

Teaching: Teacher as Game Designer?

With the second offering of my Game Industry Survey course, I reworded a few of the homework assignments to make it clearer what I was looking for, based on confusion from the first offering.

Sure enough, the new crop of students is better at providing what I asked for, because my documentation was clearer.

Now I'm starting to wonder if this is entirely positive. In game development, clear specs that leave nothing to the programmers' imaginations is considered a good thing, because you're trying to make a game that's true to the designers' vision. But in a classroom, removing the students' room for creativity teaches them that they should be prepared to accept clean, detailed specs and follow instructions... not exactly the skills I want to pass on to the next generation of game designers.

In a way, if I treat homework assignments as design documents, my students end up getting better grades... but perhaps not learning as much.

Teaching: Teachers as Marketing (?!)

Normally I don't just link to the post on some other blog (I'd rather make my own content, thanks) but this article was too relevant to pass on. In brief: marketers spend their time trying to get your brain to pay attention and learn their message (something that teachers could do better at), and teachers spend their time transferring actual, useful information (something marketers could do better at). Sounds like a good idea to me.

I would add game designers into the mix; their entire purpose in life is to take a game and make it Fun (whatever "Fun" means).

So, teachers could learn from game designers: how to take this "Learning" and make it Fun. (Or rather, since learning is inherently fun -- especially in the case of game development classes -- how to take this "Learning" and not suck the inherent Fun out of it.)

Marketers could learn from game designers: how to take your advertising product and make it fun. Interactive advergames that concentrate too much on product marketing end up not being very fun, and thus losing their message.

Game designers can learn from marketers: all that brain research on how to get the brain to pay attention seems rather handy. As it is, we're still stuck with Csikszentmihalyi's 17-year-old research.

Game designers can learn from teachers: if you have some kind of greater social message you want to include in your game, how can you do it without beating your player over the head with the message in every cut scene? Especially useful for those working on training games, advergames or other "serious games" that are more than just entertainment.

Culture Shock: Textbook Evaluations

There were definitely times as a game developer when I'd have "I can't believe I'm actually getting paid to do this" moments.

The other day, I receive an email from a textbook publisher asking me to fill out a survey on one of their books; they're considering a new edition and they want to know what teachers think of the current one. I happen to already have a copy, so it doesn't involve any extra time on my part to evaluate the thing -- I did that months ago.

So, I'm offered a complimentary copy of the book that I already have (hello, ebay), plus another book of my choice, plus a small amount of cash. In exchange for the privilege of letting a textbook company know how their products can be better modified to serve me, and knowing that they'll actually listen. Twist my arm, why don't you!

I never had this in the game industry. No one ever came to me as a programmer and said "here, we'll pay you to tell us what new features to implement in the next version of Visual Studio". No one approached me as a designer saying "we'd like to give you this complimentary copy of our mind-mapping software, just let us know if you find it useful." It's an entirely different dynamic.

Teaching: Student mistakes

To my Game Industry Survey students, most of the topics we cover are completely foreign concepts. When I ask them to research and present a topic in class, it's only natural that mistakes will be made; this is new material for them, and they have no way of knowing what's vitally important and what's a minor detail.

On the other hand, they really should know the important details by the end of the class. A simple slip like asking a game developer if they have any openings in "Q&A" will pretty much end the conversation right there.

So, when a student says Richard Garriott is otherwise known as "King British," part of me wants to be lenient because they did get the general idea, and they were clearly trying. And then part of me wants to take 50% off their grade, because I'm pretty sure that saying something like that at GDC is grounds for ejection from the premises. I'm still trying to figure out what's fair. (I suppose I could split the difference, being lenient in the presentation and then asking about it during the final exam...)

I should be clear that I mean no disrespect towards the guilty party; this is one example of many. I chose it because I felt it would resonate best with my readers who are game developers.

I will say that I visibly wince when something like this happens in class. I can't help it, it's a natural reflex. Maybe seeing that is punishment enough.

Speaking at GDC

It's official. I'll enjoy five of my fifteen minutes of fame on Tuesday, March 6.

I'll present my final exam from the Fall, condensed down to five minutes, during the International Case Blasts session. It's part of the IGDA Education SIG Curriculum Workshop.

I'm really excited to be able to share my experience with other game educators. If any readers will be at GDC this year for the full five days, drop by and say hi after the session!

Emergent Design: Sound Design

My Capstone course (where a group of students create a complete game) is fortunate to have a Sound Designer as one of the eight students on the development team. On a professional development team this might seem like overkill -- the ratio of Game Audio to Everyone Else is usually closer to 1 in 40, not 1 in 8. There are exceptions, but our game isn't one of them.

Anyway, our sound designer comes in on one of the first days of class with a short looping sound for background music. It consisted of two tracks: a light, airy guitar melody and some deep bass drums. They're part of the same rhythm, so it's really just one sound loop divided into two tracks.

Here's the interesting part. By changing the relative volume of these tracks on the fly, the nature of the sound changes. If your avatar is flying through the air, play 90% guitar / 10% drums. If you're deep underground, change to 10% guitar / 90% drums. Walking on the ground, it's 50/50. Same song, but the nature of it changes dynamically based on character location (or health, or proximity of enemies, or what have you). It really sounds like three different songs depending on how you mix it. The programming to support this is absolutely trivial.

I can't think of a single game I've played that does this. Even games with dynamic sound like Shadow of the Colossus and God of War swap in one track for another at specific points in the sound loop, not really blending them. I suspect it took them far more effort from their Programming and Audio departments to achieve the same result that my student was able to do in about twenty minutes.

Has anyone else seen this technique before? Because once you've seen it, it seems like a really obvious thing to do...

Culture Shock: Textbook Writing

As a student, I never really gave a thought to where textbooks actually came from. The extent of my understanding was
Step 1: Professor says 'I have a Great Idea for a textbook'
Step 2: Then a Miracle Occurs...
Step 3: Profit.

Most people working in the game industry don't think about writing a textbook in their spare time. It never really enters our minds. It's not like textbook publishers come calling to remind us. And it's not like we have any spare time, anyway.

This cannot be said of academia. Textbook company reps actively court professors in a variety of ways, both to peddle their wares and to seek out any future book authors.

Through talking with one reps, I now know how textbooks get made, at least at one large publisher.
Step 1: Professor says 'I have a Great Idea for a textbook'. I didn't expect to get this part right! It's a little more involved, though; the professor submits some materials like a resume and proposed table of contents. The objective here is to show that there's a need for the book, and that you're the one who should write it.
Step 2: Marketing people at the publisher do market research to see if there's enough people who would want to buy the book. If not, begin negotiation to find something that the professor is qualified to write. Meanwhile, an Editor evaluates the resume to see if this is someone who has the basic skills required to write a book.
Step 3: Professor is asked for a sample, maybe one or two chapters. Publisher submits these to colleagues in the field -- other professors teaching relevant classes, for example. This lets the publisher know if the professor has a clue what he's talking about, and also whether the book would be remotely useful in classes. If not, publisher may ask for edits and try again, or may simply hold on to the idea and try again the following year.
Step 4: Publisher receives positive feedback from the sample chapters. Begin negotiations on the actual contract, payment schedule, milestones, etc. The entire process up to this point takes maybe two or three months, minimum.
Step 5: Write the book. That part usually takes one to two years, although it varies (of course). Then it's printed, marketed and shipped.

Emergent Design: Magnetic Whiteboards

A few days ago one of my students brought in a prototype for a game concept on a magnetic whiteboard. This has got to be one of the best prototyping tools I've ever seen. It has moveable parts -- custom magnets. Draw a stick figure, there's your avatar. Draw a straight line, now you've got a moveable platform for the avatar to stand on. Parts of the game that are static can be drawn in whiteboard marker, and erased / redrawn as needed. Parts that move are drawn on magnets, and you slide them around.

The particular model my student brought in also had cork board on the opposite side -- ideal for a pause screen or subscreen :-)

Yes, you can do this with post-it notes or index cards. But a magnetic whiteboard combines all of the best aspects of these in one prototyping tool.

And yet, I never had one of these when working for a game company, nor did anyone else who I worked with. It didn't even occur to us to go out and get one. So, to my game designer friends in the industry, I'd suggest going out and investing in one before your next project enters the concept phase.

Thank goodness for students with no industry experience; I don't know how we'd advance the field without them.

Final Exam, Second Season

In the Fall, I had a gameshow-like final exam in my Game Industry Survey class. I was happy with the results. Originally I planned to ask everyone two questions, but due to time constraints we only had time for one. This time I'll limit the number of buzz-in responses to make sure we don't get stuck on a single question for too long, so now there can be two questions for everyone.

This was my thinkinguntil someone pointed out the obvious to me: last time I had 16 students, this time I have 27. Oops.

I really don't want to have everyone's final exam grade come down to a single question. I'm thinking of adding a written section at the end, including some questions that everyone must answer. Maybe some essay questions (similar to Fall's "bonus questions" except that they're a part of the raw grade and not a bonus), plus perhaps some quick written fill-in-the-blanks (similar to Fall's "lightning round" except asked of everyone rather than just one person at a time). I don't particularly like this solution because it makes the exam more traditional, but I'm not sure what else to do at this point. Suggestions?

Emergent Design: Prisoner's Dilemma mods

Emergent gameplay is when complex (and often unexpected) behavior arises from the interaction between simple rules.

In class yesterday, I witnessed emergent game design: some students in the class managed to create some very interesting mechanics even though I had not planned that as part of the lesson.

We were talking about the Prisoner's Dilemma, one of the few things from the field of game theory that's actually relevant to making games. Prisoner's Dilemma isn't all that compelling as a game itself, but it often finds itself incorporated as a byproduct into larger social games.

A student offered this modification to make the basic game multiplayer:

• Each player has the same two choices: Cooperate or Defect. However, if you Defect, you also choose a target -- one of the other players.
• If you Cooperate, you get 2 months in jail.
• If you Defect, you only get 1 month in jail, but the target gets an extra 2 months. Cumulative.

Very simple, but I like it as a designer because it has some interesting properties. If you play selfishly, there's no reason to Cooperate; Defecting is better for you, personally, no matter what. However, the total number of months spent in jail among all players increases if you Defect, so in the big picture Defecting hurts everyone.

In practice, players found that opening with Cooperation (assuming multiple trials) was a good strategy; anyone who Defected on the first round made themselves a target for retribution on subsequent rounds. If you were the only Defector at the table on round one, you were pretty much going to get killed for the rest of the game.

An unexpected meta-strategy occurred: once you do start Defecting, it's better to keep your focus on the same person rather than spreading it around. You make fewer enemies that way, and increase the chances that you won't be in Last Place.

I didn't learn much about teaching from this exercise (except to respect my students' game design skills, which I already knew) but the game designer in me was fascinated.

Teaching a class the second time is different

The content for my Game Industry Survey class today was identical to what it was in the Fall.

On my Fall notes, I have in my own hastily-scribbled handwriting for Lecture #5: "I thought this would take a lot of time so I rushed through it, and ended up an hour short." This time, knowing better, I didn't bother rushing. I had plenty of time -- an extra hour in a two-hour class!

The students had other ideas. We got into a class discussion on ESRB ratings and the responsibility of retailers (and parents and legislators); and another discussion on whether rentals were good or bad for the industry as a whole, and how they changed the business decisions of what games got funded. Great stuff, and very much on topic, but neither of these topics were brought up by students in the Fall.

Between these debates and my relaxed pace we only had ten minutes left at the end to play Guitar Hero, and we never got to watch the awesome developer interviews on the disc (or look at the Accordion Hero website) -- I'll have to save those for next time. So much for relying on my notes from last time; the students are different, and therefore, so is the course!

Update on Grading Methods

A long time ago I was thinking about different ways to grade a class. For the intro class, Game Industry Survey, I ultimately decided on scoring out of 1,000,000 points -- it's more accessible, and any given assignment feels uplifting even if you only got 50% (which most students don't, since it's not supposed to be a difficult class). It served its purpose: it amused the class on the first day and set the stage for this being more about fun and learning than traditional skill-and-drill.

In the interest of science, I decided to use the Zelda Heart method for my Game Design Workshop-like class this Winter. The students are already (mostly) familiar with me as a teacher, they're ready to take a step towards being a game designer, so I wondered if they'd be more open to alternate grading styles. So far, the reaction is very positive; students chuckled when they saw a "life meter" on the last page of the syllabus, and they realized (without me having to point it out) that turning in assignments late amounted to "poison damage". So far this seems to be working... at least for an advanced class.

Flash as the ideal tool for student game development?

Flash seems to have an awful lot of things in its favor as a platform, from a student perspective:

• It's (relatively) easy to learn and work with, especially for non-programmers.
• It supports a lot of common game behavior (capturing mouse/keyboard input, drawing sprites, playing sounds and animations, collision detection) right out of the box.
• ActionScript is extremely expressive and powerful when you need it to be.
• Content management (art, animation, sound) is absolutely trivial.
• It's cross-platform, so it doesn't matter if some students prefer Macs and others use PCs.
• The end result is playable in a Web browser, making it a nice addition to a student's online website/resume.

The only down sides I see:

• It's definitely NOT priced for a student budget. But if the school already has some educational copies in their computer labs that are available for student use...
• If you're a programmer, you should really be using C++ (or maybe Java) since that's what pretty much everyone in the industry uses. Flash experience won't get you a C++ Programming job, or at least won't let you prove your C++ skills. This can be mitigated by providing other code samples, and using Flash simply to show that you can work on a project with students from other disciplines. And if you're anything other than a programmer, then this does demonstrate your technical ability.

Is there anything I'm missing here?

Innovation in Retro Gaming

Retro-style games are great for student projects because of their small scope of implementation, and necessary focus on gameplay. The down side is that all of those older genres have been done to death -- they've been around the longest, so they've had the most time to have every last drop of innovation squeezed out of them. Right?

And yet, this was the task set before my Capstone students: come up with something that can be done in twenty weeks with relatively little programming.

They came up with a surprising revelation: one particular genre, the 2D platformer, still has a lot of life left in it because of a curious property: every successful game takes the basic platformer mechanics and adds just one or two "gimmicks", so all you have to do is choose a gimmick that hasn't been done before. And I think they're right, looking at successful platformer franchises and their gimmicks:

• Mario = hidden stuff
• Sonic = go really fast
• Castlevania = short-range attack with whip
• Pitfall!, Prince of Persia, Impossible Mission = time limit to complete the entire game
• Metroid, Blaster Master = explore a huge map, gaining access to new areas as you get more powerups
• Mega Man = choose the order of stages, earn boss's weapons
• Incredible Machine, Lemmings = build and/or destroy the platforms as you go

There are some interesting ideas there, but really, they don't even scratch the surface of what's possible. There's a lot of room for new gimmicks that haven't been explored yet, which is why we're still seeing new 2D platformers in this day and age:

• Gish = blob physics
• LocoRoco = rotation and gravity
• Braid = time reversal

So, it would seem this is a promising direction for aspiring game developers who want to create something interesting on a student's schedule/budget.

What I've Learned So Far

Just taking stock of a few things I've noticed now that Fall is over and Winter is starting...

College students are very excited about the concept of taking a course about video games. However, getting the word out to students outside your department is really hard.

If you're introducing new courses to a curriculum, start at the most basic level and build up. If you have the opportunity to teach an upper-level Special Topics class in something that you (as a teacher) are passionate about, but it requires some background material that the students might not have yet... Just Say No. Or rather, Just Say Yes But Next Year! Don't be afraid that this year's graduating students will "miss out" -- if they can only take one course, it's better for most seniors to leave with a 100-level "intro to the industry" course that points them in the right direction, anyway.

For every homework that you assign, ask yourself: how long will it take me to grade this? Is there some way I can have students do the same kind of work, but that's easier to grade? That said, students seem to appreciate if you take the extra time to give them meaningful, personalized feedback on their assignments.

If you make yourself available to chat with students a few minutes before and after each class, don't expect any visits during your office hours.

Keep soft copies of everything you do for a class, and keep it all organized as you go. Keep it in one central location, ideally a thumb drive or laptop -- if some of your notes are at school and others at home (or worse, the same notes are in both places but one is a more up-to-date version) it's a nightmare to sort out.

Teaching: Grading an Interdisciplinary Class

One of my upcoming classes basically amounts to a group of students working together in a team to make a game. I expect them to have some great experiences, and the classroom is a much better place than the first industry job to make some serious beginner mistakes. So, I'm really excited about this one.

Then there's the question of grading. If I have a programmer, a couple of designers, a producer, an artist, maybe a sound guy, all working on different aspects of the same project... how do I grade them?

So far, I've come up with several possible methods:

1) The "I know it when I see it" method. No quantitative grading at all, I just assign whatever grade I feel the student deserves. While this would probably give the grades that are the most in line with what students have done, it's a terrible stress on the students themselves, and it puts a lot of burden on me to Get It Right. And if a student complains that they got an unfair grade, I have no defense.

2) The project-based method. I grade the final project, not the individual students. Everyone gets exactly the same grade. I don't like this, because it doesn't allow for variation in student abilities.

3) The discipline-based method. I grade the programming on the final project, and anyone who was a Programmer gets that grade. I do the same with design, art, audio and production. Everyone gets graded on their own work... except that you quickly realize that everyone's work affects everyone else. Maybe the game has a brilliant design, but it just can't be implemented by the programmer(s) in the amount of time we have; this is an issue with design and programming and production, so who gets a lower grade?

4) The method I'd like to try is a hybrid between project and discipline. I grade the final project on its various aspects, and each student gets a different weighting of those aspects based on their role:

• Programmers: 40% programming, 5% design, 10% art, 10% audio, 15% production.
• Designers: 15% programming, 40% design, 5% art, 5% audio, 15% production.
• Artists: 5% programming, 10% design, 40% art, 10% audio, 15% production.
• Audio: 10% programming, 5% design, 10% art, 40% audio, 15% production.
• Producers: 15% programming, 10% design, 10% art, 5% audio, 40% production.
• Everyone also has 20% class participation. Class time is roughly the equivalent of team meetings, and not showing up for work is obviously bad.

Where the five categories are roughly defined as:

• Programming: does the game work? How buggy is it?
• Design: is the game fun?
• Art: does the game look good?
• Audio: does the game sound good?
• Production: did the game get finished on time with all of the intended features?

I'm hoping to impress on the students that their work affects the rest of the team, and the rest of the team's work affects them, and that in the industry they're ultimately "graded" on the sales of the final game above all else.

Culture Shock: Iterative Design is not Iterative Design

When designing a game, most people at least give lip service to the concept of iteration: that is, no one gets it right on the first try, EVER, so build some time into your schedule to make major changes that you'll find along the way. It's the game developer version of the saying from engineering, "build one to throw away". I'm sure other fields have their own jargon for essentially the same thing.

Of course, with games (especially for console), once you ship your game you're done. No more iteration for you! If you're lucky and the original game is Good Enough, you might be able to improve some things in the sequel... but you can never go back and actually change the first one. "Remakes" of old games are incredibly rare.

Designing a class is just the opposite. I taught Game Industry Survey once already, and I'll teach it again two more times this year. Each time, I get to look at the results from previous classes and iterate on the design, improving weak points, tweaking the grading system, updating the content, and generally making the whole thing better. And I get to do this again and again, with fresh students each time who don't have any previous experience with earlier versions.

This property of classes encourages risk-taking. I can do something crazy like make each homework worth a hundred thousand points, and if it doesn't work then I can just apologize to the current class and change it next time around. It's quite a different environment from the risk-averse environment of the game industry, and the only thing that changes is that I get to redo my work after it "ships".

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Winter Break is a Hoax

With only one week between the Winter and Spring quarters, I effectively need to prepare for all of my Winter and Spring classes right now. This involves two brand-new classes, plus the administrative details of the classes I'm repeating (like changing the dates on the syllabus). I also have some short-term industry contract work, and some game-related R&D that I'm supposed to be doing at home.

So far, I've been about as busy as I was during Fall.

I always thought that whole "22 weeks of paid vacation per year" thing sounded too good to be true...

Fast Group Board/Card Games

One of my courses this Winter will focus on the rapid design of game concepts. While most of the games will be digital in nature, I think it's important to have at least some grounding in physical card and board games, as the boardgame industry has permanent ties to the video games (for several reasons).

One project I'd like to do will involve eurogames, and in particular I'd like to demonstrate a number of these games in class. Ideal games can be played with a large number of people (6+ "players", with the ability for several people to play as a single team), have simple rules that can be explained in a minute or two, have a total playing time of 15-30 minutes or less (although for games with multiple rounds, 15 minutes or less per round is acceptable), and can be played without specialized components (in case I don't actually own it in my collection and can't find a copy in time). Oh, and it should be fun, at least for the first few times.

So far I've come up with 6 Nimmt, Diamant, Circus Flohcati and Tutankhamen. If anyone has other suggestions, please post a comment here. Thanks!

Teaching: Groups of Three

With my first set of courses done, I'm looking ahead to the next set. One course in particular offers an interesting challenge.

The course is basically a set of game design exercises, meant for small groups (three or four; I think five would be excessive). Each exercise would go something like this:
Tuesday in class: We play a game or set of games, and analyze them from a game design perspective. The choice of games is relevant to what we'll be doing for the project.
Tuesday-Thursday, homework: Students perform some kind of preliminary market analysis that will be relevant to the project, so they won't be starting from square one. For example, if they'll be designing a game to fit a license, this is where they'd take a look at the license.
Thursday in class: Project is assigned. Groups brainstorm ideas together, and submit their best idea at the end of class.
Thursday-Tuesday, homework: Groups take their best idea and flesh it out into a full concept (one or two pages). Something that would be presentable at a business meeting.

Now, the obvious problem here is that it's an awful lot of work outside of class.

Here's what I'd like to do: delegate the homeworks to one person in each group, and rotate it around. With groups of three students each, and nine projects total in the course, that means each student would have a total of six homeworks, none more than a page or two. Much more manageable.

But what do I do if the number of students isn't divisible by 3?

Culture Shock: Class Post-Mortems

In the game industry, it's traditional to do a post-mortem at the end of a project: everyone on the development team sits down and tries to identify what went right and what went wrong, as a way of avoiding past mistakes on future projects. I wanted to bring that same spirit to my classes, particularly the one that I'll be teaching again immediately after winter break.

Now, in both cases, brutal honesty is hard to come by. If you're working on a development team, your desire to be honest for the good of the company is tempered by your desire to not tell your boss why he sucks. Likewise, it's hard for students to tell a professor why his class sucks if he hasn't yet submitted final grades. So that much, I'm used to.

That said, there's a self-selection bias that exists in a classroom but not in industry. That is, at a game company everyone on the team shows up for the post-mortem, because it's part of their job and they're getting paid for it, so the people who got burned on the project will be there as advocates for change. After a class is over, the students who hated the experience are going to leave as soon as possible; they don't want to stick around for a post-mortem. The only students who remain will be the ones who were already loving the class and don't want it to end, so any comments will be skewed very positive. Meanwhile, the students who struggled and had real issues won't be there to let me know, so I'm likely to repeat my mistakes by catering to a certain breed of student while possibly alienating others. (Don't get me wrong. The students who participated made some great suggestions that I'm going to implement next time around; I just want more information from a wider range of perspectives, because that tends to lead to more surprises.)

I suppose that's what the student course evaluations are for, but I don't really trust those either. Many students don't take them seriously and will comment more on the professor's hair style than teaching ability; also, it doesn't give me the ability to ask targeted questions ("what do you think about Homework #4?") so the comments may be too general. Oh, and I had my evaluations done about two-thirds of the way through the course, so anything that happened in the last third won't be represented on the evals.

I was thinking of perhaps using class time to conduct a post-mortem, as a way of forcing the issue, but then I'd have to remove something else -- so I'd be cheating my current students out of valuable class time, in order to benefit the students next quarter. Not really fair.

Any other ideas of how I might get honest feedback from all my students -- both the ones that love the course, AND the ones that hate it?

Final is done!

Overall, it went very well, and I'll definitely consider this style of game-demo-exam in future classes. Things I learned, in no particular order:

• I'm not exactly a whiz with video cameras. Even though the final was taped, I have no idea if it recorded sound, or even if it recorded at all, so it's a good thing I wrote everything down as I went.
• Preparation is key, and I didn't do enough of it. In particular, I forgot to make sure there was a PS2 in the room, so I had to take a short recess in order to hunt one down and connect it. Time was very short, and delays like this were deadly.
• Students were absolutely terrified going into the exam; this comes from the prospect of being asked only two or three direct questions, and what if I draw a total blank? As soon as we started, everyone was much more at ease -- it felt a lot like the discussions we've had in class all along -- and I think many of them forgot they were even taking an exam :)
• Students had a tendency to repeat each others' answers, weighing in with their opinion, apparently forgetting that I was only asking for NEW information. These took up a lot of time, particularly on open-ended questions in which everyone had an opinion they wanted to share. I need a new rule to prevent getting bogged down on a single question; I'm considering limiting the "buzz-in" responses to something like three per question instead of unlimited.
• I realized when I had asked a single round of questions that we were about an hour and a half into a two-hour exam, and decided on the fly to go immediately to the "lightning round", and then ask some bonus questions (individually written responses on index cards) with whatever time we had left. This ended up being a reasonable way to deal with time pressure. Unfortunately, it did mean that there was more of a focus on older games (and more class lecture, less reading and terminology) than I'd have liked.
• This really only works with a very small class (<20),>
• Ask the most interesting and thought-provoking questions first, so students can get into the spirit of the exam and really start paying attention. Save the most fun, entertaining questions for last, so students will leave the exam (and the course) on a positive note.
• It helped to talk like a gameshow host, referring to students as "players" or "contestants", asking for a round of applause for our sponsors, and having parting gifts. First because it sounds so ridiculous that it really removes tension, second because it makes the video camera in the room feel more natural.
  

Marble Sadness

There are times in your life when you realize that it's nearly impossible to share some experiences of your youth with the next generation.

Those kids who saw the Star Wars movies starting with Episode I (instead of IV like the rest of us) will never be able to experience that shock of finally realizing, after all of the conflict, that Vader is actually Luke's father. You just can't un-see the new trilogy to experience the old trilogy with a clean slate.

Similarly, a couple of weeks ago I found (to my surprise) that most of my students had heard of Marble Madness, a wonderful arcade game first released around the time that today's college students were just being born. Why? Because the game has been ported to just about every console machine Atari could get its hands on. My students haven't seen an arcade model (many didn't even know it was an arcade game), but they've seen the NES version.

This is a shame, because there has never been (to my knowledge) a decent port of this game to a home system. The great thing about this game is its play control: you roll this heavy trackball and your marble on the screen moves in the same way. Converting it to a d-pad control simply doesn't work, because it removes that visceral rolling that forms the core of the game; it's like playing a dance/rhythm game with the sound turned off.

So, all of these kids today think of Marble Madness as this mediocre race game for console with lousy play control, not as a perfectly wonderful arcade game with the curse of never surviving a port intact. And that makes me sad.

Teaching Backwards

Due to low enrollment in one of my Winter courses, the focus of the course has changed to something completely different. This happened all of a sudden at the very end of classes this quarter, so it's a bit unsettling.

I'm excited about the content though. This will be a pure design course, with no art or programming to get in the way. It's project-based: students will work (probably in groups) on a set of exercises. I'll cover some physical card and board games, and some paper designs (and project proposals) for digital games. I plan to keep the students on their toes by offering them interesting sets of constraints; I did this before on a semi-regular basis at Hi-Score, so expanding that into a full class shouldn't be too hard.

Here's the strange thing, though. This Fall, I taught a course about rapid prototyping and iterative design, from a technical game design perspective; this was a course where students were expected to actually implement their ideas, sometimes doing some light programming or scripting in the process. It's a pretty advanced course for undergraduates.
Meanwhile, this Winter I'll be teaching a practical game design class. And this Spring I'll teach a game design class that covers the theoretical foundations of the field.

Through a set of circumstances outside of curricular matters, I'll teach these courses in the reverse order that students should be taking them!

Lesson learned: next time I'm introducing a new set of courses to an existing curriculum, offer the lower-level ones with fewer prerequisites first.

Culture Shock: Going Independent

Occasionally, a jaded game developer gets fed up with harsh industry practices and decides to strike out on their own, starting their own game company to make their own games. This usually involves moving to a cheaper apartment and eating ramen for awhile.

And occasionally, I'd imagine a jaded university researcher gets fed up with stuffy academic bureaucracy and decides to strike out on their own, doing research as a commercial venture. This also involves ramen, unless they manage to secure a grant first.

If a teacher decides they've had enough of the system, though, there's not much they can really do. Tutoring, maybe, but it's not really the same. I suppose it's because academic programs are accredited; you could start your own university, but it takes millions of dollars, and there's no easy way to do it "on the cheap" that I can tell.

Not that I'm looking to do any of this, mind you. It's just one of those differences I noticed the other day.

Final exam rules are finalized

Just finished writing up the rules for the interactive final. I'll hand them out in class Monday, but you get to see them here first!

• Students get assigned a unique random number from 1 to 17 (there are 17 students in the class). Randomizing prevents anyone from arguing that I intentionally gave them harder questions, or that they got screwed by sitting next to the wrong people.
• Starting with #1 and incrementing, each student is asked a question. (Most questions will be about a particular game that I'm demoing at the time). The student gives their best answer. Answers are scored as a normal test question.
• After the student in the "hotseat" is done, anyone else may raise their hand to elaborate or disagree. If several students want to chime in at once, start at #17 and decrement. (In this way, a particularly bright student who keeps completing everyone else's answers can't keep control of the spotlight -- once they answer out of turn, everyone else gets a shot before they can try again.)
  
• For those parts of the answer that the student elaborates on correctly, they split the points with the "hotseat" person, 50/50. In this way, the final is collaborative; even if you don't answer your own question fully, you can reclaim some of those points with help from other students. At the same time, students who answer other people's questions can get above 100% on the final. I expect this to have interesting ramifications on students' study strategies...
• For those parts of the answer that the student elaborates on incorrectly, they lose a quarter of the full points (i.e. half of what they would have been entitled to). This is to discourage random guessing. Educated guesses are encouraged (I hope), since it's a 2-to-1 ratio of gains to losses.
• If a student doesn't show up for the final at all, the questions that would have been theirs instead become bonus questions for the group. Everyone gets to answer on an index card, with points given (or taken away) as if they had answered out of turn. Students can choose to only answer partially, or not answer at all.

Time permitting, I'd like to add a "lightning round" at the end, quiz-show style: rapid-fire questions, all with very simple, clear answers, directed at each student in turn, with no answering out of turn. This will be the ideal place for those little tidbits of information that I want everyone to know about the industry, but that can't be demonstrated easily by playing a game.

The final is 2 hours long, which is frighteningly short if I'm asking even just two questions per student (it comes out to about 4 minutes per question on average, including time for me to ask the question, time for the student to answer and time for other students to chime in out of turn). Not sure what I'll do if I run out of time; I'll definitely be practicing everything ahead of time to make sure that I can breeze through my own parts, at least.

So, that's what I've got right now. I'd love to hear your comments.

Teaching: Oh yeah, study sheets!

One of my classes has a final exam. I was planning on actually designing the thing next week, since there's a solid week between the last lecture and the date of the final and I'll have nothing else to do in that time.

Until then, I was planning on working hard to get the last of the grading done, so students will know their grade going into the final. I always liked that as a student, being able to compute exactly how well I need to do on the final to get what grade. I'd like to do that for my students. But I don't really have time to do that AND come up with all of the questions for the final exam.

But then I realized I should really give out study sheets for the final exam (I'm ashamed that I had to be reminded of this by a student). But in order for those sheets to be accurate, I have to know the content of the final...

So, I either have to keep students in the dark about their grades, or keep them in the dark about the final exam, or take a guess of what content I'm going to test on the exam and then try to stick to that. I'll probably do the latter.

Now I know why in some classes, the study sheet would bear no resemblance to the actual content of the final... it's because the final wasn't written until after class was over!

Elementary Schools

Sometimes, just when I feel like I'm too old to be in touch with my students, they surprise me.

Today they surprised me by recognizing Math Blaster, Number Munchers, Carmen Sandiego and Oregon Trail from their own early childhoods. (This is, like, ten years after MY early childhood when I experienced these games.)

So, apparently the classics never die. Or maybe elementary schools are just hopelessly behind on the technology curve. Or maybe we just haven't had any decent educational games in the past ten years. Either way, it means something.