For the original Unreal, Steve Polge wrote the AI and gameplay systems, Erik de Neve wrote the procedural texture effects and helped optimize the renderer, and James Schmalz had written some of the weapon and inventory code.
Most everything else, I wrote : the core engine and resource management, the editor, the renderer, the networking code, the scripting system, the collision detection and physics. It was a fun and daunting experience. I think the one-man-band approach works well for the first year and a half of developing entirely new technology -- if multiple programmers were working on the project at that point we would have just gotten in each others' way and made a mess of things.
| QUOTE on the next-generation UnrealEngine3 "... All lighting and shadowing are per-pixel, and we support lighting and shadowing techniques that go one or two generations beyond what the major upcoming 2004 games are doing." Tim Sweeney |
By early 1997, we had hired Steve Polge after seeing his Reaper Bot mod for Quake, and he had written his first pass of the AI and gameplay code. That was my first experience collaborating and sharing responsibility for a large amount of code with a great programmer, and it was a very positive experience that paved the way for the next generation of Epic programmers.
Nowadays, we're developing the third generation Unreal engine, and it's a very collaborative effort between a quite larger programming team than the original Unreal. Andrew Scheidecker has written the third generation Unreal Engine's new DirectX9 renderer with its scene visibility solution, new material shader system, new terrain system featuring displacement maps and foliage, and has improved many of the engine's internals. He joined us during development of UT PS2, and he absorbs knowledge at an amazing rate. Dan Vogel has responsibility for the particle system, sound system, new background loading code, and lots more. James Golding is heading up our physics system, while Warren Marshall is responsible for UnrealEd. In total, there are now 11 of us programmers at Epic, each responsible for certain parts of the engine.
Which aspect of a game engine is the most difficult to program and which is the most important, assuming "most difficult" and "most important" are not the same?
I don't think it's wise to single out any subsystem as "the most important", because games are such an across-the-board experience. For a successful game, you almost always have to have fun gameplay (which usually implies good AI, good network code, and good physics), impressive visuals (implying a modern and stable renderer), good sound, sufficiently powerful content creation tools to empower the artists to work their magic, and a sufficently powerful and stable engine framework (the unglorious things like resource management and loading) to enable the programmers to work productively. A game or engine seriously lacking in any of these areas is very likely to turn into a disaster.
On the other hand, it's easy to point to the hardest part of engine development: putting together a coherent set of subsystems that interact well together. It tends to be much easier to program one cool feature in isolation than to make it integrate well with lots of other features. A modern game engine has a very complex set of internal interactions between rendering, networking, physics, gameplay, and editing tools.
For example, good gameplay networking performance depends on having a predictable physics model, and physics depends on collision, which depends on editing tools, which require a renderer for visualization, and that renderer isn't of much use if you don't have an editor so you can get content in. There are a great many circular dependencies, and as Dijkstra said, "The hard part of programming is how to not to make a mess of it".
You have mentioned that UnrealEngine3 - what you're currently working on - is :
"… the name for the next major step in Unreal technology, aimed at DirectX9 hardware as the absolute minimum spec, and scaling (way) upwards from there."Could you briefly clarify (perhaps with a summarized list of DirectX9 features) what is meant by "DirectX9 hardware as the absolute minimum spec" since there appears to be different interpretations of "minimum DirectX9 spec" from a hardware perspective?
By DirectX9 minimum spec, we mean we're going to make a game that brings today's GeForce FX's and Radeon 9700+'s to their knees at 640x480! :-) We are targetting next-generation consoles and the kinds of PC's that will be typical on the market in 2006, and today's high end graphics cards are going to be somewhat low end then, similar to a GeForce4MX or a Radeon 7500 for today's games.
Specifically, all pixel rendering is done via high level shading language, and these shaders are quite complex and are often dynamically and programatically constructed as artists visually put together their own custom materials. All lighting and shadowing are per-pixel, and we support lighting and shadowing techniques that go one or two generations beyond what the major upcoming 2004 games are doing.
