Yesterday we brought you the first part of our transcription of John Carmack's GDC keynote address. In this second part, the Id Software supremo discusses AI, game development cycles and how new technology is forcing the developer to think of new ways of speeding up production - such as a Quake II remix...
"The next thing I want to cover is what you do with AI. Of course that's a field that goes much beyond gaming - or entertainment even - to really large, kind of world scale important issues on there. But when we come down to it, when we start rendering all these completely perfect worlds that are looking absolutely fabulous, the process of making everything else look as good as the rendering involves many things that are difficult physics simulations and many things that are just AI complete problems and it's going to be really interesting to see how those things are addressed.
"One of my major strategies at Id has always been 'if you're not going to try and solve something really well, try and dodge the issue as completely as possible'. Which is why we don't have character interaction, because character interaction is hard, and if you start making characters look really really good, but they still act like cardboard cut-outs, y'know, it's an open question whether that a good direction to pursue.
"So... AI is one of those things that in the games industry is still addressed completely as a set of techniques and tricks and working at it specifically for a limited set of outputs. But we're going to be demanding more and more out of that. And when we start looking at what we really expect to see in a game - if people just sit back and kinda 'blue sky'... they wanna have some fantasy environment where you go in and you've got all of the people in there acting like people - that's a really tough problem.
"It's interesting in that... I believe personally that, as the direction of research goes, game environments are really a wonderful place to actually conduct AI research, because it gives you a simulated environment where you don't have to worry about sensors and actuators and you can still work on core computational problem there. So there are hopeful bits that may be interesting research elements going on there, but it always has to be tied in with the fact that in the end we are making a product that's supposed to entertain people and the choices that you make in technical directions, if you want to be successful, you have to keep your eyes on the value or in some ways what you might think of the quality of what you are doing.
"AI in many cases - there are some interesting aspects to the gaming world on there, where a lot of what people look at as AI, like bot programming and things like that, are issues where you're addressing a very domain-specific element of the game, and that's been good mileage, we've gotten good value out of the effort that goes into that, but when we start looking at harder and harder problems on there it does come closer to a pure research topic.
Not my speciality
"I'm probably not going to be one of the people at the forefront of that technology, but it's going to be an incredibly important area that we look at over the next decade of game development, and there is always the possibility that some really fundamentally important wide-reaching results maybe obtained by the efforts of people, y'know, to make a game in there, to make something come out the way they want characters interacting.
"But that is one of the big problems still yet to be done in computer science - I certainly believe it's a solvable one, but tying that into the actual process of sitting down and making games there is... it's always been interesting to have a goal to the project you're working on, trying to do something new each time and trying to meter out the time that you've got to develop something new and interesting. To actually tie in with producing a product that's going to pay for company and continue to make games in the future.
"That's one of the other major topics that I wanted to go over is the extensive stretching of the game development cycle, and some of the problems I see with our development cycles and, to some degree, the industry as a whole. We've been... obviously Doom III hasn't shipped yet, we're going into our fourth year of development on that. It's really close, but there are some interesting things I could look at on that.
Doom III... coded by a craftsman
"We were clearly, on previous projects thinking 'ok we're down the wire, we're pushing everything through, I've done a good job on all of this, but wouldn't it be nice if I could sit back and really clean up the code, perfect the interfaces, y'know, just do a wonderful craftsman's type job on that'. And, interestingly, this project I've had the time to basically do that, and I've come to the conclusion that it sorta sucks to be in that position where there's a small level of... there's a level of craftsman satisfaction you get from tying to do what you do at an extreme level of quality.
"What I've found is that's not really my prime motivation. I do take some enjoyment in it when you go ahead and work and polish and prove something, but in the end, that's not what's really providing the value to the end users and that really has become clear to me. And it's been something that's driven all of my developments over the years in that you want to pick out the things that are really important and you need to be able to categorise and say 'this perhaps has value' but isn't the best use of time on there?
"That's going back through every project we've ever done that's had those kinds of decision points on there, where 'is this going to be the thing that we focus on?' Is this going to be key? And when you get little bits of time and you can sit back and do a really nice polishing job, it's kind of nice... but... it's not the point of maximum leverage. And I found that I get the most satisfaction out of development work when I can tell that the work that I'm doing has major leverage on the final product.
"There are a lot of things that have changed with the industry that to some degrees have lessened the ability of that to happen, In the early days you had a company that would have a couple of programmers working on a project and there would be a good chance that a single programmer would basically know everything about what's going on in a project, and up until recently, every aspect of a game that came out of Id was something that I had originally written and then we would have one or two other programmers that would pick up the foundation and go ahead and work from there.
"The last game, Quake III, was the first game that had a major chunk that had something that I didn't write which was the bot AI analyser. In Doom III it's the first game we've started off intending to have multiple developers developing completely independent areas. And it's necessary at some point to do that if we follow the current design trends that we're doing with games because at some point you just reach a level where one person can't possibly do what you decided are critically important for your product - you have to split things up.
"But there's a big cliff right there when you go from one person being able to deal with and manage and go over and change and fix anything in the product, to a point where you have three or four or more developers that may not actually know what's going on with everybody else's code. It's been unnerving for me sometimes to realise that there are source files in Doom III that I've never even opened. On the one hand I can berate myself a little bit to do more comprehensive code reviews over everything, but it does just mean there's a finite level where there's only so much one person can deal with at one time.
Stuck inside a mainframe
"Again, it's necessary if we continue to have the kind of feature lists that we have, if we have to do everything we did before and do many more things... everything the competitors are doing, but to some degree, I feel that we might be falling into a kind of a mainframe trap where you looked at the old computer vendors that would look at things and say 'well, this is the serious work, this is our group of competitors. We have large products that have decades long histories or legacies with them, and we need to keep maintaining this level of support.
"And while I don't have specific visions for how this could go, it does sort of strike me that there's a possibility for things that are not yet another first-person shooter, third-person action game, or RPG, whatever, that there are game possibilities that are not just working directly off the existing paradigms, with the genres that we've got now. Certainly Id's claim to fame is probably that we invented a genre with the first-person shooter, and to some degree we're still trapped by that success.
"You don't expect anyone to cry over our woes on this, we're very happy to be successful with this, but there are some issues there that prevent us from doing radically different things. Just the concept of having dozens of employees at a time that have certain skill sets kind of determines where we go in the development process on there. We can't just say, 'oh I'm deciding we're going to do a strategy game with some increasingly clever objective, and we really don't need all these level designers'.
Hope for the small developer?
"There's an aspect of the established game companies having time, sort of a mainframe bias there, and I have high hopes that there are still many creative small development teams that can be working on a more innovative approach there. There are factors of efficiency there when I can still look back wistfully remember when there were six of us sitting in a room working all night to get the project done, rather than having a project manager and multi departments working on different things. But there's no question that what we're doing now really is superior in every way. I'm not going to go longing for the good old days of the extremely simple games - what we're doing now is just better, but it's better at much larger cost.
"The development process there I do still think is open for that six person team doing something really innovative, but it's not going to be a first-person shooter or any of the established genres because it just taking incredibly massive amounts of development time and effort to do this.
"The time ties in a really depressing level with technical time requirements and strategy on there, where the new Doom game was based on strategic decisions I made over four years ago. They've turned out good in that the hardware has pretty much evolved over time the way I expected, although, to be sure I have sort of an Hiesenberg uncertainty-effect principle on the hardware industry, where the strategic decisions I've made do influence upcoming generations of hardware, so it may not be completely strategic brilliance on my part (audience laughs). But the decisions looked good. I looked at this, and we were rendering the same pictures that we do now effectively over three years ago on a GeForce 1 class hardware, yet we haven't shipped the title yet, and we've had three generations of hardware that could have used this technology that we haven't been able to get out and really take maximum advantage of them.
Doom III coming soon...
"Right now we're looking at starting new research for the current generation of hardware with fully per pixel formats, doing all the interesting rendering things that we're looking forward to on there. But I'm looking at this and thinking 'well... we ship Doom III really soon now... generally we'd like to go ahead and have the next title... it's going to be a much shorter development time which usually means that we have not be so aggressive at developing new things. If we basically took Doom III and just spiffed up the technology a little bit - there are a couple more things we can account for in the changing market share.
"That means that a brand new level of technology, if I kind of do the level of clean rewriting that I did with Doom, might not even be started to be worked with until two years from now, and then it could take two or three years to develop a new title if we're lucky. It could be another four-year title after that, and that's looking at six years from concept time to actual deployment on there, and then of course there's the legacy tailing on there, where we'll have licensees using it for two generations of product after that. That's requiring, to some degree, looking ahead almost a decade of hardware technology.
More new stuff now!
"Certainly we can't be appropriate at that point. It might be scalable to some level there, but it's sort of like running, you can run Quake on a modern processor but it doesn't take advantage of what you can really do when you run a current game like Doom III. That's one of my big trouble spots on there. I want to bring new technology out as rapidly as possible - the new stuff is great, and there are things that we can do with the cards that are just coming out. I just got an NV40 in my dev system and it's spectacular... the power we can get with that to go ahead and utilise all the floating point calculations that we want to use, the new generations of what I want to do with the rendering and it's really disappointing that at the absolute best possible case we decided to kind of go for it and do a real high end product for the next one it would be two and a half years - best case - before we could have something like this that actually gets in people's hands, and I don't really know what to do about that.
"An idea that I floated early on in Doom III's development that I wish we had followed up on was to go ahead and do a product that was specifically a rendering showcase. A lot of people accuse Id products of doing that anyway - that's not the case. We do all the aspects of a game that we want to improve there, and certainly rendering hasn't been the thing that's held up Doom III's development - it's all the other aspects of the game that we're improving on there.
"I have some hope for tiny little specialty products, things like that, what I pitched the idea early on was basically doing kind of a Quake II remix and taking a game and not changing the game, y'know not going in and trying to redo everything, but build new media sets for it, and use the new technology and get it out there knowing that you're targeting a small section of the market, just so people can go ahead and get some value out of the newest generation of graphics technology, get people experienced with it and kind of start the cycle a little bit faster, where everybody always wants to see the second generation title with the new technology once everybody's kind of learned the ropes with it and is ready to kind of apply all the lessons that they've learned. It would be great if we could shorten the development cycles on there, rather than having three or four year development cycles so you wait six or seven years to see the second generation technology... Y'know if we could bootstrap that somewhat earlier...
Not as simple as all that
"But even the idea of just re-skinning an old game brings with it the problems that as we're doing the newer and newer graphics technology the media creation demands have just gotten worse and worse. Certainly we've got more levels of maps that are high resolution applying to everything, but what we also see is that things that were acceptable in the earlier games... I mean if you go back, Wolfenstein was blocks, y'know, you added a texture on, it was tiled to the same thing on each side and it took thirty minutes to make a map. We were shipping maps in there that were done in less than an hour. Somebody scrubbed something out, play tested for a while, said 'this is fun, it's in', Y'know, Spear Of Destiny... it worked, they were fun.
"But when we look at things now where it's taking man months to deliver a level to even the beginning of the play test stage, it becomes a real problem and I'm worried about the interactions between the media creation and the actual game content side. If we go back and get the Wolfenstein maps and somebody goes into a room and this is not much fun here you just scrub out a couple more tiles to connect and animate the cycles with the other areas and if you go in and you spend your couple of months you build an area in a current game generation and you say 'well this play isn't working out all that well'. That same knocking a hole into another room can take a week. It can take a week to go ahead and rebuild a room that looks good that connects in a different way, has a slightly different flow, relights the different area, so that's a concern. It's certainly something that makes the final bit game development process take a lot longer. I'm afraid that it has the possibility of actually making games less fun on a pure game development symbolic level, which you hopefully counteract with increased richness."
And that wraps up the second part of our Carmack special, taken directly from his speech at last week's GDC in San Jose. In the concluding part, the Id legend discusses his next project, and delivers more insight into the problems facing a developer at the leading edge of technology...