John Carmack Speaks on Next-Gen Consoles:
id Software has begun to step up its efforts in the console development space. It's not that the company is a stranger to console development (DOOM 3 was released on the Xbox shortly after the PC, and in days past id had worked on Nintendo projects), but now id Software is getting serious and hopes to have a near-simultaneous release for its next game.
Carmack's platform of choice for console development is the Xbox 360, and he explained why. But first, a bit of history:
Back in the DOOM era of game development, high-speed graphics were coded at the register level (basically in machine language). Then, as development moved from DOS to Windows and code started being done through APIs, game development became more abstract and higher-level. Carmack remembers a frustrating time when there were literally 20 different graphics chips that game makers had to code for, but nowadays there's only two to worry about. While coding through these layers is sometimes easier, it can also be frustrating. Carmack often finds himself wondering if a mistake was "my fault, the drivers fault, or the hardware's fault?"
Carmack raved about the relative ease of developing for Xbox 360.
But the Xbox 360 was designed to have a very thin API layer. In Carmack's words, he can "basically talk directly to the hardware ... doing exactly what I want."
Here Carmack heaped praise on the decisions that Microsoft has made with the Xbox 360. "It's the best development environment I've seen on a console," he says. Microsoft has taken a very developer-centric approach, creating a system that's both powerful but easy to code for. This is in contrast to Nintendo, Sony, and (formerly) Sega, who generally focused on the hardware.
Carmack ruminated on how throughout history consoles have swung back and forth between providing high-end hardware or development tools. Until the PS1 came out, nearly everything was done at the register level, but Sony's first console shipped with tools to help speed the development process. This was in opposition to the Sega Saturn, which was very powerful but nearly impossible to efficiently code for. Then, with the release of the PS2, Sony flip-flopped: the PS2 had much more complicated hardware and you basically had to program it at the low level again. Then along came the Xbox, which didn't have low-level access but was way easier to program.
Carmack looks forward to what's coming up. "It'll be real interesting to see how this next generation pans out," he said. This time around, the Xbox 360 is coming out sooner and is easier to program; will it be enough to supplant Sony's market lead?
Single vs. Multithread Processing
Carmack points out that there could be diminishing returns with the next generation of consoles, thanks to the architecture of the hardware. Although the PS3's Cell processor is powerful, it's still a single-thread processor (unlike high-end PC processors). There's not much more technology can do to crank more speed out of a single-threaded processor. To make up for this deficiency, multiple processors are used: multithreading and parallelism is the way to go. But this isn't easy to do in games! "The returns will initially be disappointing," he explains.
It will take a long time before game developers will figure out how to get the most out of parallel processors, and in the meantime, it's going to make high-end game development more difficult -- "Not a good thing," Carmack says. There's no easy solution to this problem, no special compiler that'll take away the grunt work. "There's no silver bullet for parallel programming."
The Sony PS3.
Sony's position seems to be similar to the company's stance with the PS2: Sure, it'll be hard, but the really good developers will suck it up and figure it out. But Carmack wonders aloud: wouldn't it have been better to use multi-threaded processors to begin with?
From here, he brought the talk around to discuss alternate ways to divide up game code to take advantage of multiple processors working in parallel, and why it's difficult...
Multiple Processors for AI or Physics
Proponents of faster and faster processors sometimes argue that now that graphics are reaching their 'peak,' extra processing power can be dedicated to calculation-intensive physics or Artificial Intelligence. (Carmack relates how an Engineer at IBM told him that graphics were basically "done.") Carmack disagrees, seeing that graphics still have a long way to go. "We'd like to be doing Lord-of-the-Rings type rendering in real-time," he states. That's still an order of magnitude more than what's possible with current machines, and Carmack is looking forward to it.
That aside, Carmack spent a few minutes talking about Artificial Intelligence as something that can be offloaded to another processor for a cutting-edge game. Carmack is skeptical. AI is a very bleeding-edge science, and it can often be processor intensive, but when applied to games AI is usually a matter of scripting. What game designers want is a way to act as the 'director,' telling enemy and friendly characters where to stand and what to do. This doesn't take a ton of processing power.
Moreover, even if you did throw tons of resources toward the AI, it might not be the best thing for gameplay. For instance, writing tons and tons of code to enable monsters to hide in the shadows and sneak around behind the player would be interesting, but often these types of things could be scripted for a fraction of the effort and - for most players - the experience would be just as cool if not cooler. Carmack recounts how players of the original DOOM would think that the monsters were doing all sorts of scheming and plotting and ambushing when, in truth, they were just using the equivalent of one page of C code and running the most basic of scripts.