[In this interview, Matthew Weise, the lead game designer for the GAMBIT Game Lab at MIT, talks about their game design lab, including what it is and how it helps students prepare for the real world of game design. Weise sat down with Charles Pratt and Evan Amos from the Another Castle podcast to explain the course.]
As more and more schools are now accepting the idea of video game design as a viable education program, MIT's GAMBIT lab might stand out as one of the most realistic experiences out there for students. Built mainly around a summer intern course funded by the Singapore government, GAMBIT throws students into a group of peers who all take on different roles as a fully functioning, mock game studio. The structure has produced some amazing results, with many students going on to land jobs at places like Harmonix, EA and Irrational Games.
The results also come pretty quickly, as Matthew Weise, the lead designer of the GAMBIT lab, will point out. "We aren't a program," he says, "The GAMBIT lab isn't a four-year degree. We sometimes get confused with a full game designer and development program/curriculum, but we actually aren't. Our main lab, the summer lab, is over and done in eight weeks."
Another Castle: Can you explain what GAMBIT is, how it started and what it is you guys do?
Matthew Weise: We are a lab at MIT campus that is affiliated and largely funded by the Singapore government. Basically, what we do is we try to help the Singapore government bolster their games industry through a student exchange program with the entire network of institutions in Singapore, including universities and polytechnics.
They send their students from a variety of these universities under the organization of the Media Development Authority, which is one of the government groups in Singapore, for an eight-week summer program and they make a game from initial concept to final polish in eight weeks. After that they go back to Singapore, taking what they learned at MIT.
The idea is that they are going to learn at MIT what they wouldn't be able to learn in Singapore. It's not that they don't have any game design classes or facilities, they do, but one of the ideas was to get them out of the country and learning from people that they wouldn't have access to in Singapore -- that they take what they learn here and hopefully bolster their own industry. That's the main idea that the lab is built around, which is what we call the GAMBIT summer program.
AC: What does GAMBIT do for the rest of the year?
MW: The lab itself is open all year, during which we have small-scope projects. There are students that come from MIT, Berklee School of Music, and other near-by schools and do smaller projects during the year. The idea is that we are more less winding up or winding down from the big summer project.
AC: Back to the summer lab, can you describe what it is the students do?
MW: For the summer lab, the students are interns that work full-time on a project that is dictated by a research element. When the students come in, they are assigned to work in a group with roles like producer, programmer, sound designer, artist, etc. The Singapore exchange students and students from the undergraduate programs at MIT make up most of the technical jobs like coders, testers and producers.
For the jobs like artists and sound designers, we bring students from other schools in the areas like Berklee or RISD (Rhode Island School of Design), which allows us to get students that are very specialized, and we bring them all together in one place. But a whole team is usually about 10 people, with six teams for the summer program.
AC: Can you explain more about the research element and how it dictates a game?
MW: Our design is very researched focused; we don't want them just making first person shooters or games that any else would make. Not only are we trying to teach them game development, but we're trying to get them used to the idea of doing innovative work.
One of the examples that I like to give is Phorm. CSAIL, an AI lab at MIT, had come up with this algorithm that would automatically rig 3D skeletons with animation data. CSAIL asked us if we could make a game with it and we said we weren't sure but we'd try. So we gave it to one of the groups of students and the game that came out of that was Phorm, a game where you are an alien who can change shape to solve problems, which shows off the auto-rigging technology as part of gameplay.
The idea was to see how quickly the algorithm could rig and animate a skeleton, so how it was used as a game mechanic was that you'd be able to draw any shape you want, the algorithm would rig and animate a skeleton to the shape and bring it to life. The game itself is a platformer, and using the mechanic you have to draw and re-draw the shape-shifting alien in different ways in order to get through obstacles, like giving it longer legs to jump higher. It worked out rather well in the end, in that it illustrated the research clearly and was also a fun game.
AC: What kind of successes or jobs in the game industry have you seen people who have participated in the GAMBIT lab go on to get?
MW: A lot of them have gotten into major game companies, like Harmonix for example. Harmonix is actually within walking distance of MIT, so we sometimes take our students over there for them to see what it's like at a big game studio. Some have gone onto Irrational Games, Activision, EA. The students that come from Singapore go back and usually find work at game companies there, many of which are start ups. Some of our Singapore alums now work at Ratloop Asia, which did Rocketbirds Revolution! and Helsing's Fire, both of which made strong showings at Independent Games Festival recently. And one of our Singapore alums is a co-founder of Game Ventures, which has a pretty successful Cricket game on Facebook right now.
I definitely see our primary success in producing students that people in the game industry say are good when they come into work. Obviously they still have a lot to learn when they leave GAMBIT, but I think that learning how to make a game at GAMBIT - as an 8 week 9-5 project - is different than a more typical experience at a 4-year college. Making a game isn't homework here. It's not something you do in your leisure time. It's a job.
AC: What do you mean by leisure?
MW: The whole idea of the GAMBIT summer program is to make a game from initial concept to final polish in just eight weeks. It's a bit of a pressure cooker. We'll give them the research concept as their base and say "Hey, use this algorithm that was developed by MIT scientists to make a game, and it has to be done in eight weeks, and you have to figure out how to work with each other in order to make that happen."
Hopefully we get something in the end where the students have learned about producing a game on schedule, about working with other people, and they've also produced a game that, hopefully, is useful to MIT researchers.
AC: So you've put the game researcher in the position of the client.
MW: Yes, the way it works out is that each team is a microcosm of a bigger game company. We have one designer, one QA person, one sound designer, one producer, two to three artists and two to three programmers on each team. The programmers and artists have the opportunity to be in a lead position, or a following position, and everybody else is basically in a lead position because it's a small team.
They get to interact with the "client" directly, and so it's like a miniature versions of a big game company, as opposed to more of a garage band situation, where they'd be making a game on the weekends or after hours between classes. We've had students who have gone on to other games schools with more traditional class/homework structures, who have come back and told us how different GAMBIT is, that it's much more like a job with a much bigger emphasis on scheduling and team communication.
AC: So the way you guys take that approach, it's like a profit-orientated entity, but the goal is still to innovate through completing the research ideas.
MW: What we really hope to do is create people who are innovation minded, but have the skills to actually produce and polish commercial work. We don't want to produce a kind of student who does amazing innovative work but takes five years to do it. We want innovation at GAMBIT, but we want it by Tuesday, if you get what I mean. I'm not saying it's always a bad idea to take more time if you can afford it, but because of the way GAMBIT is structured - because we can only have these students for the summer and then have to send them home - we have certain constraints we need to work in, and it's a good opportunity to teach what it means to work with constraints.
Eight weeks might sound like a lot of time, but not when you are actively trying to teach your interns to avoid crunch. We feel crunch is a symptom of bad time management, but this also severely limits how weeks and days translate into practical development time. In the summer a typical work week is 40 hours. That's eight hours a day. During the school year, when our interns have full course loads in addition to working at GAMBIT, we can only have them work 10 hours a week at most. That means one semester translates into two and a half weeks worth of full-time, 40 hour a week work. That's not a lot of time. In terms of what's normal for polished game development, it's virtually nothing.
Most of the stuff we do, the stuff that you see on the website, is made in eight weeks or less. Some of them are made in two and a half weeks. There are a few cases where we took an eight week summer project and added more levels in the Fall/Spring, but that's very few projects and it's still not very long. I feel those time constraints are important to understand that when you look at our games. I think in generally they're a lot more polished than one would expect from such constraints, which is one of the things I feel we've gotten better at as GAMBIT has evolved.
AC: Is there any kind of advice that you'd give to people about what to expect when doing a real project with a time constraint? A mistake that you see a lot of people make their first time?
MW: I would say that a lot of the game designers, who have ideas but who have never work with other people to develop a finished game on a schedule, have this misconception that you design the game first and then you go and implement it. Game development is an organic process that requires a lot of iteration. It's not a simple matter of input/output. The value of user testing is something I see a lot of interns struggle with, as to why it's so important. You won't really know how a game works until you see a player play it, and everything up until then is just hypothesis.
This is one of the things you can try to tell people, but they won't really believe you until they face it themselves. Sometimes people just need to make mistakes and learn from them to really understand why a certain practice or method is a smart one. People who are unwilling to cut features when they become unmanageable, that's another mistake I see a lot of people make.
AC: What about communication? I hear that's probably one of the most difficult things in these type of groups, and poor communication can sometimes cause large problems that would have been otherwise easily preventable.
MW: Communication is probably the biggest problem that groups encounter. One of the things I like to tell interns is that they might know how to make games, but they don't necessarily know how to make games with other people. In this case, communication can mean many different things. It can be making sure that code is properly commented and readable by others than the person who wrote it.
It can be updating a design document in a timely fashion, so everyone knows what is actually in it. You don't want a designer to be walking around with design decisions that only they know about. It can be simple things: if you're having a problem with something, tell someone about it. An objection? Speak up about it. Lots of problems don't get solved because people don't want to rock the boat by admitting there is a problem.
Another common error is not wanting to take responsibility for things. Many people come in with the idea that what isn't in their immediate domain isn't their problem. They feel programmers never have to worry about design, that designers never have to worry about art, etc. This can be quite crippling to a team.
People have to understand that a problem with the game is everyone's problem, just not the designer's problem, or the programmer's problem. Hopefully, when people see that that one problem starts affecting everyone, they see the practical value of speaking up about problems, or asking others if they're having problems. Only teams that are able to do that produce good work.
AC: So can you tell me a bit about yourself? How you started and then ended up at MIT?
MW: I was a student at MIT in Comparative Media Studies from 2002 to 2004, and before that I was in film production at the University of Wisconsin-Milwaukee, because I always was a film lover and still am. I went there, started the film program, but somehow transitioned into writing about video games. At the time I was working with 16mm silent film, which was cool, but for some reason - maybe it was my nerdiness - I felt more comfortable writing. I had some teachers who encouraged me in that direction, and eventually I ended up designing my own degree built around analyzing video games. I don't think it would have been much good getting a job at the time, but it did get me into MIT.
At MIT I mostly did writing and analysis, but I did do some design work, primarily on a educational game set during the American Revolution. That was my first exposure to game design, with an actual product being made. The research group I was in was funded by Microsoft at the time, and I remember being given a Microsoft Game Design Document template to work with. I didn't really know what I was doing, but it was an attempt to produce something professional. After I graduated I moved to Atlanta with my girlfriend who was doing her PhD at Georgia Tech, and I started looking for a game design job. After a few months I landed a producer/designer job.
The company I ended up working for was... well, it was educational, to say the least. It was not very well managed in my opinion, and the experience was rather frustrating. There were people there who had worked in games for a long time, but they didn't seem to have very structured development practices or the ability to communicate them well. However, because they saw themselves as veterans it was hard to convince them their habits were bad, and I didn't know any better anyway.
Overall the experience actually was quite instructive, especially in terms of dealing with constraint. We made games for a wide range of mobile devices. This is before smart phones really. Publishers would expect versions of the same product that worked on both a 1mb memory device and a 64k memory device. Some of the devices didn't even have enough memory to fill the dimensions of the screen with a single graphic. The constraints you had to design within were unbelievable.
The spec range was like the difference between, relatively speaking, the Xbox and the Atari 2600. It would be like if someone asked you to "port" Splinter Cell to the NES. And some of them didn't understand why both couldn't be 3D.
Dealing with those people was always very frustrating. I remember one project that, we were told, should "appeal to women". We were then instructed that this meant the game couldn't have any real gameplay but that players had to be able to get through it using only knowledge gleaned from super market check-out isle tabloid magazines. Amazing.
At one point I worked on a project that was supposed to be two-months, like eight-week projects we do at GAMBIT, but it ended up stretching out into six months by the time it was done, and by then the publisher didn't even want the game. Around that time I remember hearing what the budget was for the project - how much our company had spent on it overall - and it was more than what some first-time indie filmmakers have used to start successful careers as directors. As someone who basically gave up film for games that was a very sobering realization.
AC: Because what you wanted turned out to not be as good as you thought? Or because there were so many problems with the company?
MW: It was a combination. After that project I just wanted to see for myself if it was even possible to get a game out on time. It was a personal challenge. The way that I accomplished that was just by checking up with the development team everyday, asking them how long their tasks were taking them, counting the hours, putting it into a spreadsheet and adding it all up. It's the basics of normal project management really, but I had to arrive at it on my own in a way. I had to reinvent the wheel because no one was helping me.
AC: So you guys didn't have any producers? That's usually the producer's job.
MW: I was the producer and the designer and the sound guy when it was needed. Like I said, it wasn't very well organized, without really clear divisions of responsibility. It was a difficult time, but also rather instructive... in retrospect. Only later did I really discover how I actually learned a lot of useful things. At the time I was sort of disappointed to be working in such short development cycles, on such small games.
I remember when I was trying to get out of the company, and looking for jobs at places like GDC, that a pretty famous game designer told me working on such games wasn't "real" game development. I don't think he meant it in a mean way. He just sort of mentioned it off hand, because I think he was used to bigger games. But it was still pretty discouraging, especially since I never wanted to work in mobile and only did because it was the only job I could get at the time. It turns out working in such short cycles and with such constraints was good at teaching certain things, thing which might not have been as clear working as a cog in a bigger machine.
This didn't stop me from getting interviews at bigger companies like EA. They flew me out and everything and it was all very exciting. But then, out of the blue, a colleague I had worked with at MIT told me about this lab he was starting up, that it was well-funded, etc. He offered me a job there because I knew the academic side but also by then had some experience with actually delivering commercial projects, which he said was a perfect for the teaching/mentoring mission of the lab. It was basically an opportunity to help students avoid the mistakes I made at the company I worked at. I told him to sign me up.
AC: Lastly, as much as you're learned about game development from working in Atlanta, is there anything that you learned about game development by watching your students?
MW: Sara Verrilli, who worked on games like Bioshock and Thief before coming to GAMBIT, has mentioned to me a few times how she might do things differently even on bigger projects after observing so many smaller projects. It's pretty enlightening, being able to oversee different people in a pressure-cooker situation each summer, over and over again. Watching six teams every year deal with being first-time game development gives you a lot of opportunities to recognize patterns, why certain things seem to go wrong in the same way with different people each time.
I think there is more you can get done in a small time frame than bigger companies - who are used to 2-4 year development cycles - might be willing to admit. We get a lot more done in eight weeks than some bigger companies do, and if I were starting a bigger project I'd try to use that knowledge to maximize efficiency. I'd definitely do a lot of rapid prototyping in pre-production, maybe start with a GAMBIT-like eight-week or sixteen-week version of the game, just to see what happens when we try to make it quickly. I wouldn't expect that to be the final game, but I would expect to learn something perhaps more valuable and usable from that experience than sitting around for months trying to think of ideas before trying them.
It seems to me like there's a lot of bloat in the process of big game companies. Not all of them, mind you, and some of them have good processes in place. But I do feel there is probably something big game development can learn from small game development. I'd be really interested to see what someone like I, who has worked at a small company, and someone like Sara, who has worked at a big company, could come up with if given the opportunity to combine the best practices of both worlds. I suspect we could probably develop a pretty time efficient process, and get a lot more done than one might normally expect from a typical two year development cycle.