Making Games

I hear from programmers every now and then who are considering trying to get into the games industry. Our projects are strange beasts that are similar to other software projects in some ways, yet vastly different in other ways. Still, if you look at it from outside, most of these differences will be hard to spot.

With this post, I will try to list what I see as the biggest differences between working on a game and working on a different kind of software project. If you have any questions related to it, please post them as comments and I’ll do a follow-up round.

The Passion and Dedication

It sounds like a cliché, but games are made by mostly gamers. In all the teams I’ve worked with spanning maybe a hundred, there’s only a few people that aren’t absolutely passionate about games, and completely dedicated to making kick-ass entertainment.

The enterprise coders I’ve worked with pretty much fall into two categories: the day job coders who don’t care much and the hackers that appreciate technical challenges. As you move into games, not only does just about everyone fall into the second category, but nearly everyone is also excited about the games themselves, regardless of the technical challenges involved.

If you’re looking for a place to work where your colleagues will be really cool, skilled people with a passion, then the games industry is where to look.

On a cynical note related to that, the abuse of this passion and dedication is what has given the games industry something of a bad reputation (and a well deserved one too). My impression is that working conditions have improved quite a lot across the board, even if there are still the occasional horror stories. If I were to give one piece of actual advice, it’d be to be rather thorough in your background checks on companies.

Creativity

Game developers live off creativity. Even the most simple churn-out-sequels factory will attract highly creative people, and studios will tend to cater to creativity to a much higher degree than most other software development companies.

If you’re highly creative, you will probably find it easy to fit in. My experience is that creative suggestions are almost universally appreciated regardless of source.

Cross-discipline, Bleeding Edge Development

Games teams are made up of a number of disciplines that vary depending on what type of game you’re making, but generally speaking you’ll at least have Designers, Graphical Artists, Animators, Sound Designers and Programmers. Our projects have Mission Designers, Environment Artists, Effects Designers and other disciplines as well.

In a way, this is no different than many other types projects where some end-users create some of the data for the system, but there is a major difference in the fact that the hardware platforms are either consoles or PCs with specs so high that they don’t even exist yet. The coders on the team will be creating a game framework, which is then populated with different kinds of content to produce the game.

The problem with this is that they’re using the software tools you’re building (like the editor and data processing pipeline) to create the game while you’re still trying to build the tools, only to run it in a game engine that is also not done yet.

It’s a bit like trying to produce a business application while part of your team is working on creating the source code editor you must use, and a different part of the team is building your compiler. In some magical way, the components must all mesh together so that not only are the tools done when it’s time to ship the product, but that content creators have time to do something useful with them as well.

This creates an extra layer of complexity to the projects that I haven’t seen anywhere else. Inter-discipline dependencies between disciplines that work in very different manners can cause common project management techniques for software development to break down, because most of the team isn’t developing software.

Performance Focus and Hardware Platforms

From a technical point of view, there is a heavy focus on code performance. This creates a different kind of environment, where some modern programming techniques are simply too expensive to use. It also means you tend to get good at optimizations after a while.

The hardware we run on is increasingly becoming paralell. Using all of the power in the PS3, for instance, requires a fairly well developed parallelism, forcing the shift from single-threaded to multi-threaded coding onto game programming long before most applications need to care all that much.

(Note that my view on the state of the industry is rather limited here. DICE is ahead with the Frostbite engine on current console tech, some other engines are hopelessly behind, but it’s always hard to tell what others have in development.)

The hardware platforms themselves can sometimes be immature and cause problems when you have to jump through hoops to get things working (simple example: graphics driver bugs).

The platforms themselves also impose other restrictions on your code, like the low memory cap of current generation consoles and extreme penalties for cache misses and branching.

Playing Games at Work (!)

I couldn’t leave that out, could I? Yes, we playtest our games at work. They’re a lot of fun, most of the time, so getting to play awesome games before anyone else is quite a perk. To be completely honest I must admit that there are times when it’s not much fun at all… but they are quite uncommon. And hey… you get to shoot your boss.

