It seems like people are moving away from proprietary tools now, because it's so expensive to have all these people working on them.

CK: It's the same problem I saw in the past, which is if you've invested so much money and have stuff that works right now, why abandon that and start buying it from people who could be acquired by EA? It's a varied cost, and a hard thing to justify. There's so much fear these days. I hear, "We're threatened if we don't own it all," and "We're vulnerable." You could potentially see a backlash against off-the-shelf stuff.

And then there's the other side of it, which is this belief that we can take offshoring to such a full degree that in the future, if you want to make a Grand Theft Auto game, all you need to do is sign the proper contracts and farm it all out overseas. I'm particularly doubtful that this will all fully work, especially on the preproduction and technology sides.

It seems like most companies are one failed game from either dissolution or being purchased. Most companies have to put all of their eggs in one basket just because of their size, and when that basket is filled with 20 million dollars, it tips over. What kind of industry is going to result from that mentality? I don't think it's necessary.

CK: I don't think it is either. I don't think that making minigames and digital content is entirely the answer. It's one avenue, and they'll do more of it. I look toward some of the other industries that have solved this problem. There's car design centers that design cars, and set things up. It's a different skill set, and it's often either a different branch of the company or a different company altogether from the ones that figure out how to reduce costs much as possible to save money on things that they know about -- the repeatable things that don't have to be iterated on.

Our consultant uses the Big Mac example -- a Big Mac tastes exactly the same in Japan as it does in San Diego. The reason for that is that they have a 300-page Big Mac recipe manual. That's how you mass-produce things, by knowing exactly what it is. You can't do that with games. You can't repeat that process unless you know exactly what it is you're producing. That's what I'm saying -- separate the preproduction, know the game first, and only spend the five million dollars discovering that one hour of core that you want to sell. Then go to your 300-page Big Mac recipe and make 40 billion of those, like they do at McDonald's.

The problem is that you've got a developer which has big spreadsheets explaining, "Okay, we have to be in production here. I don't care where the game is. I have to find something for these 50 people who are coming off of another game to go on, on this date." You've got to make payroll, and you've got to get cash flowing in. That's what's forcing us to make all these decisions. The decisions aren't being made about the game. It's because resource flow on huge games is what rules developers right now. These days, you can't survive just having one project with 100 people. You've got to have three to justify your company. You've got to figure out what everybody's doing on a day-to-day basis.

There almost needs to be an industry shift, maybe from an external source that says, "Look guys, here's how you can organize yourselves into a better model." That's sort of what tools companies are tending toward. How do you envision that shaking out?

CK: I don't see where it's coming from. There's been some resistance to every change, but really the market is going to drive solutions. I'm personally seeing a lot of enthusiasm for the Agile stuff, and a lot of that is just coming from desperation. It's why we adopted it -- we started a company, we were well-funded, we were creating our own engine, and we were still screwing up. We were buried with problems and a slipping schedule, and not seeing the game. We're seeing that all over the place -- everyone's looking at the bottom line and saying, "It's broken." I think that's going to drive change.

I heard a rumor that you guys were using [agile development method] Scrum less than before.

CK: Nope. I don't want to sell Scrum as a silver bullet -- it's first and foremost about having a great idea and a great team to execute on it. Scrum is about not going down false paths as much and not producing as much waste. If you pick a dozen monkeys and let them develop a game using Scrum, they'll be successful with Scrum, in that they will fail faster. You won't sign up a two year project and then find out two years later that the monkeys have nothing to show for it. Fast failure is a benefit of Scrum, but people keep looking at it like, "Oh, the monkeys failed, so it's probably Scrum's fault."

If you want someone to fail, you want them to fail fast, before they spend a lot of money. That's how Nintendo was. When I was working on the Dream Team [at Angel Studios], they wanted us to do this DNA-based driving game called Buggy Boogie. You had these vehicles that would eat other vehicles and adopt their powers and morph. It was really cool. But they would sign three month contracts, and Miyamoto himself would say that he did not want any documents. He would just say, "Find the fun, and I'll be back in three months to take a look at what you have."

We went through about three iterations of that. We busted our hump trying different things, but at the end of it, he kept coming back and saying that it wasn't there, and it wasn't fun. We were a new company that didn't know how to make games. After about six or nine months, he came back and said, "You guys have really worked hard, and we see the progress, but we're not seeing the product. But another opportunity has come up for a fantasy golf game, so why don't you guys work on that? In three months, we'll be back. Show us a golf game."

So rather than getting pissed off at us and canceling the contract after two years and millions of dollars, they spent just a tiny fraction of that with a small team and said, "Well, it was just a bad idea." It maintained the relationship with them, so we could go off and do something else.