Wednesday, August 30, 2006

Culture Shock: Meetings

In the game industry, everyone is keenly aware of just how far behind schedule the project is, and it's (usually) recognized that meetings can burn a huge number of man-hours in a very short period of time, so when people call a meeting they tend to get right to the point. People are in the room to find a specific solution to a specific problem, and then to document the solution and the reason behind it so that they don't forget later. Meetings in practice often fall short of this ideal, but we try.

During a meeting, everyone may have their own ideas and their own agenda, but they are entirely forthcoming. Creative disputes (sometimes involving voices raised in passion) are expected from time to time. Everyone cares deeply about making the best game possible, which means no one is going to hide their idea and keep quiet just to "not rock the boat".

In academia, meetings feel a lot different. There is not necessarily the same time pressure (you're certainly not going to have a whole group of people laid off just because their project is behind, since half of the people you're dealing with have tenure), so the atmosphere is more relaxed and reserved. There is more competition between individuals and less overlap, and there is a lot more concern about making sure no one else in the room is offended, so people tend to be less forthcoming with their ideas and they're much more subtle about pushing their own agenda on the group. As such, brainstorming effectively is much harder.

Bonus culture shock of the day: specific to the institution where I'm teaching, students add classes by filling out a "pink slip" (this is what they are called) and having the instructor sign it. I have to question the wisdom of whoever thought it would be a great idea to subconsciously train their students to energetically ask their superiors for a pink slip...

Sunday, August 27, 2006

Culture Shock: Homework Design

One thing I never appreciated as a student was that, no matter how heinous the work I was assigned in class, the professor had to do even more work than I did. If I'd thought about it at the time, I never would have complained about my workload, ever.

For one, the professor has to actually do the assignment, same as the students. It's much like beta testing -- gotta make sure the assignment actually works, that it isn't too advanced or too time-consuming. It's also useful for having an "A"-level standard to use while grading (assuming you could get an A in the course you're teaching :-).

Of course, before testing the assignment, the professor has to actually design the thing. And afterwards the professor has to grade all of them. And during the assignment period the professor will be fielding questions about the assignment during office hours.

At least, that's what it's looking like to me so far. Maybe I'll discover a shortcut later.

Thursday, August 24, 2006

Game Design Curriculum: Elective Minors

The sad fact is, almost no one gets a game design job immediately on graduation. Most people enter the industry as a programmer, an artist, or a software tester. The reason for this, I think, is that those positions are inherently low risk: a programmer or artist who screws up their entry-level work is probably not going to sink the entire multimillion-dollar project; another programmer or artist will clean up the mess and no one else will notice. (A tester, by definition, can at worst do nothing.)

But a designer's job is, essentially, to tell the programmers and artists what to do. Design mistakes don't just require another designer to make repairs, but also programmers and artists to redo their work. Design mistakes bleed across departments, so companies tend to be very careful of who they hire in those positions.

As such, anyone interested in game design should also minor in Computer Science, Art, Business, Marketing, or some other discipline that is directly related to game development. This gives you three ways to enter the industry: game design (unlikely), QA (easier to find, but tedious and boring to most people), and whatever you minored in. Understanding multiple disciplines also makes you marginally more attractive to a game company (especially a small one), since you can fill more than just one role and you're more likely to communicate well with people in different departments.

Additionally, take a second minor in something that has nothing at all to do with games. Game designers need to foster a lifelong passion for learning (just look at all the crazy stuff that Will Wright or Sid Meier knows – the stuff that has nothing to do with games – like astrobiology or world history). I know, I know… most educational institutions do their best to squash the love of learning out of every last student. That makes it all the more important to reverse the trend in college, by studying in-depth something that really interests you. It could be anything; astronomy, art history, classics, Shakespeare, French, quantum physics, whatever. There are many reasons why this will help you. First, it will set you apart from others by giving you unique interests. Second, it demonstrates your all-important love of learning. Third, it gives you a small, random chance to be a perfect fit on any given dev team (example: if you minored in abnormal psych and unbeknownst to you, the company you’re applying to happens to be in negotiations on a game with a paranoid schizophrenic as the main character…).

Two minors? Sounds crazy, but in a field with practically no entry-level positions open to new graduates I consider it a necessity.

Monday, August 21, 2006

Topic for Discussion: Game Research

If half of being a faculty is teaching, the other half is performing research.

Game Studies research is pretty straightforward in terms of how to approach it; it's similar to other cultural and anthropological studies, where you conduct interviews and observe player reactions to games and analyze demographic tables and such, and then you find the correlations.

Game Design isn't like that. Yes, some researchers conduct studies that try to quantify "fun", in the same way that economists might try to quantify "utility" or psychologists quantifying the exact definition of various disorders.

