 |
|
|
| |
GCDC: Epic, Cryptic, Crytek, Vicious Cycle Talk Engine Tech
by Leigh Alexander
|
|
| |
|
August 24, 2007
|
| |
An Engine Panel at the 2007 GCDC examined the benefits and challenges of licensing an engine versus deciding to build ones own, and addressed questions to ask during the decision process and what to look for in support after the decision has been made.
Krawall Gaming Network's Goetz Klingelhoefer moderated, and Cryptic Studios' (City of Heroes, City of Villains) Bruce Rogers, Crytek's (Crysis
The panel opened with a discussion of why it might be advantageous to license a game engine instead of developing one's own. "From a developer's perspective, there are two things you have to devise -- building technology or building games," O'Neill said. "From a business perspective, you obviously don't have to listen to a publisher."
Rein added: "We have people that license our engine, but also make games with their own engines. It's really a game-to game-decision."
"Every publisher will want you to reuse technology," Binks added. "You need to do tech, but you can really give yourself a huge lift with an engine. But there are times when games have very special requirements, and that's when you have to do the tech."
Klingelhoefer asked the panel members if they'd ever been in a position when they had to advise a client against using their engine.
"We really can't judge a product -- we decided not to be the quality police," Rein said. "We've learned that lots of people that came out of nowhere make great games. But we advise people in what they have to do if they want to use our engine for their games."
"Understanding the developer's need is important, so there were times when we recommended other solutions which fit more to their needs," O'Neil said.
Do the panelists take feedback from developers and add required features to an engine, or do they take payment to incorporate a requested feature? "We specifically don't do that," Rein answered. "Developers will know exactly what we are doing. They know exactly what they get. We feel that if we put features in the engine, that we didn't think of ourselves, it wouldn't meet the high requirements we have for the features in our engine."
Klingenhoefer noted that many developers avoid middleware out of the fear that "it's not their game anymore" if they use it. "Many games are only innovating in content or in very small features," Binks observed.
"We already use a lot of middleware -- DirectX, the Sony library, et cetera," Rein replied. "Improving the middleware really helps developers -- in fact, everybody is a middleware user. Don't think that you are doing a game on a platform [without] having to learn how to use that platform. If you start changing our engine and write native code, you'd better know what you are doing."
On challenges in using engines, O'Neil said that documentation can be one of the biggest helps when going to a new engine or platform.
"Once we've gone through all the pains of programming all the native stuff, that becomes knowledge which we can pass on," Rein added.
The panel discussed issues that developers have when using those engines. "Learn the engine very very thoroughly before you start changing something on the engine," Rogers advised.
"We really push licencees to come to us and show us how far they got," Rein continued. "Use our support. There are a lot of times where we look at games made with our engine, and our artists say, 'if they had done that and that, they would get a lot more performance out of the engine.' One of my little dirty business secrets: we discourage people from sending us secretive messages, but want them to use our support boards. The community aspect of the support is extremely useful, because people will share code snippets and help each other."
"The mod community is a great community," concurred Binks. "For that reason, PC development is still a very important branch, because it is a great opportunity to play around with the tools."
An audience member noted that many upcoming games using the panelists' engine all have a similar look. "I think if two games look similar today, its probably intentionally," Rein suggested. "Two art directors know each other, or appreciate each other's work. There is no reason not to do, for instance, a cartoony-style game with our engine."
Recalling the successful Epic modding competition, an audience asked for more details and for a reason why the competition was done. "One reason is, of course, to see great mods getting made for our games," Rein answered. "The second reason is to find great talents. A lot of people from the competition now work for us or one of our licencees. It generally helps the entire community."
How often are major changes done during engine development? "If you create a complex piece of software, it is very important that you don't get afraid of breaking it," Rogers advised. "We frequently make major changes to our engine."
He continued: "If you don't embrace change, you will not get better. Execute some portion, test and make sure it works; it if doesn't, go back. Make sure you make the best quality product, even if you have to do very tough decisions."
An audience member asked the panel if they would rather go for generalization or specificity in their engines. "It really depends on the developer," O'Neill replied. "It's not really what you give them with your engine, but what they make of it.
"We decided to give away half the prizes of our competition to non-fps entries," Rein added. "We have guys making sidescrollers, puzzle games, RPGs, et cetera."
"If you are going for our engine, you probably want to do a MMOG," Rogers said. "So we probably go more for specialization."
Another audience member wanted the panel's opinion on why there are no real-time strategy engines. "Because companies who make these games don't want to give you their engines," Rein explained. "RTS engines are really custom-built for RTS games. There are only a few big players in this genre."
"RTSs have a lot of engineering in gameplay, not in technology," Rogers added.
"However, there is lots of middleware which specializes in certain aspects of RTS development," O'Neill offered.
Are the panelists talking with animation studios, such as Pixar? "I can't talk names," Binks replied, allowing, "but we are talking to a few major players."
"The show Lazytown uses our engine to render the background for their scenes," Rein said. "I think you will see more and more of that."
Another audience question was, "How can you stay competitive in this business without having a $20 million dollar budget?"
"License our engine!" Said Rein.
"No, license our engine," Binks countered.
"Start of by making a mod, experiment without spending much more than the price of a game," Rein advised. "If you are starting off with a few hundred dollars, make a mod."
How to define next-gen audio? "Our recommendation is to use another solution for audio, because that is not the area where we see our focus," O'Neill said.
"We really rely on what the console can do," said Rein. "5.1, 7.1 -- the consoles kind of define where we are going with the audio system in our engine."
Binks added, "Audio is no longer at a point where we have problems with compression. So you can do a lot of stuff."
Will OpenGL ultimately die out, what with Vista and DirectX 10 on the scene? The panel agreed it won't; "I come from the academic area and there OpenGL is still widely used," Binks added, and Rogers agreed: "OpenGL will be there forever."
"The problem is it's not owned by any company, nobody cares about developing it," Rein explained. "It's certainly a stepping stone to DirectX. However, the more important Apple becomes in the market, the more power OpenGL will probably have."
The last audience question was on the topic of the legacy code still contained in the panelists' engines, and whether they considered making new engines from scratch. "We kept some legacy code in for good measure," Rogers said.
"Our networking code is our legacy code, which still works pretty well," Rein added. "At some point we will need a new engine to deal with new platforms' technology."
|
| |
|
|