Some Battlefield News

I’ve been busy lately with a whole host of things, among others a presentation at a DICE event on the subject of Design Fundamentals. I’ll see if I can get back to you more on that later on once I’ve held the presentation and I’ve got a few posts I’m working on, but it’s slow going right now with everything going on.

I missed the link run this weekend, but for now, here’s a bunch of Battlefield news that are going around. Starting out with the one that has everyone excited:

• Yes, we’re working on Battlefield 3.
• No, we’re not telling you more than that. Do appreciate all the excited comments though, just don’t have any more information for you at this point.
• My colleague Demize99 has started to blog over at battlefield.com, starting out with a post about medics in BC2. Must-read, and I love the class.
• Inside XBox did an interview with Patrick Liu, producer for Battlefield 1943, about the game out soon on Playstation Network and XBox Live Arcade — asking, “is this really an arcade title?“

A Tour of the Games Studio

There’s a hole slew of misconceptions and weird comments that inevitably go around as soon as any large game studio announces a game, or releases a game, or… well, just about anything else. So with this post, I’d like to welcome you to a small sightseeing tour of how a games studio works, on the inside.

I hope to give you a chance to see how a games studio works — maybe it’ll create better understanding of what it is you’re saying when you chatter around forums about the latest greatest game from some studio, or maybe it even gives you valuable insight if you’re looking to get into the games industry.

The Myth of the A-Team and the B-Team

Somewhere in the DICE Office

As soon as a game announcement turns up, knowing fanboys will appear on all forums around, claiming grand things like “Wow, this sure is great. Now we know DICE has the A-team is working on this while the B-team was doing (other title here).” Substitute with “good team” and “bad team” or whatever you will.

The reality is not only that there isn’t any first or second-rate teams, but that the teams themselves don’t really exist as a concept. People move between teams constantly — some project doesn’t need any more audio work now, so the sound designers move over to the next one. Meanwhile, the programmers are fixing the remaining bugs and getting set to ship the game. Most of the artists left the project before that.

That means that there’s rarely a situation where a team in a large studio makes one title and then immediately goes on to make another one — more likely the team will split up and head to other projects. Some may jump on to help another project get the final bugs squashed, others may jump on to prototype a new game.

The Life of a Game Project

That leads us to the life cycle of a games project, because another misconception is that the team making a game will remain the same group of people all the way through.

A project generally starts out small. A few designers basically start up by spending some time trying to answer the simple question of “What game do we want to make?” Sometimes this is more straightforward than other times — but more often than not it is somewhat complicated and difficult. Even sequels usually start out in a state of “don’t really know what this is about”.

There’s this nice thought many people have about games as having this brilliant idea first, and then just making the game. This never happens. The project will probably get to some kind of rough concept of what they want to do, what kind of technology platform to use, what setting, and so on… and then go into pre-production.

The pre-production phase of a project is when the project starts taking on more people. Coders join, artists join, and most probably more designers join. The mission now becomes trying to prototype, test and prove all the different aspects of the game — figure out the core game mechanics, make art target concept environments, make sure all the tools needed work properly. The goal is usually to build a small section of the game as a proof of concept.

The project has probably been running for at least six months by the time it finishes pre-production and heads into production. It staffs up even more, and sets about building all the levels, missions, features and content needed for the complete game. The amount of time it takes to do this varies wildly depending on the game.

Still, through production concepts are refined. As playtests are done, the developers think of new ways to improve the game, and the new ideas are worked into the concept.

What You See Is All There Is?

By the time you hear of a project, it’ll generally be in production. Conceptual prototyping is relatively cheap, so studios can afford doing concepts for games as a test, and if they don’t turn out well then cancel the project. This means that at any time, your favourite games studios out there are probably doing cool stuff you have no clue about.