But look at cinema. Is anyone writing research papers on the crafting of an audience reaction, or the correlation of fun to car chase scenes, or creating emotional tension in the viewer? These kinds of things are artistic, creative and highly subjective; they don't lend themselves well to number-crunching quantitative research.

Instead, the academic side of film creation concentrates on, well, creation. Students make their own experimental films and showcase them.

Should game design research be the same way? Shouldn't we be making experimental games, using mechanics or themes that haven't been used before? If we must, we can always write an academic-style paper about the game we made, that talks about the design intent and observed player reactions.

And yet, I haven't seen anything like that coming from academic researchers. Grad students, yes, but not faculty. Am I barking up the wrong tree here, or is this a direction that game research should be heading in? Or has it already, and I'm missing out on a lot of experimental games out there?

Thursday, August 17, 2006

Culture Shock: Mommy, Where Does Funding Come From?

In the game industry, funding models are pretty straightforward. If you're a third-party developer, you get your original game project as finished as your startup funds permit and then shop it around to publishers; or you respond to publisher RFP's. If you're established enough, publishers come to you instead. Wash, rinse, repeat until one of two things happen: you go too long without getting a new contract and you go out of business; or you generate a massive hit that gives you royalties, letting you self-fund your next project.

In academia, things are different because there are so many funding sources. For public institutions, you have state (and maybe federal) funds. There's alumni donors. There's tuition, of course. Then you've got grant funding from large organizations (e.g. NIH, DoD, NSF -- at least in the States), and from private foundations. Oh, and there's the occasional research project that gets commercialized and generates revenue to the school through royalties. And it's some combination of all of these that pay your salary as a teacher.

To complicate things further, these sources don't exist in a vacuum; they affect each other. For example, you get more state funds if you increase your enrollment, which also increases your tuition revenue (but also your costs to support the extra students, which may wipe out your gains). You also get more state funds (at least here in Ohio) based on the number of patents you generate, which also means increased commercial revenue. You increase alumni donorship by getting your university in the news because you just published some really important piece of research, which may or may not have been funded by grants. Deciding where to put your resources and where to chase additional funding is a huge balancing act.

And that's all ignoring university athletics; I don't even want to think about the complexities of that.

Back when I was a student, I thought that the whole point of universities was to teach their students. But then I also thought that the point of working at a game company is to make the kinds of games you want to play yourself. In both cases that may be the Dream, but everyone has to deal with the reality of where their next paycheck is coming from, first.

Sunday, August 13, 2006

Game Design Curriculum: Other Stuff

There are a few other assorted courses that I've found useful in the field.

Communication. No matter how good your high-level designs are, you must communicate your vision to the rest of the team. Having solid communication skills is one of the most important aspects of being a designer. If your school has a class in active listening, take that too -- designers tend to receive lots of feedback from their team (mostly on how much their design sucks :-), and being able to listen effectively and deduce the real design problems from someone who isn't a designer is a great skill to have.
Microeconomics. Really, anyone that wants to work for a company of any sort should understand the basics of supply and demand. Like it or not, game companies are businesses and they therefore need to make money if you want to continue receiving a paycheck. This course will prevent you from saying embarassing things in company meetings, like “we should make our game engine open-source and stop charging people for it, we'd get more players then.”
Women’s Studies. Currently, the game industry is really terrible at dealing with women. First, it’s lousy at attracting women to the industry; the average game company is about 10% women, and it’s even worse if you just look at game designers. Second, it’s not so great at marketing to women; the number of female gamers is growing, yes, but if you look at game ads and game magazines (and some games, too) you still see chainmail bikinis and the like. Game developers (especially male ones) need to understand some fundamental truths about women if we ever want to make them feel welcome. I sincerely hope that some day, this problem will be fixed and I’ll be able to remove this course from my proposed game design curriculum.

Thursday, August 10, 2006

Topic for Discussion: Money, Grades, High Scores

Darius pointed out to me yesterday that giving grades to students is a lot like giving incentive pay to workers. The ever-eloquent Joel "On Software" Spolsky has recently (and not-so-recently) written about why incentive pay is bad. In short, it insults the worker by implying that they're only trying to do a good job because they want the money (rather than the more powerful incentive of taking pride in their work and genuinely wanting to do a quality job for its own sake), and it also encourages workers to "game the system" to get more pay while actually doing a less optimal job in the process.

Let's suppose that both Darius and Joel are correct. What are the implications for teaching, if the necessity of giving grades takes the students' focus away from the theoretical goal of actually learning something?

In part, this is why I'd like to make my grading system playful. By doing something mildly ridiculous, I'd like students to forget about the grades and concentrate more on the class itself. (I realize I'm running the risk of having students focus more on grades since the system is novel. I'll let you know how it goes.)

