All id's secrets belong to us! Todd Hollenshead tells all

Todd Hollenshead, CEO of American game developer id software (you may have heard of them), was in Australia recently as part of a whirlwind Return to Castle Wolfenstein promotion.

Todd Hollenshead, CEO of American game developer id software (you may have heard of them), was in Australia recently as part of a whirlwind Return to Castle Wolfenstein promotion.

Once again, our Atomic Spy Network delivered the goods, transmitting an exact copy of Todd's itinerary to Atomic HQ with plenty of time to spare. And so it came to be that on Monday the 12th of November, our resident Atomic Spec.Ops. member, Bennett Ring, was dispatched with orders to ambush Mr Hollenshead and extract an interview. What follows is a transcript of the event, the text of which was transmitted to us mere seconds before Bennett's CS skillz failed and Todd's elite guard burst into the room.



Bennett Ring: Quake 3 is perhaps the most widely used Open GL benchmark in the world. How important is it for id to include benchmarking functions in its games, and are you committed to include such functions in future games like Return To Castle Wolfenstein (RTCW)?

Todd Hollenshead: One thing that we do from a benchmark point is, John Carmack likes to have diagnostics within the game for internal development purposes and if you develop these features there is really no reason not to allow people to use them, whether it's a tool for amateur mod designers or whether it is for evaluating video card A versus video card B. The same standardised diagnostic tools in Quake 3 that are basically inherent within the technology of the Quake 3 engine are also in Return To Castle Wolfenstein. I don't know if RTCW will be as ubiquitous a benchmarking tool that Quake 3 was; because it has such varied environments you will get vastly different numbers based on what level you are on, its inherent geometry, the size of the levels in general or the number of textures being used. That wasn't so much the case with Quake 3.



BR: Obviously the open-air levels are going to be much more demanding on system resources.

TH: Right. Or even some of the smaller levels where you have a hundred different varieties of textures, or a large number of very large textures. That's going to be less indicative of what the raw geometry that's going through the accelerator is as it may be limited, for example, in texture ram or something like that.



BR: Is there a specific 'hardware revolution' – such as a new video chipset or memory subsytem, increased CPU speeds, increased availability of broadband or a new console – id is most looking forward to? Any big paradigm shift coming up?

TH: Well, I think that the paradigm shift on the horizon for 3D action on the PC is, instead of having pre-rendered lighting calculations for the maps, they're going to be rendered in real time. And that's what we're doing with Doom 3. The paradigm shift there will be, lighting rendered in real time by the video card, so GeForce 3 level geometry acceleration and T&L onboard – that's the next event we're crossing. Basically, there's sort of a 'are you going to try to put a foot in the old and a foot in the new, or wholeheartedly step forward into the next generation of technology' issue, and we're going straight forward.



BR: If you do go straight forward into the next generation, do you anticipate a risk of leaving people behind who don't have new, high end video cards.

TH: We made the decision with Doom that if you do not have geometry acceleration on the video card you just won't be able to play it. There will be varying degrees of performance that you can get or features that you can turn down to get trade offs of speed versus visuals, but the fundamental bottom line is, the new Doom technology will require you to have T&L onboard. I think it's a risk, undoubtedly, but I think it's a calculated risk and we're doing it with our eyes wide open. It's more than an educated guess – it's ultimately where the technology is going to go. I remember when we were working on Quake 3; in the initial development of that game, we made the decision that we were not going to do a software renderer, that it was going to be hardware acceleration required. A lot of people went, 'Whoa, hardware acceleration required?' Now, it's clear that that was the right decision and that was the direction you needed to take on the PC if you wanted to have competitive looking graphics.
The first time you saw the Quake 3 engine was in March 1999 and here we are in November 2001, and I think RTCW is going to be the best looking PC game this Christmas. So nearly two and half years later the engine really shows its strengths, including the strength behind making it a hardware-only rendering engine.



BR: You use server side network code in your games opposed to the client side prediction that CS and HL use. For modem players, client side prediction tends to be a smoother game. Are you going to stick with server side network code?

TH: You can't trust the client is the paradigm. And so anything you put on the client side you can count on people to hack and to manipulate, and we're really committed to trying to keep cheating out of our games as much as possible. It's going to be impossible to prevent all cheating all the time, but we're going to do our damnedest to try to make online game play as cheat free as possible.



BR: So you will stick with server side?

TH: Yep. I mean that's the way that the Quake 3 engine basically works and we haven't changed anything in the architecture for RTCW. But we are doing some things to try to limit the cheating. A lot of methods [we were working on] I think are going to be influential in the future in terms of people trying to prevent cheating, like the qvm's opposed to dll's, pure server checks and those sorts of things. Of course, people develop hacks around them. It's a difficult position. You are faced with [the dilemma] of allowing people to modify the game, knowing that people are going to manipulate and abuse that code and develop cheating, or not give people the tools that they need to make game mods and things like that. We don't want to be in a position where we are not giving mod authors the tools they need and want to be creative, and not be able to play around with the tools that are released with the game. But there's a balance. Right now we've decided that we're going to continue to release the content, continue to release the games source, so that people can do this sort of thing, and we're going to try to keep on combating cheating.



BR: Cheating. Have you ever prosecuted people who release cheats, as they are in effect damaging your product and its sales?

TH: We're not a litigious company at all. I won't say that we've never sued anybody, but we've never sued a customer to my knowledge. It's a harsh and expensive measure. Also, I'm not sure how the community would react to that sort of measure. I would much rather take non-legal measures first because I think, ultimately, an ounce of prevention is worth a pound of cure on that sort of thing and we can't go around suing everybody that makes a cheat. Some of the cheats also infringe copyright in addition to just being cheats, so I guess theoretically there are measures we can take there. But we are a small company, we only have 17 people and we don't have an army of lawyers to send chasing after people all over the world. Even if you are able to clean that up in the US they