Chris Lambert @ PC.IGN.COM

It was a dark and stormy night. The clouds tumbled and rolled over what remained of a once-sleepy suburb. The pub was a shell of a building; half of the windows were shuttered, the other half pulverized as if by some terrible gust of wind. Where there had been a door, keeping out the cold while welcoming the thirsty, now was a gaping frame turning away nothing but inviting even less. The bent streetlamps cast long shadows from the giant, square moon in th-- Square? Crap.

The alpha blending states aren't being preserved properly, and after going into fullscreen mode the moon object no longer resembles the crescent shape the artist created. My bad.

Like many games, Hellgate: London requires close cooperation between the graphics engineer (enter: me, stage right) and the small, dedicated platoon of 3D concept artists, modelers, animators, riggers, texture artists and technical artists to bring the designers' vision to life. Our game design has many challenges common to conventional graphics engines and then brings an extra barrel of enraged, starving monkeys to the dinner table just in case we get too comfortable.

Take the moon. This is a pretty standard task in 3D engine design: keep the settings required to draw the object (called "states") with the object itself, to make sure it can be drawn correctly when the time comes. In this case, a few of the states were implicit; because the moon was rendered at the beginning of the frame, certain states tended to have a "good" setting. Then the fullscreen change caused a few one-time renders to take place (inventory thumbnails -- more about those later) and they screwed the states. Boom! Transparency (alpha blending) fails and the giant square moon comes out.

OK, that was an easy one. Then the monkeys come out.

Our levels have major random variation. Not random variation like "look, the town borders a graveyard this time!" or "when I play the same level backwards, I can almost taste the value!" Underground, subway tubes and sprawling underground complexes join together in three dimensions. Train tracks loop under and over other tracks and join again into cavernous terminals. Above ground, dozens of variations of road segments, buildings and unique landmarks link together to form complex, interesting layouts. The scale of these pieces aren't city blocks but small, detailed components. They are pieced together at load time once the level layout has been decided.

Sounds great! However, this degree of randomness leads to graphical problems in the outdoor realm. One of these, as a means of example, is how to present global illumination.

Global illumination is the task of representing light coming from and interacting with the environment. In this case, the moonlight is casting light onto the scene and causing shadows to appear on the moonlit streets and buildings. The sky is at times an ominous dark green color and other times a dull glowing red. At least some light should be bouncing back from the ground and walls, back-lighting the characters and other objects.

Getting that lighting to show up in the world in an efficient, real-time way is the task at hand. There are quite a few ways to attack the problem. The common approach has been to use so-called "lightmap" textures to apply pre-computed global lighting to all the fixed, non-moving objects in the world. A newer technique is to create a series of functions to describe the incoming light from various directions and then compute and store the correct lighting values for the functions all over the world to be reconstituted into actual light data at runtime. (Whew.) The most expensive approach would be to actually calculate full lighting and shadowing at runtime in shaders for every single pixel on the screen. Hybrid approaches are common: a major game in recent history used three lightmaps to store lighting values for three approximation functions.

At Flagship, we choose technical features through a combination of cost/benefit analysis and good-old-fashioned trial and error and play-testing. Fascinating, I know. Want to see charts and graphs and tables? Yes? Too bad.

We want it all -- a great-looking game that runs well all the way down to our min-spec hardware, with a solution that doesn't take 4 years to develop and perfect. Currently, we use a hybrid lightmap approach. For outdoors, we pre-generate a lightmap containing local lighting information (streetlamps, etc.). Then, at load time, we calculate (hopefully, in an efficient manner) global lighting like moonlight and shadows and add it to the original lightmap for that chunk of the environment. This has given good results and makes our hellish rendition of London seem to have the unifying coloring and shading that we're all accustomed to seeing in conventional fixed-layout game levels.