I'll take this a step further and tie the discussion to games. In the early days when video arcades roamed the earth, every game had a scoring system and a high score list. But did we actually play the games to get on the high score list, or did we play because they were fun? Did high scores actually make the games less satisfying, by implying that we were just playing for the score, rather than the sheer joy of shooting countless waves of aliens?

I'm not sure if that's the case or not, but games have definitely moved away from scorekeeping over the last decade. (Of the ten games I'm playing right now, only one of them has any kind of scoring system.) The focus nowadays is usually on "beating the game", and even then the player is often encouraged to go back and do it again with a higher level of mastery -- time attacks, higher difficulty modes, hidden secrets, unlockables, and so on. Essentially, games have evolved from letter grades to pass/fail... with the option to do extra work to earn honors credit!

I feel like there's some universal connection here that's just beyond my grasp, something that suggests a better way to evaluate classes than the standard grading system. Any thoughts?

Tuesday, August 08, 2006

Culture Shock: Industry Jargon

When talking about game development disciplines (programming, game design, art, sound, production, QA), one thing I've noticed is that the industry vocabulary has not been adopted by most academics.

At GDC, there were a number of times when I introduced myself as a game designer and was immediately asked "so, what language do you program in?" Well, I happen to be a C++ man, but that's beside the point -- design is not programming. I would advise any developer applying for a professorship to explain game development and their specific role during their job interview, just so everyone is clear on your experience and area of expertise.

Here's another example: one of the courses I'm teaching this fall is called Game Development. Game developers will look at me in horror for this; the field is so broad and interdisciplinary that it's impossible to teach in a single course. You would need a twelve-semester sequence to cover everything. If all you have is a single class, you'd need it to be so abstract that it's functionally useless. A course in game development would make about as much sense as a course called Science or a course in Art.

As it turns out, this particular course is about how to build game prototypes. We'll start with paper and work our way up to digital prototyping. The focus will be on expressing and communicating ideas -- as efficiently and cheaply as possible -- through the medium of game prototypes.

So, in a sense it is a class in game development, as students will be one-person dev teams on small game projects. But no one in the industry is likely to know that from the name. In future years, I hope to rename the class to "Digital Game Prototyping" or something similar.

Sunday, August 06, 2006

Culture Shock: Writing a Syllabus

I never gave much thought to the syllabi I received on the first day of every college class. I just assumed the Syllabus Faerie created them all on the day before the semester started.

Now, for some well-established classes where the content doesn't change much, I'm sure a new professor is handed the old syllabus as a starting point, but when teaching a brand-new class it's something one has to create from scratch. And when that class is game-related, you probably won't find that many similar classes to draw inspiration from.

Having never written one of these before, I was a bit nervous. But now I'm feeling much better about it, because I found a way to bring the art of syllabus-writing into my field of expertise using two models:

Syllabus as Developer/Publisher Contract. In a way, a syllabus is a contract between the professor and the students. Both syllabus and game development contract spell out timelines and development goals and a description of the end-user experience. The contract is agreed to by both parties (in this case, the students "agree" by not dropping the course, analogous to a publisher not canceling the project). And the contract is a living document, open to negotiation if all parties agree partway through that it just isn't working in some area.

Syllabus as Game Design Document. A design doc describes in great detail what the game will do and how it will work, down to the core mechanics. A syllabus describes in equally great detail what the class will involve, how it will work, and what are the grading mechanics. Again, both documents are subject to iteration during the course of the project; in particular, game features (lecture topics) tend to get added or cut later on in the project (course) when there is more or less time than needed in the schedule (semester).

Culture Shock

One of the things I wanted to do with this blog was describe those areas of academia that were particularly surprising to me for one reason or another. I've spent most of my professional life in industry, so I have a bit of an outsider's viewpoint of the academic world.

These posts will be meant primarily for those of you in the game industry who are curious about what it's like on the other side. Students may also gain an appreciation for what their professors go through (we really are normal people, just like you, honest).

Experienced professors will probably look at these and either find them blindingly obvious or hopelessly naive. That is, more or less, the point :-)

Thursday, August 03, 2006

Game Design Curriculum: Computer Science

If we accept that learning art will help you to communicate with artists, then learning some computer science should help you communicate with programmers.

Intro to Programming. Some aspects of game design are pretty technical; if game data or rules are stored in a scripting language (either a commercial one like Python or Lua, or a proprietary one) then it is often expected that a designer will be creating content in those languages, which requires at least some fundamental knowledge of programming. Since you do want a solid foundation, take the course for CS majors if they'll let you.
Data Structures and Algorithms. I don’t feel that a single, introductory programming course is enough to truly understand how to convert ideas into code. A course dedicated to algorithms will give you a better idea of how that’s done, and a course dedicated to data structures will give you some tools that’ll make certain problems much easier.