Interviews// John Carmack: The SPOnG interview

'Game environments that look as good as a movie backdrop'

Posted 24 May 2006 13:37 by
Games: Quake Doom Wolfenstein 3D
John Carmack, co-owner and technical director of id Software, is one of the acknowledged geniuses of the games industry. Put simply, with 1991?s Wolfenstein 3D he invented the first-person shoot-em-up. Innovatively, he sold Wolfenstein 3D as shareware, and released the engines powering his subsequent games Doom and Quake to all-comers, spawning a modding scene which saw the fps become the most popular genre. In technical terms, Carmack has always been several steps ahead of the rest of the industry ? he sits in his office (decorated with melted pistons ? he?s an inveterate car nut) dreaming up new ways in which to make games.

We had the privilege of catching up with Carmack at E3, where he revealed id?s next project (an all-new IP and a rare in-house development) and the technology he has developed which will debut in the forthcoming Enemy Territory: Quake Wars. He also told us about the relative merits of the Xbox 360 and PlayStation 3. Here?s the full, unexpurgated transcript.

Probably the best place to start would be the forthcoming Enemy Territory: Quake Wars. What can you tell us about it?

I?m a peripheral player in Enemy Territory. I did some technology for it, but it?s not really been my game: Kevin [Cloud] has been the lead guy at id over that. Splash Damage have been really great to work with. On the technology side, it has been rewarding. I did these two core pieces of technology for them, and explained where I thought the value was and what they could do with it, and they got it immediately. They ran with it and did some great stuff and, if anything, it makes me look really good.

One of those pieces of technology was megatextures. I could see when I played the game that they look great, but how the devil do they work?

If you look at the way most outdoor textures are done, you wind up with some grass textures, some dirt textures and some mountain textures. You break them up and make some borders, and kind of cross-fade and blend between them. There?s a lot of little strategies you can do for that, but it does wind up with this look of sameness across the areas, and sometimes it looks ugly if you look down closely at it, although sometimes it looks OK if you?re running past it.

When we were originally talking about Enemy Territory, early on, they were pursuing a direction like that, but I suggested a direction that I?ve considered a couple of times over the years, and I?m still surprised no-one has pursued this more aggressively. And that?s instead of trying to take some textures and combine them in some way, just make the entire thing a texture. At first glance, you?re like: ?That?s ridiculous ? it?ll be 4 gigabytes.? But if you look at it the right way?the way that people look at these outdoor territories really are just as a very cranky form of data compression. You wish you had this unique stuff over everything, but you?re saying: ?Well, we?ll tile these textures, so this is repeated here, here and here, and I?ll just blend between it because I can?t afford to have a unique texture there.? So really, it?s data compression -- just not very friendly data compression.

So what we thought was: ?Well, what if we tried to make it really unique, and then use friendly data compression on there. So we use a combination of DCT and black truncation coding on there, and it really does start off with these multi-gigabyte 32,000 by 32,000 textures for every level and it?s compressed down. Plus there?s some graphics technology that goes on to just pull in pieces of it as you go around. That all works pretty much seamlessly.

To create all that, you obviously can?t have an artist go in and paint four billion pixels, so there are two pieces of technology that combine to let you build all that. There?s a procedural base creation tool, which is kind of like various commercial landscaping technologies, where you?ll say as angles tip up, we?ll get more rocky here, and the grass will be down here?. But instead of doing the dumb blending that you have to do in real-time, they can do sophisticated things like have the grass petering out and going into the cracks between the rocks, instead of looking like you spray-painted it on. Then they?ve got the ability to go in and have an artist at any time, anywhere in the level, and to say: ?That doesn?t look quite right ? that tree is just sticking up out of the grass? ? which is what you will see in every other game. But what you?d like to do is scrub away a bit of the grass there, so there?s dirt showing, and you could maybe draw a root. So that?s the other freedom they?ve got.

That?s a finishing tool, but there?s a really cool aspect to it: finishing like that is guaranteed to have no impact on the gameplay. Unlike most of the things that you do when you want to make the game look cool, it won?t make the game slower or alter the gameplay, which makes you go through this iterative tuning process. But the great thing about stamping into a megatexture is that it has no impact on the game ? it?s strictly an aesthetic thing.