Is it good enough? One thing we lose is the great look of normal mapping of diffuse lighting on the backgrounds. That is, when looking at a cobblestone road away from any active "dynamic" lights, we don't see the "bumpiness" we'd expect from the moonlight shining down. One option is to pull some lights out of the lightmap generation step and run it in real-time on high-end hardware. In addition, it's worth further investigation into some of the hybrid light-approximation function (so-called "basis-function") techniques.

Newer techniques like high-dynamic-range (HDR) rendering and parallax-mapping have our artist-savants gnawing at the bit. As we consider adding support for these features, we have to take into consideration how long they will take to add, what they will bring, how many eventual players can use them (does it have a good fallback method for cards that aren't top-of-the-line?) and the all-important issue of frame rate.

If ever the frame rate drops below a certain threshold during development, the onus is on the graphics engineer to prove it isn't graphics causing the slowdown (maybe physics or AI) or fix it, if graphics code is indeed at fault. In that way, the graphics engineer in a small development team like ours becomes the chief performance engineer as well.

I spend a lot of time profiling the game both for video and CPU performance. My goal is to keep the balance of features, cost and workload between processors in a Happy Place(tm). Every feature has a cost, a minimum hardware spec, a fallback method and a visual or performance benefit. For example, consider full-screen distortion effects like heat shimmering. Their cost is almost purely in pixel shading and texture and framebuffer bandwidth (transferring pixels to and from video memory). That means on computers with really high-end video cards where the CPU is the limiting factor, they are essentially free. Conversely, on the machine with an average video card where pixel-pushing is the bottleneck, they can be incredibly costly. A fallback for those cases would be a cheaper effect (perhaps reducing the number of passes on the effect or using a simple texture lookup in place of more interesting and complex per-pixel math) or getting rid of it altogether. The min-spec would obviously be defined as the point where the technique is unusable. If that's too high and the benefit of the effect is too low (say, it's only used on a tiny stained glass window high up in a wall that you never get close to), it may be dropped in favor of an effect with more bang-for-the-buck.

And behind all the glitz is a massive framework of functions and containers for storing, sorting, processing, converting and eventually using the huge -- no, monstrous -- truckload of data coming from the artists in the form of textures, models, animations and settings. Many fundamental requirements for real-time performance involve organizing this data in a way that can be accessed as quickly as possible for the task at hand. When we built our first outdoor level, the data structures that worked indoors couldn't cope with the hugely increased amount of visible objects and terrain. Now, our engine handles removing invisible data (culling) in outdoor levels in a way totally different from the indoor (underground) levels. If we had a jet-piloting game, it would be different still. A lot of the commonly-accepted approaches to culling rely on pre-computing visibility between objects. Remember the random levels? They sort of take a demonic flamethrower to those particular approaches. Then they laugh.

Also, the viewpoint of the player strongly influences what's visible and therefore how the culling systems operate (and where they break). We have both 1st and 3rd person camera modes. Levels that run fine in 1st person may choke on 3rd because of the elevated camera or the way you see ALL the enemies surrounding you, not just the ones in the front 90 degrees or so.

Definitely, our random level layout design flies in the face of some of the technical "best practices" for real-time graphics development. Grouping nearby objects to render together only works when you know they're near each other. We don't want to turn the level load (however it takes place: as a load screen, hallway or streaming) into a prolonged pre-compute phase. Keeping that in mind is an yet another input into the feature-selection and -implementation process.

I haven't even touched on the random character variation (monsters with damaged armor or different tattoos, for example) or the huge list of items. There are so many items, in fact, that we don't create thumbnail artwork to fill inventory slots. We instead render the items (using special environment, camera and lighting settings) into a special "thumbnails-only" texture when they are added to the player's inventory. That's just another of the dimensions of complexity we find when randomness is the rule.
Hellgate: London is definitely a different breed of game. The technical challenges arising from our design make for a game that's almost as fun to write as it will be to play. I, for one, can't wait.

Source: http://pc.ign.com/articles/610/610199p1.html