SAN FRANCISCO--Getting one of the most advanced 3D game engines onto the iPhone has not been an easy task for Epic Games. But they're close to getting into the hands of developers, and gamers alike.
The makers of the Unreal Engine now say they've kept approximately 90 percent of the code from the PC version, but that process of getting it from PC to Mac, then to the iPhone has been cumbersome.
In a talk to developers at Tuesday's, Epic Games' senior console programmer Josh Adams illustrated some of the pitfalls in taking the Unreal Engine, which is--and always has been developed in Windows, over to other platforms. In this case it was Apple's iPhone, which despite being one of the faster smartphones on the market, does not compare to a multi-core gaming PC.
The Unreal Engine is what powers many of today's popular PC and console titles like Gears of War, BioShock, Mass Effect, and of course Epic's Unreal Tournament. What the company builds for its own games, it then licenses out, meaning other publishers can use it on their own titles. The company also has a development kit, which anyone can use (not just big studios), then sell their games for a small fee and a chunk of any revenues. In that regard, it's in the company's benefit to get it ready as something it can sell to other developers, as well as port in-house titles out as iPhone games.
Adams said that the single most pressing issue Epic has run into while porting UE3 to the iPhone, is simply getting the various systems to talk to each other. The engine itself consists of 2 million lines of code, many of which depend on Windows-specific features. In porting it over to the iPhone, Epic has had to make a number of workarounds and simply cut out things that were either too taxing or completely incompatible.
One of those things that has seen a drastic reduction is the rendering, also known as the magical process wherein lines of code get turned into textured levels filled with bloody explosions. Adams explained that where the standard version of UE3 is running thousands of rendering shaders, the iPhone can only do so much. Part of the problem is that UE3 is used to having several processes to work with--one thread for running the game and another for doing all the rendering, whereas on the iPhone both of those tasks are running on the same processing thread. Adams said that having an extra processing core to work with would be good, and that "four would be great."
Another big problem Epic ran into was with textures; 98 percent of UE3's textures are compressed using a DXT, a compression codec that Apple does not support. This, combined with the aforementioned processing bottlenecks, have led to some major simplification in the quality of textures that can be displayed, or even processed while the game is running.
Epic's solution was to simply flatten the textures out and compensate for the lack of some of the 3D elements with lighting effects. Though even there, things had to be tweaked considerably. The iPhone version of the UE3 engine will simply use one or two lights, then effectively clone them throughout a level. Adams said that the effect is good enough on the small screen that players should barely notice it.
Ultimately, what may become the biggest problem is actually one of size itself, both in the data size of the engine and the scale of the game worlds it can render. The first issue is one Adams said can be addressed by Epic, since they still have to go through and clean out a lot of superfluous code that's not being used in the iPhone version. Right now though, it's sitting somewhere between 16-18MB, which is close to pushing Apple's recently upgraded 20MB over the air download limit. This means developers will have very little space to work with to keep their game at a size where users can buy it, then download it when away from a Wi-Fi connection, or a computer with iTunes.
The other, more pressing problem is one of level scale--a limitation more of OpenGL ES 2.0, the graphics API that powers these games. Currently, it does not support "occlusion queries," which Adams said limits how big developers can make their levels. This basically keeps the game engine from rendering something unless the player is looking at it. Other engines such as Unity have had to build this on their own in order to help developers create levels at scale they would have otherwise been unable to. For now, that means UE3 is going to have to load large levels in chunks of several smaller levels, instead of simply streaming them in as the player moves throughout a virtual world.
Adams did show off a working version of UE3 running on an iPhone 3GS, though he would not say when the first crop of games that have been built using it will end up in consumer's hands. The good news at least, is that the tech demo he showed off was running at a solid 24-30 frames per second, a number that could get a bump on the, and whatever hardware improvements Apple bakes into .