This way of doing things also means most views on the state of a game are somewhat flawed. By the time a game hits beta and you get to see it, it’s virtually completed and only bug fixing remains. Comments like “well this is an early beta, they’ll change lots of stuff” are quite common and somewhat funny to see — very few game changes will be done once a game is in beta.

That doesn’t mean quality doesn’t increase though — much of the quality you see in a game comes from the actual fixing of bugs, not the adding of features.

“Not that the devs are ever gonna care”

Gamers tend to show a pretty large dose of resentment towards game developers. In general, what you see is an announcement met with awe and comments like “this’ll be the most awesome ever”. This attitude then changes over time, until at release, the comments tend to sound more like “they messed it up”.

A strange aspect of this is that many gamers seem to be deep into the belief that game devs don’t care about them, about the games they make, or about anything at all other than earning a quick buck. This is strange because the games industry is not the place to go to make the good money while slacking — it’s generally a grind of long hours of dedicated work and not as well paid as other comparable areas (making business apps is definitely much more lucrative for a programmer).

Yet people still do it? Why? Because these people are gamers and love what they do. Maybe somewhere there are big-name execs that don’t care, but I haven’t met them yet. I’ve only met the EA execs who beat half the dev team on Battlefield: Bad Company (though dogtagging your boss is sweet indeed).

That’s all part of what makes the games industry such a great place to be if you love games — not only do you get to work with games, you get to work with gamers.

Yet most people seem to think that game developers isolate themselves in a small glass jar somewhere, and start ignoring the internet as soon as their project becomes public. Nearly every forum or blog post about a game has a bitter comment about “no chance the devs will bother to read this”.

Guess what — we do read stuff on the ‘net. Not only because we’re gamers but because we care deeply about making the best game possible. So why don’t we answer? Well, I think you could imagine what’d happen. Half the people would call you a liar, and the rest would bombard you with even more. There’s no way for a game developer to answer questions or opinions on a forum without immediately being subjected to at least twice the amount of new questions or opinions. We’d simply run out of time.

And well… at the end of the day, we have games to make.

For my own part, I’m more connected than most. Toss me a line on twitter if you have a question.

Sunday Link Run

A bit of a rush this weekend so I haven’t been able to finish the blog post I was hoping to post. Here are some links to keep you occupied for a bit though… I hope I’ll be able to post a full post the next few days.

• E3 has come and gone. I could link to a million things from there, but I’ll restrict myself to one: The Star Wars — The Old Republic trailer. That is one serious piece of awesome right there.
• No, one more E3 mention actually: You will burn in hell for pretending to burn in hell.
• In other game news, the new Red Faction seems to be a good game.
• On the subject of MMOs, Jeff Vogel posted an interesting article about addiction-based game design and Eric at Eldergame posted an in-depth article on the health of the MMO industry.
• Sad news: Fantasy author David Eddings is dead.
• Here’s a concept display of a new kind of interface, used entirely without clicking. I’m not sure if that’s the way of the future, but it’s interesting.
• Алёна C++ made this awesome map of C++. Goes pretty nicely with xkcd’s map of the online communities from a while back.
• Speaks for itself: some beautiful world records.
• And the asshole of the week (frightening how easy it is to find these): the guy who thinks he owns the word “edge”, and likes lawsuits about it — Tim Langdell.

Deleting Code

I came upon an event handling function a year or two back. It was late, there was a crunch going on, I was tired as hell, and I needed to figure out what it did. Here’s something like it (or see the whole thing if you can’t read it in this format):

