Wednesday, February 27, 2008
I've been quoted
Brenda writes an interesting piece for The Escapist on how game design is frighteningly similar to game play. A quote from me appears in the sidebar on page 2. I assume this doesn't count as an academic publication, but thankfully I'm not in a "publish or perish" environment.
Tuesday, February 26, 2008
Note to schools: Remove obstacles!
One thing that came across loud and clear to me at GDC is that there are many developers who would like to teach, but they don't know where to begin... and there are many schools who would like to hire people with industry experience to teach their classes, but every time they try to recruit they don't get any applicants. This is strange. What's going on here?
The solution to this mystery lies in the obstacles that prevent developers from applying. Here are some examples:
The solution to this mystery lies in the obstacles that prevent developers from applying. Here are some examples:
- Accreditation boards require that all professors must have a terminal degree.
- All applications must go through Human Resources. HR writes the job description and also screens applicants, even though they don't know the first thing about game development.
- The school is located in a place where there are no professional game developers anywhere nearby.
There are plenty of schools that have found ways to remove these obstacles, and they are the ones who have no problems filling faculty positions. There are other schools that throw up their hands, assuming that these are just forces of nature that can't be worked around, and then they complain that they can't find anyone qualified to teach their classes. If you are at a school where you just can't seem to attract experienced people to teach there, I'm here to tell you that these problems are not insurmoutable if you are sufficiently dedicated. Here are some examples:
Accreditation:
- Talk to your accreditation board to see if any exceptions can be made. Game development (especially game design) is a field where terminal degrees don't exist, so finding someone who is both educated and knows what they're talking about is effectively impossible. See if it's possible to substitute experience for formal education in specific cases.
- Some accreditation requirements don't force all faculty to hold terminal degrees, just a certain percentage. Hire industry people into departments that are already above the threshold.
- Accreditation requirements may not apply to certain kinds of positions, like adjuncts or visiting faculty. (I ran into one developer who has happily been a full-time "visiting" professor for the last four years.)
- Some schools allow provisional hires, where they bring in someone with industry experience to teach now, and it is expected that the person will work on their own time to earn an advanced degree within a certain amount of time. Plenty of industry people are more than willing to do this, we just aren't willing to leave the industry to become a full-time grad student first.
- I ran into one school that offers online classes, claiming it must meet accreditation requirements in all fifty states. I wondered, if there are only a few states with super-strict requirements, why not hire an industry prof and only offer their classes in (say) 47 states?
Human Resources:
- I remember a certain job posting where a school was trying to hire an art/animation faculty under the job title of game design. I talked with some people at that school at GDC, who expressed equal frustration at the whole thing. Apparently they had not been consulted to write the job description, and of course anyone from industry contacting the school to inquire about the position would be talking to HR and not them. This is a communication breakdown that could be fixed in a few ways...
- Open a dialogue with HR to make sure the job postings say what you want them to say.
- Put contact information in the job posting for someone who actually knows what they're talking about, in case anyone from industry seeks additional information. HR is not capable of answering technical questions about game development, and they will probably not forward these things on in a timely manner, so prevent them from getting these questions in the first place.
- Don't just post a job opening on your school's website and think you're done, because the number of game developers that regularly search there is pretty much zero. Make postings on places game developers are likely to read, such as Gamasutra and Game_Edu. Attend GDC and go to events and sessions where you're likely to find interested candidates. Spread the word, because it isn't going to spread itself.
Schools located somewhere other than California:
- First, are you absolutely sure there's no game developers in your area? I had always assumed I was the only professional game developer in the entire state of Ohio, until I received email from a casual game studio just a few miles from where I live. And then another email from a publisher about as far away. And then I met someone from EA at a local IGDA meeting. And then I encountered a local game audio professional on the plane back from GDC, who then told me about another game studio that I've yet to meet. Columbus may not have the developer population of San Francisco, but it's certainly not vacant. Of course, it took a bit of digging (and a bit of luck) for me to find this out. Maybe you're in the same situation and you just don't know it.
- Does your school offer online courses? If a professor can teach from their living room, you can open your search to the entire world; it doesn't matter where your physical campus is, if all your game courses are online.
- Do you have teleconferencing? I met a few industry professionals who would be happy to give a guest lecture to my class, as long as they don't have to travel.
- Develop and maintain ties to the industry. Conferences like GDC are ideal for this. I even met one school that hired a full-time employee whose entire job is to research and contact game development companies. How do these ties help you? For one thing, it makes it much easier to have guest speakers from industry; even if no one lives in (say) Nebraska, maybe a few people have family there, and they'd be happy to drop by for an hour the next time they're visiting. Maybe someone at that company knows someone else who happens to live in your area, and a couple of phone calls to a friend of a friend gets your position filled (it's a small industry). And even if you don't have any faculty with industry experience, you can at least run your course content and curriculum through an industry advisory board, and get additional feedback from any of your students who happen to land summer internships.
In short: stop whining and start recruiting!
Sunday, February 24, 2008
Welcome, newcomers
It seems I met about a billion people this year at GDC, and I'm sure at least a few of you have found this blog by following the URL on my business card (if only out of morbid curiosity).
Some of the more popular areas of this blog (based on emails I've received):
Some of the more popular areas of this blog (based on emails I've received):
- My proposed game design curriculum
- Reviews for textbooks on game design
- A series of articles on the differences between industry and academia (I'll retrofit with a "Culture Shock" tag at some later point)
- A two-part description of an interactive final exam
- A list of analogies to explain the field of game design
- A two-part article on what all teachers should know about game design
Thursday, February 21, 2008
Think student games don't matter? Think again.
The Game Developers Choice Awards is an annual show where developers themselves honor the best games of the previous year (much like the Academy Awards for film).
At the GDCA, the winner for Game of the Year was Portal, beating out Bioshock, Call of Duty 4, Rock Band and Super Mario Galaxy. Additionally, Portal received several other awards (Innovation and Game Design) and was tied with Bioshock for most nominations overall.
In case the implications of this are not clear, let me say it straight: A seven-person student team made a game that, in the opinion of the professional industry, is better than four other games with teams of 100+ experienced industry professionals each.
The Independent Games Festival went much the same, with four-person student project World of Goo walking away with the grand prize (along with the other two things was nominated for).
Okay, so these aren't technically "students" anymore since they all graduated last year. And yes, the people involved in these games are absolutely brilliant, and I wouldn't expect this to be achievable by just anyone. But at the same time, I think it says something that small teams lacking industry experience are capable of this kind of success. If you are working on a student project, take it seriously...
At the GDCA, the winner for Game of the Year was Portal, beating out Bioshock, Call of Duty 4, Rock Band and Super Mario Galaxy. Additionally, Portal received several other awards (Innovation and Game Design) and was tied with Bioshock for most nominations overall.
In case the implications of this are not clear, let me say it straight: A seven-person student team made a game that, in the opinion of the professional industry, is better than four other games with teams of 100+ experienced industry professionals each.
The Independent Games Festival went much the same, with four-person student project World of Goo walking away with the grand prize (along with the other two things was nominated for).
Okay, so these aren't technically "students" anymore since they all graduated last year. And yes, the people involved in these games are absolutely brilliant, and I wouldn't expect this to be achievable by just anyone. But at the same time, I think it says something that small teams lacking industry experience are capable of this kind of success. If you are working on a student project, take it seriously...
Wednesday, February 20, 2008
At GDC, students are Pikmin
If you've never played the game, Pikmin are these strange little creatures that follow you around and follow your orders. Among game professors here at GDC, to Pikmin is now a verb, referring to the act of a student following the professor around everywhere in the hopes of being introduced to some cool industry people (instead of just networking and finding people themselves). My thanks to Brenda for introducing me to this amusing word.
There is an up side to this. The students that respect you will do pretty much anything you tell them. I could tell my students to form a human pyramid, and they'd probably do it. If I were a little more playful than I actually am, I could probably have a lot of fun with this.
In reality, it means that I can coordinate with students. This year there are some time slots (I'm looking at you, Wed 2:30-3:30 and Fri 4:00-5:00) where they've got five or six really great sessions going on simultaneously. With seven students at the ready, I can coordinate things so that each session is covered by someone who takes notes, and we can all type them up and send them to each other later. This frees me up to go to the more obscure sessions, secure in knowing that I've got some spare eyes in the high-profile ones. It also frees up the students: if all of the sessions are taken care of, any excess students can hit the Career Pavillion at a time when they'll be practically the only ones there, which greatly helps their chances of being remembered.
In an ideal world, I'll also make sure the students are not just networking for themselves but for each other. As an example, suppose one of my students is a brilliant game designer, and another student is looking to be an environmental artist. If the designer finds a company looking for environment artists, instead of just saying "sorry, not interested" they can add "...but, I know someone who would be perfect for this, can I give them your card?"
There is an up side to this. The students that respect you will do pretty much anything you tell them. I could tell my students to form a human pyramid, and they'd probably do it. If I were a little more playful than I actually am, I could probably have a lot of fun with this.
In reality, it means that I can coordinate with students. This year there are some time slots (I'm looking at you, Wed 2:30-3:30 and Fri 4:00-5:00) where they've got five or six really great sessions going on simultaneously. With seven students at the ready, I can coordinate things so that each session is covered by someone who takes notes, and we can all type them up and send them to each other later. This frees me up to go to the more obscure sessions, secure in knowing that I've got some spare eyes in the high-profile ones. It also frees up the students: if all of the sessions are taken care of, any excess students can hit the Career Pavillion at a time when they'll be practically the only ones there, which greatly helps their chances of being remembered.
In an ideal world, I'll also make sure the students are not just networking for themselves but for each other. As an example, suppose one of my students is a brilliant game designer, and another student is looking to be an environmental artist. If the designer finds a company looking for environment artists, instead of just saying "sorry, not interested" they can add "...but, I know someone who would be perfect for this, can I give them your card?"
Monday, February 18, 2008
Is this what leveling up feels like?
Last night was the first time at GDC when someone walked up to me, called me by name, was clearly happy to see me again... and I absolutely didn't recognize this person at all. So, I'm apparently part of a community that's larger than my close circle of personal friends, and they know who I am. It's a bit scary.
Monday, February 11, 2008
GDC Checklist
I've answered the same question ("This is my first year at GDC, what do I need to know?") several times lately, both for students and fellow educators, so it seemed worthwhile to post it here.
This is my checklist of stuff to bring:
This is my checklist of stuff to bring:
- Business cards, at least 250 of them (you had one out to pretty much everyone you meet, which is a lot of people in the space of a few days; better to have too many than to run out). In one of the classes I teach, I require students to purchase their own business cards on the pretense of using them for a game design exercise, but the real reason is so they'll have them on hand when they go to GDC.
- Clothes. Casual is fine, most developers will be. If you're allergic to denim or something, business casual is acceptable. Avoid either extreme (suit and tie makes you stand out, and not always in a good way; ditto ripped jeans and a t-shirt with M-rated content).
- Resumes, if you're looking for work. Do not hand these out to anyone, or offer them, or even mention that you have them; it's considered rude. But if (and only if) someone asks you, it's good to be prepared. Likewise, if you're entering a profession that expects a portfolio, making a few CDs to hand out with your resume can't hurt (but if you're on a budget, at least put it on your own thumbdrive and take it with you). If you're a game audio person, it's easier: put your portfolio on your iPod.
- Physical notebook (you know, with actual paper made from trees) and plenty of things to write with. It's easier to take notes during sessions if you don't have to jockey for outlet positioning, and if someone asks you for some information that they can take with them you can write it down on paper and give it to them. You can't do this with a laptop.
- Cell phone. If you meet someone that you want to meet up with again later in the week, the only elegant way to do this is to swap cell numbers. If you don't own one, consider renting one for the week, or buying one of those pre-paid ones (and write your phone number down somewhere easy to access, like on the phone itself, so you'll know it when asked). Oh, and make sure you turn off your phone before entering any session. In two years I don't think I've ever made it through a session without someone's phone embarassing them; don't let that person be you.
- Laptop is optional (unless you're carrying your portfolio on it). Take an extra battery if you have one, just in case you can't sit near an outlet, and turn off the sound.
- Sleep. Okay, it's not something you pack in your luggage, but be sure to get plenty before you go. You can count on having next to no sleep as long as you're there.
Friday, February 08, 2008
Everything I Need to Know about Teaching Game Design, I Learned in Kindergarten
In a Gamasutra article, Nick Burton of Rare urges developers to take an active role in shaping game education. I feel Nick's frustration; in spite of the great long-term rewards of getting involved with the local colleges and universities, very few game developers take the time to do so.
It reminds me of a story I read when I was young. It goes something like this:
The educator goes among the industry and asks, "who would like to help me craft a curriculum to take talented and eager high-school students and teach them how to make games?"
And Loosey Goosey says "not I, for I have to do the schedules for next milestone."
So the educator does it herself, and then returns to ask, "who would like to help me find talented high-school students so that I may educate them in our game development program?"
And Henny Penny says "not I, for I'm busy making textures for our models."
So the educator does it herself, and then returns to ask, "who would like to teach classes to these students, to show them how to make games?"
And Foxy Loxy says "not I, for I have to write some concept docs for this publisher RFP."
So the educator does it herself, and then returns to ask, "who would like to mentor these students, to show them what it's like in the industry and talk to them about breaking in?"
And Piggy Wiggy says "not I, for I've got to finish this code for alpha."
So the educator does it herself, and finally returns to ask, "who would like to hire these brilliant students who know how to make games?"
And everyone says "I do, send them to our HR department right away!"
Okay, maybe the original story was about baking a cake or something, but you get the idea.
It reminds me of a story I read when I was young. It goes something like this:
The educator goes among the industry and asks, "who would like to help me craft a curriculum to take talented and eager high-school students and teach them how to make games?"
And Loosey Goosey says "not I, for I have to do the schedules for next milestone."
So the educator does it herself, and then returns to ask, "who would like to help me find talented high-school students so that I may educate them in our game development program?"
And Henny Penny says "not I, for I'm busy making textures for our models."
So the educator does it herself, and then returns to ask, "who would like to teach classes to these students, to show them how to make games?"
And Foxy Loxy says "not I, for I have to write some concept docs for this publisher RFP."
So the educator does it herself, and then returns to ask, "who would like to mentor these students, to show them what it's like in the industry and talk to them about breaking in?"
And Piggy Wiggy says "not I, for I've got to finish this code for alpha."
So the educator does it herself, and finally returns to ask, "who would like to hire these brilliant students who know how to make games?"
And everyone says "I do, send them to our HR department right away!"
Okay, maybe the original story was about baking a cake or something, but you get the idea.
Friday, February 01, 2008
Culture Shock: Professional Humility
If you're a game designer for long enough, eventually you'll work on a game that ends up just not being all that fun. (No matter how great you are, everyone has their mediocre projects.)
As a teacher, there are analogous cases. Eventually you'll meet a student who you know is capable of grasping the course material, and they genuinely try hard, but for whatever reason they just don't seem to get it. Or, eventually you'll create an exam or assign a homework and half the class completely bombs it.
In either case, there are two types of people. There are the ones that look at the tiny amount of positive feedback (the one glowing game review, the one student who gets everything perfect) and decides that if this tiny minority understands what they were trying to do, then everyone could, and it's just that the others aren't trying hard enough. It's certainly not their fault if these people just don't put in the effort to see their obvious brilliance. They feel better, but they don't actually get any better.
Then there are the ones who learn humility. Yes, others may have made mistakes along the way, but something in your own work went wrong as well -- enough that it was unable to save everything else. By figuring out what you did wrong, you become stronger.
In games, this is actually pretty easy. Reviewers will quite happily lay your game on the table and dissect each of its flaws, for all to see. Post-mortems, likewise, show us that most development teams are painfully aware of their issues; if you as a designer have made mistakes, even if you don't know what they are, someone else on your project team certainly does.
In teaching, it's much harder. There is no "project team" -- in fact, it's rare to have even a single other education professional observe your work and offer any constructive feedback at all. Students can help you identify weak points, but they can't tell you what to do about them. Teaching, then, forces one to go beyond humility into the realm of self-reflection in a way that game development does not.
As a teacher, there are analogous cases. Eventually you'll meet a student who you know is capable of grasping the course material, and they genuinely try hard, but for whatever reason they just don't seem to get it. Or, eventually you'll create an exam or assign a homework and half the class completely bombs it.
In either case, there are two types of people. There are the ones that look at the tiny amount of positive feedback (the one glowing game review, the one student who gets everything perfect) and decides that if this tiny minority understands what they were trying to do, then everyone could, and it's just that the others aren't trying hard enough. It's certainly not their fault if these people just don't put in the effort to see their obvious brilliance. They feel better, but they don't actually get any better.
Then there are the ones who learn humility. Yes, others may have made mistakes along the way, but something in your own work went wrong as well -- enough that it was unable to save everything else. By figuring out what you did wrong, you become stronger.
In games, this is actually pretty easy. Reviewers will quite happily lay your game on the table and dissect each of its flaws, for all to see. Post-mortems, likewise, show us that most development teams are painfully aware of their issues; if you as a designer have made mistakes, even if you don't know what they are, someone else on your project team certainly does.
In teaching, it's much harder. There is no "project team" -- in fact, it's rare to have even a single other education professional observe your work and offer any constructive feedback at all. Students can help you identify weak points, but they can't tell you what to do about them. Teaching, then, forces one to go beyond humility into the realm of self-reflection in a way that game development does not.
Subscribe to:
Posts (Atom)