Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Interview: MIT's Matthew Weise on the GAMBIT Game Lab

    - Evan Amos

  • 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.


comments powered by Disqus