IGF Student Games

One last bit from GDC was the IGF Student Games roundtable. I was sad to see that the room was almost all students, no faculty. There were three IGF judges there, including one who judged student entries, and their advice was invaluable.

If you're a student creating a game, you should be thinking about making it worthy to submit in the IGF when you finish it. If you're a professor running a project-based class where students make a game, you should be thinking about encouraging your students to make it worthy to submit to the IGF. Any student team that becomes a Student Showcase winner gets some media exposure, and will therefore have a much easier time finding jobs in the industry.

My notes from the session, on how to make your student game project as competitive as possible:

• IGF student games should not be full productions. You only get about 5 seconds to hook a judge, and even then they’ll only have time to play your game for about 10 minutes.
• Consider your game as a “Demo”: Get to the “meat” (fun) of the game instantly… within 5 seconds; easy install/config helps a lot; about three good, well-defined levels will give about 10 minutes of gameplay.
• This year there were 108 submissions, 10 Student Showcase winners, and one grand-prize winner. “Don’t enter to be the William Hung of the IGF.” Only enter a game that you think can really compete. All of your first-semester individual student projects should not be entered by rote (although some of them may be good enough to enter). Generally, your game should be a good game.
• Include an automatic Install, and Uninstall. Judges don’t appreciate random stuff that’s stuck on their personal computers. There are plenty of free install apps; use any of them.
• For long-term student projects, you can still submit a project even if some of the original team has graduated. In fact, graduates can still work on the game, as long as they don’t get paid for their effort.
• Judges repeatedly used the word “polish” to describe what they’re looking for in a game, but were clear that this isn’t just about expensive production values. Game should be a complete experience. It shouldn’t feel like there are unfinished features. (Missing levels, sure, but not missing functionality.) Game design should clearly have undergone iteration. It should be fun. Game interface should also be iterated on. Does the game give good feedback? Is the UI “juicy”? Does the game train you to play it?
• Students would do well to check out the non-finalist games of the previous year to see what didn’t win. Decide for yourself why they didn’t win, and make sure your game doesn’t fall into the same trap.
• Focus test your game. A lot. When doing this, don’t tell people how to play it; just sit them down and see if they can figure it out. You learn a lot from watching people struggle, in particular with what player expectations are. One memorable quote from a student team: “We thought everyone was playing our game wrong; then we realized they were playing it right, and we made the game wrong!” It occurs to me that this is good advice for any development team, not just students.
• Make your game single-player (or, if it must be multiplayer, include a one-player version). It’s hard for judges to coordinate to play a multiplayer-only game. Memorable quote: “A multiplayer game is just another person doing the AI for you.”

Common mistakes for student games that keep them out of the top ten:

• Bugs/crashes, art issues, or other obvious flaws (of course).
• Accessibility: what’s happening when you start the game? Does the player have any idea what they’re doing, what the controls are or how the game works?
• Language issues: use clear English in your instructions (this is mostly a problem with foreign teams).
• No gameplay, just walking around in an empty level. No matter how brilliant your game engine is, you need to create at least some content to show it off.
• If the game is clearly in a genre, make it immediately obvious what makes your game different. The judge should not say “great… not another undifferentiated FPS/side-scroller/whatever”.
• Too difficult. Some games are supposed to be difficult and that’s fine, but don’t kill off the judge before they get to the fun part.

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.

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?

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.

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.

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!