Tyler Thompson talks about programming Hellgate: London @ PC.IGN.COM

Staggering zombies, explosive fireballs, super-jumps, and lightning shotguns. The game programmer gets to play with everything. We combine all of the art, sound and code to craft an experience for you to enjoy.

This brings me to the topic of cooking. Yes, cooking. I love to cook, and like most people I find parallels between my hobby and my profession. So, indulge me for a little while as I point out how being a game programmer has some similarities to being a chef.

Chefs design a combination of flavors, prepare various ingredients and combine the results to produce a final product for people to enjoy. Similarly, I design gameplay features, prepare art assets so that the game can use them, and combine them with careful timing and placement to create a game experience.

Like any good chef will tell you, it is all about having high quality ingredients. It takes great tomatoes and bread to make a good bruschetta, and tapenade is all about the olives. Similarly, as game programmers we rely on artists to make the animations, meshes, sounds, particle systems, and backgrounds. Their quality is what makes a game sound wonderful and look beautiful.

There are many dishes that require a skilled cook. Crème Brule requires combining the right amount of liquid to egg and cooking things slowly for just the right amount of time. It takes a skilled game programmer to make an interesting monster which moves believably, makes you change your tactics as you fight it and feels challenging while not being too difficult.

Okay, enough about cooking. Thanks for going through that with me. It means a lot to me.

So, what do I do each day? Knowing that I was going to write this diary, I started paying attention to where all of the time goes. I attend meetings, program, answer questions, and ask for things. Attending meetings is my least favorite of these. (Ironically, as I write this sentence, I am getting called into another meeting.) The meetings are like Death in Gauntlet -- avoid them or they drain your life. They suck away time and keep you from working on explosions and zombies -- which is where all of the fun is. Luckily, most people at Flagship Studios have an aversion to meetings. We have very few of them, and most of them are short.

Let's walk through the fun things that I do with my day. First, let's talk about programming. I write code for the game logic and the tools. Tools? You thought that we were making a game here -- not some Windows app full of buttons, sliders and graphs? Yeah, you see, a couple years ago game programmers got clever. We stopped writing hard-coded tables that define how everything works in the game, and we started making programs to create and read this data for us. Now, we hand these tools over to the artists and designers. We let them adjust the Shock Blade's damage, the timing of the Hellmeat's melee attack and how the Orbile bursts into chunks when it dies. We also write the logic in the game that uses all of this data to help draw and simulate stuff: monsters inform their buddies when you hurt them, some missiles can bounce, and electricity damage will stun a monster.

So how does all of that work? Here is a simplified example. The lead designer, Erich Schaefer, asks me if we can have the HARP's laser beam lock onto its target so that it still hits them even when you are not pointing directly at them. He and I talk about it for a while and we decide that the laser should come straight out of the gun, but bend towards the target. I return to my desk. The first thing that I do is add a button in our skill editor, "Laser Bends." Then, I run the tool, open up the skill editor, select the HARP's skill file, find the laser event, click that new "Laser Bends" button and hit "Apply." (Does the laser bend now? No! I wish it were that easy. All I've done is let the game know that I've set some flag.)

Now I have to do the hard part. I have to change some logic so that the particle systems code can draw a bending laser and make the game logic realize that the laser can bend. I won't go into the specifics here, but let's just say that the particle code often requires some trial and error, and the game logic requires some careful consideration. I spend a lot of time writing, compiling, testing things out in the game, and scratching my head. When things look like they are working, I go talk to our particle artist, Max Schaefer, and explain to him how the tool has changed so that his laser particles can bend.

In fact, I have changed the HARP's laser particle so that it bends, and I show him how I did it. Now he can make it look better than my weak programmer art. So, now the HARP's laser bends, but more importantly we have a way to bend any of our laser weapons. Since I changed the tools as I wrote this, it was pretty easy to make the Incinerator Ray and the Arc Lasher bend their lasers.

(Now for a quick aside: As I've been describing the process here, I've been mentioning the name of several weapons, monsters and skills. Please realize that these are the Development Names. At some point in the process someone will come up with a better name for the Arc Lasher - I think that Zeus Rifle is the current favorite. This Release Name is what users will see in the game. However, we keep changing our mind on the Release Names. This week is it Zeus Rifle, but next week it might be Lightning Arc Machine or Zapper. I can't keep up with all of these changes. It gets really confusing. So, I just stick to calling things by their Development Name.)

This all makes it sound like the game programmers just make the technology, sit back and watch it all get assembled. This is hardly the case. Since we write the tools, the game programmers are the ones that know best how to use them, and we use them more than anyone. Although in theory anyone could create an AI for a monster with our tools, only game programmers end up making them. Although in theory anyone could make the Firebolter launch missiles that explode on impact, game programmers sketch it in for the first pass. The main advantage of the tools is that the artists get to add, tweak and change the stuff that we sketch in.

This power in the artist's hands generates a ton of questions. "Do I need to separate the end of the Blaze Pistol so that it can come off?" "How do I make it play a sound when the Hyper Slicer's missile bounces off of a wall?" "The Templar's run animation doesn't move his hips, and I don't see why." Since we have created all of these tools for people to modify the game, there are often questions about how things work, why they don't work, and how they could be changed.

This is where interpersonal skills/flaws and problem solving come together. So when searching for game programmers, we typically don't hire introverts who prefer to work in a closed room and have pizzas passed under the door. You have to be able to discuss, debate, consider and cajole without upsetting people, and you need to enjoy doing it.
The most valuable phrase that I've learned in the last couple years is, "Let me think about it." For a long time I thought that we needed the answer to every question at the instant that it was asked. If I couldn't figure out an easy solution in the first few moments, then there wasn't a good solution. If there wasn't a good solution, I had to convince the person that what they wanted wasn't worth doing. That was bad. I was crushing people's ideas all of the time.

People don't like to hear that their idea can't get in the game, and it just wasn't always true. Given some time, rest and good green tea, I often can figure out a clean way to solve many problems that seem difficult at first glance. Sometimes it just takes some time to find the answer or even a better question with a great answer.

The final thing that I do with my time is ask for things. "The Zombie needs three get up animations." "The Cluster Rifle's muzzle bone needs to be moved up a little bit." "We need a particle system for when the player is on fire and using the first person view." There are so many different assets required to make a modern game; so many little details that need to be taken care of. This is why it is taking so much time and money to make a modern game. Each game has millions of details to take care of and thousands of assets to make. Take for instance our zombies. In total, they use 28 textures, 24 animations, 46 sounds, 2 meshes, and some dripping blood particles. Sometimes, when an artist says that a monster is ready to go into the game, it has all of the ingredients that it needs, but most of the time there is something missing, forgotten, or incorrect. So, I make a few requests each day.

Like a chef's goal is to make food with good texture and tastes, game programmers try to make a game that is fun. It sounds a lot simpler than it is. Crafting an experience requires paying attention to the details, keeping focused on a vision, encouraging unexpected surprises, and correcting bad results. Game programmers may not make all of the ingredients, but we are right there in the kitchen preparing, tasting, testing and correcting things all along the way.

Source: http://pc.ign.com/articles/654/654720p1.html