void EventHandler::handleEvent(const Vector& eventPos, const Transform& objectTrans, Object* sourceObject, int sourceId, float time)
{
    if (sourceObject && sourceId != -1)
    {
        Actor* sourceActor = getActorFromId(sourceId);
        if (sourceActor)
        {
            // Event was fired by an actor. Accumulate data in the actor's memory about how much firing strength it has fired.
            // Get information about source weapon.
 
            Object* actorVehicle = sourceActor->getPlayer()->getCurrentObject();
            Armaments* actorArms = actorVehicle ? (actorVehicle->getArmament()) : 0;
            int weaponId = actorArms ? actorArms->getActiveWeaponIndex() : -1;
            if (weaponId != -1)
            {
                if (actorArms)
                {
                    Weapon* weapon = actorArms->getWeapon(weaponId);
                    if (weapon)
                    {
//                        if (weapon->getExplosionRadius() > 0)
//                            sourceActor->getMemory()->setTimeOfEvent(time);
 
                        // Get information about target, and bots memory of target.
                        ObjectProxy currentTargetHandle = sourceActor->getMemory()->getTarget();
                        Object* currentTarget = currentTargetHandle.get();
 
                        // Always deal with primaryObject
                        if (currentTarget && !currentTarget->isPrimary())
                        {
                            currentTargetHandle = currentTarget->getPrimaryObject()->proxy();
                            currentTarget = currentTargetHandle.get();
                        }
 
                        const SensingData* currentTargetSensingData = sourceActor->getSenses()->getSensingData(currentTarget);
                        if (currentTarget && currentTargetSensingData)
                        {
                            ASSERT(0 <= weaponId && weaponId < 8, "Illegal weaponId: &u", weaponId);
                            //DEBUG_OUTPUT("FiringStrength accumulation for weaponId %u... %f\n", weaponId, cyrrentTargetSensingData->typesFired
 
[weaponId];
                            int targetType = currentTarget->getType();
                            if (targetType <= 3) // Lighter types
                            {
                                //for (int strType = targetType; strType <= 3; ++strType)
                                //    currentTargetSensingData->typesFired[weaponId] += weapon->getTypeValue(strType);
                            }
                            else if (targetType == 4) // Other type
                            {
                                //currentTargetSensingData->typesFired[weaponId] += weapon->getTypeValue(4);
                            }
                            else if (targetType == 5) // Third type
                            {
                                //currentTargetSensingData->typesFired[weaponId] += weapon->getTypeValue(2); // Other type
                                //currentTargetSensingData->typesFired[weaponId] += weapon->getTypeValue(3); // Other type
                                //currentTargetSensingData->typesFired[weaponId] += weapon->getTypeValue(5); // Third type
                                /*                                ObjectProxy victimHandle = targetObject->getVehicle(sourceActor->getTeam());
                                SensingData* spottedObj = sourceActor->getSensingDataFromHandle(victimHandle);
                                if (spottedObj)
                                {
                                spottedObj->fireSuccess += 1;
                                }*/
                            }
                            //DEBUG_OUTPUT("...became %f\n", currentTargetSensingData->typesFired[weaponId]);
                        }
                    }
                }
            }
        }
    }
}

There are lots of things I could say about the quality of the code… but it’s late, there’s a crunch, I’m tired and… what does the function do? I’ll let you think about that for a bit. You can safely assume that functions don’t have side effects.

Many people focus almost exclusively on writing new code. Some people even stay away from deleting code — instead simply commenting things out. As you see above, this makes the code extremely hard to read. Also, the commented-out code doesn’t work anymore. With other changes, the compiler no longer checks this code for errors (for instance, some of the commented-out functions had been removed entirely).

This also misses the entire purpose of having source control in the first place! If you want the code back, go check it out in perforce, subversion, cvs, or whatever source control system you’re using. If you’re not using a source control system… well you have bigger problems than commented code.

For all there is to be said about writing code, often the best thing you can do is delete some code. Delete the code you don’t need — delete the extra pieces that are in the way of working with the code efficiently.

I once took over ownership of a code base, and the first thing I did was strip nearly half of the code out in form of unused support code, unnecessary interfaces and adaptation code for layers that no one wanted or needed and code that was simply so bad quality it was better to rewrite than to maintain them.

So… what does the code do? Cookies for the first commenter with the right answer.

(Disclaimer: the code above is not exactly the code I found… but it matches in form, and is similar enough to make the point)

Update: Added a link to the code as a separate file so you can view it without the scrollbar headache.