And you can target it, when you go to play-testing. You can say: ?People are congregating here and here, but they never really go up here,? so the artist can go and make a particular area really cool ? say with little footprints and tyre tracks, and it can be as good as a movie backdrop.
-1- 2   next >>
Games: Quake Doom Wolfenstein 3D

Read More Like This


phoo 30 May 2006 04:56
The problem with Carmack talking about console development is that he's not a console developer.

He's giving this impression that the tools matter more than the raw power. On a PC environment this is true. New hardware is constantly being added and it takes every last bit of DirectX and OpenGL for devs to keep on top of things. Those who use the latest tools on the latest hardware end up with the most technobabbly FPS which sells games (and graphics cards and memory and operating systems). Making the whole thing run efficiently needs to be automated becase there's no time to do it by hand before the new hardware's out.

On consoles the situation is virtually the reverse. Look at the PS2. It's situation was such that no developer could be crazy enough to ignore it despite horrible development tools. But Sony knew this. In fact Nintendo knew it before them.

The trick with console hardware is to remember it has a life cycle. Time can be spent to perfect squeezing out every last kernel of power from the silicon. Having a dynamic of development is important even on fixed hardware: games better look better at the end of the generation than at the beginning. This is achieved through archaic arcitecture and development tools. The genius is Sony spent every last transistor on raw power instead of efficient loading (etc.). Tapping it will be difficult, but by the end of the generation it will be done, and we'll constantly have a compelling (graphical) reason to buy new games. 360 hardware on the other hand has great tools for maximising efficiency from the get go. I.E. games won't ever look a whole lot better than they do now. Why'd they do it?

2 reasons:

1. Developers will only spend the time squeezing the power out if your system is dominating, which MS couldn't garantee (and Sony sorta could).
2. MS wanted to attract developers (particularly those neive PC veterans) away from Sony. Developers would like to go where the tools are. This plan may have failed - they attracted them, but did not really put them off the competition. The fact of the matter is, even though devs love nice tools, the ones that feed them know where the sales are.

As for his preference of symetric chips, of course he likes it, it's more like a PC. Cell requires a new programming mindset. Different is troublesome, but it's also better for certain things. The certain things Sony is leveraging it for.

As for buying a comercial PC to match these consoles?

Have you ever seen a comercial tri-core chip? Heck, have you ever seen a 3.2 GHz commercial powerPC chip. Or a 3.2 GHz multicore anything for that matter? unless it's called 360, I didn't think so. Further, it would take a ridiculaously wild departure for Intel and AMD to make PC chips that can do what Cell can do. GPUs and Ram may be one thing (or rather two), but nothing on the market can touch the 360 CPU for the moment, and nothing will touch Cell for a longer while.
YBQ 30 May 2006 06:03
I believe Carmack is completly right here, tools are very important part of devlopment and when it comes to Microsoft no one does a better job, why do you think we have so much devlopement on Windows than any other operating system.

Having said that its developers who can can squeeze everything out of a harware, just look at the games on PS2 6 - 7 years ago, there is a hell of difference. I think Carmack is talking about the first impressions here, when I started developing on PS2 it was a pain in the ass, however for X-Box, there was not much change from PC (though Xbox is just PC).

So in my opinion its the tools, tools and tools which can decrease the devlopment time, and it always the delopment time /cost that matters for any project.
tyrion 30 May 2006 08:01
YBQ wrote:
why do you think we have so much devlopement on Windows than any other operating system.

For exactly the same reason there are so many games on the PS2? The market is huge!

Great tools on a marginal platform will not cause huge numbers of developers to write huge numbers of software packages.

Developers will still write large amounts of software for a dominant platform even if it has s**te tools. See the PS2, which, as you point out, had awful tools to start with, but large numbers of games none the less.

In the end, you have to weigh up the development costs against the potential sales. If it takes 20% longer to develop for PS2 over XBox, but the market is four times the size then it's not an issue.

Please note that I'm not a console developer and that 20% figure was pulled out of the air as an example. However, I do write software for a living and can understand the basic parameters of console development.
Posting of new comments is now locked for this page.