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

    [07.05.11]
    - Evan Amos

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

Comments

comments powered by Disqus