When you're trying to do something like make a game that's 60 frames instead of 30 -- certain things that you do, are they driven by your engineering background? Is it that you want to challenge yourself? Or are you an egotistical man that wants 60 frames over everyone else?
JC: That was a decision where, when I first started off, I was designing a graphics engine that was going to be 30 frames per second. And I got some sense of what I thought I could do there. And then I got some sense of what I could do at 60.
And this is the important point, where I made the conscious decision that the user is going to get more value out of running at a higher framerate than me making the pixels pretty. Because that was the choice. You can go ahead and say, "Well, we can go ahead and pile on some additional levels of stuff here."
There are people who argue the exact opposite quite a bit.
JC: It's certainly a valid argument. It's not a foregone conclusion. Previously, not all, but most of the previous id games made that decision. "We want to show people graphics they've never seen before." That usually meant coming out running at a barely acceptable framerate until people got the next generation of graphics cards that made it really smooth.
I think that games look fabulous today, and I think that we can do a pretty good job of any designer's vision with the technology we've got today. And I think that that delta, of me doing a 30 hertz game versus a 60 hertz one, throwing twice the horsepower at the graphics, I don't think, gives as much to the user as giving it that extra smooth feel.
It's still arguable, because in the Doom 4 project, we decided the multiplayer is 60 frames per second, but the single player is 30 frames per second, so you can have twice as many demons coming at you. They're valid decisions to go each way, but I am proud of the fact that we were able to push Rage through at that field.
And part of it also was because in a driving environment, you notice 60 frames per second a lot more than you do when you're just walking around. So, that was also part of the deal -- it made it more important to be 60 frames per second.
As a renowned programmer, is there any technology out there that you look at that's not id that you're very impressed, like "Wow, how did they do that?"
JC: You know, I'm actually pretty impressed with most of the modern games. I think almost all the big games look really great nowadays.
I think the difference with you guys is the team size, though.
JC: We've grown a lot. We are a lot larger than we used to be. And in fact, one of the real lessons that we learned is Rage took too long for a couple reasons. We rewrote too much technology. We're not going to do that in the future. We're going to be more focused in what we do. And also a lot of the technology, like our animation and some of the AI stuff, was going to be good enough to keep, even if I rewrite the graphics engine.
But the other thing is just once you've made all the decisions, there's real value in being able to pile a hundred people onto a project. Now that id's grown to be multi-team, we should be doing more of that shifting resources around. As soon as Rage ships, the core tech team is going over to help the Doom 4 team. I think that's the more correct way.
If you can have a small team, get a game rolling, kind of lay out the core concepts of the game [you can do that], but if you want to get done in three years, you need to be able to throw a lot of people on it. It's awful trying to hire a bunch of people. You want to be able to have a migratory workforce that can kind of move from project to project, rather than see the whole thing through, because it's a waste to have a hundred people on it for six months of a project, when you don't know what the heck you're doing. But you really would like to throw a lot of resources on it at the end.