Working Without Crunching

You are here

American McGee (personal hero) in a piece on Gamasutra on how his process developing games works – totally crunch-free:

You discussed the idea of small innovations. Rather than push forward with large things, it’s better to do small innovations. What taught you that lesson, or where did that come from as a philosophy?

AM: Well, you understand, it’s more about the taking the less risky innovation. It doesn’t necessarily mean that we’re always doing small ones but when we do a big one, it’s one that we’re very comfortable with, right? So, we may innovate a lot in terms of an art style but then that’s because we’re really comfortable with making that new art style.

Whereas we wouldn’t take our current [Unreal Engine 3] technology and really build a new engine and try to suddenly start innovating that. I mean, that’s what people would call it – trying to change that to be something that’s going to make a big, massive open world game, right?

Well, one thing you talked about is that you don’t crunch, which is exceedingly rare. And how did you arrive at that?

AM: Just process. It’s crazy. I mean, I wish more people knew about Grimm, because for us it was a phenomenal success, but because of GameTap and their distribution and monetization model, no one really ever heard of it, and it never made a dime for them, or for us.

But what it did do was build us into a studio capable of really rock solid, on-time production, because we had such unbelievably short timelines. I mean, when I came to China, we signed the deal. The clock started ticking at 12 months from myself, the guy Adam that just walked by, and my art director. So we had three guys. We had to build a team, in China, and get our first episode of this game out 12 months from the day that everything started up.

And that was why I brought up Conway’s Law. What it did was, the mandate was 24 episodes, each a half hour in length, going to be released this kind of boom, boom, boom fashion of one every eight weeks. So, I reversed the product requirement into that production structure.

And that’s what I saying; it kind of ended up looking like, [what] I later learned, is called “Scrum”. But I didn’t know what Scrum was, because I was out here. I mean, everybody else was going nuts about Scrum back in the States. It wasn’t until one of my Western friends came out mid-way through Grimm and said, “Oh, your production looks like Scrum.” I’m like, “What the hell is Scrum?”

But it did something really strange – again, because of the outsourcing as well – it made us really break the whole project down into these little chunks. And that was one of the cool things about Grimm, was that we shipped 24 individual games. It wasn’t one big game. Each episode was completely standalone, and disconnected from the rest.

So as a result we broke the production into 24 discreet timelines and we broke the team up in this way where these little pods were each attacking, and they were cycling. You would have one group doing the concept to Alpha and another group would take their work and do the Alpha to Beta and another group would take their work and do the Beta to final.

It was very much like a sort of TV production model, of you shoot it, and then you send it to editors, and you go to post. We were doing that exact same thing… and it just worked. And that combined with the outsourcing stuff, and how much planning had to go into that, it just emerged and it was really cool.

I fully intend to use that knowledge to shield myself from too much crunching later on – after all, it can be done without, right? And again, I sound extremely pompous and self-righteous and thoroughly non-idealistic – but I definitely have better things to do than catching myself a burn out syndrome, no matter how much I like making games.