Read an Excerpt
Distributed Game DevelopmentHarnessing Global Talent to Create Winning Games
By Tim Fields
Focal PressCopyright © 2010 Elsevier Inc.
All right reserved.
Chapter OnePreface and Overview
Some time over the last 15 years, the geeks won. Bill Gates became the richest man in the world, at least for a while. The personal computer moved to the center of private life for hundreds of millions worldwide. The planet got wired, got flat, and got an e-mail address. Most fun of all, games moved from being a marginalized form of entertainment at the fringe of social acceptance to being mainstream. And beyond mainstream, video games became cool, no longer just the province of the stereotypical outcast adolescent male. Consequently, video games became delightfully profitable.
Hand in hand with this rise to popularity, our entertainment software has become more complicated. Gaming hardware, from PCs to high-end consoles, has become more powerful, and the types of content have become much more involved. Gone are the days of single textured polygons or even basic hardware shaders. Simple LAN-style multiplay is long gone too, and an escalating war of feature brinksmanship is leading to ever more sophisticated ways to play. Input mechanisms have become more varied and sophisticated, with motion-sensing devices like the Wiimote and those fantastic little plastic guitars opening up new types of game-play to all new audiences. The proliferation of mobile phones capable of running complex software has created new markets for casual gamers who don't even own dedicated high-end hardware. At the same time, our users expect ever more accessible interface models, better matchmaking that is more transparent as well as more accurate, and so on. Finally, the profusion of different platforms, from PC to handhelds, means that it is no longer enough to build a great game on one gaming system. To reach massive commercial success, it often needs to be built for six or seven. As if all of that weren't enough, the marketplace has become so crowded (because of the delightful profits I mentioned previously) that you need to have brilliantly marketed products. Moreover, all versions of those products need to simultaneously hit store shelves on the same day so you can get the most out of those brilliant marketing dollars. Beyond that, you'll need to have downloadable content, expansion packs, and sequel or franchise plans in place so you can ensure that your hit game isn't a flash in the pan but instead starts a franchise dynasty that will have your investors rolling in the Benjamins until the next ice age.
1.2 how Is a team Leader to Juggle all of this?
Luckily, a few things have evolved to make this daunting task a little easier. First, the software tools we use to create games have gotten better – a lot better, in fact. From modern versions of 3d packages such as Maya to middleware such as Havok or Gamebryo and the software development kits that we use to interact with console platforms, our tools are just plain better, Our defect tracking software has improved, as has the server hardware and the version and source control software. Moreover, there are many more professional game developers now, and our methods of communication have become much more varied and powerful. Gone are the days of firing up a dial-up modem and logging into a BBS to ask technical questions. There are thousands of websites devoted to helping engineers ask questions and wiki-type collaborative projects that serve up vastly better documentation than was common a decade ago.
Finally, our organizational processes have become more advanced. First, we've embraced a level of specialization in many roles (physics engineer, rigger, CG Sup, lighter, etc.) that would have been unheard of when all game developers were expected to be generalists. Second, we've refined some of our management roles and added a layer of facilitators such as development directors and associate producers. Teams can grumble about the introduction of these kinds of middle management roles, but it seems clear that when used properly, they help reduce friction, increase communication, and make possible the feats of coordination required to deliver top-selling titles in such a complex marketplace.
Perhaps the most sweeping change to the way we organize ourselves to facilitate the creation of entertainment software is a process that has only recently come online. It is widely remarked that the world has become "flat." Advances in communication, the opening of global markets, and the widespread adoption of English as the lingua franca assist an educated class that can collaborate across borders regardless of distance or time zones.
To be fair, "collaborate" is my word. And It's chosen to frame our subject in the appropriate light from the outset. Unfortunately, too much of the discussion about our new flat world has centered on fear mongering about lost jobs and discussions of the perils of outsourcing. Although much of this seems to be little more than political pandering in the developed world, it does speak to a greater truth: The ways in which we can turn the world to our advantage are often ill understood. An educated, global workforce with the tools of communication that allow them to collaborate can be used to benefit most industries. The creation of goods and services, like gaming software, is not a zero sum game. It is possible to make better products, more efficiently, which reach broader markets, and delight a wider range of consumers, if the power of distributed collaboration can be effectively harnessed. We can increase the number of jobs, make better games, and all make more money than we have in years past if we can embrace the options we have available.
In particular, we're going to spend the next few hundred pages visiting about how to harness the global talent pool to create winning games – games that exceed sales expectations, games that thrill our customers, and games that help build sustainable franchises and make a lot of money for our investors and, it is hoped, for you.
This is a book about the organization of teams – about how to make use of a wide, flat world of resources and eager developers in order to accomplish the daunting tasks described previously.
Approximately 15 years ago, I was handed a book on software project management by one of my bosses, software guru David Stafford. The book, the venerable Debugging the Development Process by Steve Maguire, is one of the bibles of software development, published at a time when Microsoft Press was working hard to create a world in which a lot more people would understood how to develop professional software for Windows. In the book, Maguire used the metaphor of the software project as a large truck. This big rig is moving, ideally moving fast, and has to be somewhere that (hopefully) everyone has agreed upon in advance. As a leader of this project, it is your job to ensure that the truck does not encounter any roadblocks, does not run out of gas, is not broadsided by another giant truck that wants to monopolize the same section of road, and so on. To extend the metaphor, Maguire likens the software project leader as a member of an advance crew who goes ahead of the truck, looking for likely obstacles that will slow or stop its progress and radioing back course corrections to the folks with their foot on the pedal. I have always liked this metaphor and thought it nicely described the way one should approach software project management.
Only now, things are different. With projects of the complexity we've discussed previously, and a world in which you can and should be distributing the workload among several different teams, your job is more akin to that of central dispatch, or an air traffic controller. To deliver complex entertainment software on time, across a variety of platforms, in a host of different languages, to a bunch of varied markets, all on time and on budget, you need a fleet of different trucks, each manned by capable drivers.
This book will teach you how to direct them all effectively.
1.3 Who Is this Book For?
There are still some games that do not require any sort of distributed development. Let's say that you're a member of a small team building a free web game. Let's imagine that you're all in the same physical space, a small office maybe, and you aren't planning any particular marketing or QA process for your title, outside of what can be provided by friends or a few local testers. You don't have a publisher – you're self-publishing. You're on the smaller side of indie, and you're comfortable staying that way. If this describes your team, then you likely don't need this book (though I'd hope that you still might find it illuminating, if only to see how big and complex the machine can get). Otherwise, if you are involved professionally in making games that you hope will reach a large audience, you'll be interested in what we'll be talking about here.
Specifically, however, this is a book for project leads or those who hope someday to become project leads. It's for the harried executive producer at one of the top publishers – Activision, Microsoft, Electronic Arts, Tencent, Ubisoft, THQ, or similar – who has just finished another game and can't help but think that there must be a way to bring a little sanity to the process. It's for the development director helping keep a team alive at a small development studio doing work-for-hire for its publisher. It's for the art director of an art outsourcing house. It's for the motion graphics expert at a video production company's gaming division. It's for the lead designer trying to ensure that her vision, her baby for all intents and purposes, gets properly translated across to even the handheld version. It's for the marketing product manager who is trying to get a grip on how to help the development team create a more predictable process and a better Metacritic-rated game.
This is also a book for teachers and students. If you are a student of the games business or in an rTF program who wants to understand more about how modern games are built – and how to find your niche in this fascinating, profitable, dizzying industry – I believe you'll find a lot here. It's also a book for teachers: My goal is for this book to serve as a backbone textbook for courses on production.
Finally, this is a book for investors. If you are one of the millions of people who owns stock in a company that derives profits (or seeks to) from creating games, then this book will teach you a lot about how games are made and how to evaluate what's really happening behind the glossy press releases.
Although this book deals with team organization and the best practices for running software projects at a fairly advanced level, I endeavor to explain industry jargon as clearly as possible for those who are not already familiar with it. If you've never worked on software before, just hang in there – there's a lot to pick up, and you'll likely be amazed at how complex it all gets. But then, the inside of a sausage factory never has been a pretty place. By the time you've finished the tour, however, it won't seem so foreign. Now here's your hardhat. Let's proceed.
1.4 preamble on Distributed Development
1.4.1 Why Would I Use Distributed Development?
There are dozens of reasons why different teams find themselves using a distributed model. It can be a load-balancing technique for larger companies that need to find work for their teams temporarily between production phases. Or maybe there are possible synergies to exploit between different teams using similar technology. Alternately, distributed development can be a great way to allow smaller companies to avoid the burden of carrying too many full-time staffers.
Any time you've got a project that is meant to hit store shelves simultaneously across several different platforms (Xbox 360, iPhone, PS3, PC, PSP, Nintendo dS, and so on), you're likely to need some level of distributed development. If your project is tied into a movie license such that you're coordinating with a Hollywood studio, then you're likely distributed. Also, if you're working with a publisher of almost any size, then you're probably distributed to some degree (even if it's just your localization, QA, marketing, or sales departments that are located elsewhere).
Ultimately, however, there seem to be two main reasons to use distributed development:
To get the best people and teams on the job
To save money
Since the latter can be a nice side effect of clever resource organization, I strongly suggest focusing always on the former. Racing toward the bottom almost never gets you a great product, and poor products seldom create the kinds of long-term sustainable franchises that generate real revenues. Focus on using the techniques in this book to get the best minds on the planet thinking about how to make your game great. If you do this, the money will follow.
1.4.2 So You Don't Like Outsourcing and Think It's a Bad Idea
While having lunch with a young designer recently, I mentioned the ways in which a current project of mine was working and discussed my plan to write this document. His response surprised me: "I don't like outsourcing, or working with remote teams. I'm not sure teams should do it."
What surprised me wasn't the attitude; many people are afraid of job loss, of losing control of a project, or just afflicted with plain old xenophobia at the thought of having to collaborate with people in a distant land. What surprised me more was the idea that anyone believed that using some type of distributed team was optional.
Make no mistake. We are now firmly in the era of distributed, collaborate development and production. Personal preferences do not much enter into the question anymore. For projects of even a modest size, the question for you isn't "Will I have to collaborate with some external teams in order to succeed?" The question for you is "How do I ensure that this collaboration results in a better end product and more effectively meets my parameters for success?" There's no "if," only "how."
According to a 2009 article from Gamasutra, the online arm of Game Developer magazine, 86% of teams polled reported using some form of externalized development, and 20% of those projects polled spent more than $2 million on an externalized component. In some cases, these may have been traditional outsource deals. In many other cases, these are likely already distributed development deals of the type with which this book is concerned.
The world got very flat within the past decade, whether you were paying attention or not. The winners in the next century are not spending today debating about whether or not they should be collaborating with the best people for the job, regardless of geography. They are investigating how to best overcome the obstacles that have historically made this kind of collaboration challenging.
This document is not an attempt to convince you to collaborate with external or remote teams. I sincerely doubt you'll have a choice if you want to build the best games possible. Rather, this book will share with you some best practices for how to collaborate effectively, through a frank discussion of the process and its pitfalls, and through sharing the thoughts of a number of individuals who have integrated such collaborations successfully into their game development process.
1.4.3 The Difference between Traditional Outsourcing and Distributed Development
It's critical that we draw a distinction between two fundamentally different development practices. "outsourcing" is when your team takes a known group of tasks and hires a subcontracting company to perform those tasks, either once (e.g., model and texture 60 background items based on these technical specifications) or in a recurring capacity (e.g., answer the phone and run callers through a branching script in order to collect and fill their orders). Outsourcing is a fine technique for well-known types of problems and tasks, in which substantial documentation or scripts and defined procedures already exist. This type of development is also best suited for cases in which quality is either not particularly important or a final polishing phase can be completed by someone from home, later in the development phase. It's not that a traditional outsourcer cannot hit a high-quality bar; many are superb at what they do. However, traditional outsourcing does not work very well in cases in which iteration is required to achieve the necessary quality.
"Distributed development" is when a collection of individuals or teams not geographically co-located collaborate on a project composed of a collection of tasks, some of which may not be fully understood. This might be for a video game project in which there are a few dozen engineers in one place and an art team in another. It might be a short film in which the dailies shot in Los Angeles are sent off to a post-production house in Dallas for color treatment. It might be a Facebook gadget where the programmer working on the features is collaborating with a content team at a major publisher. In all of these cases, there are numerous research and development components of the task, as well as a relationship between collaborators that stretches beyond a traditional contractor and client relationship. distributed development management methods are designed for these types of tasks that require autonomy, creative decision making, and lots of iterative cycling toward quality.
Excerpted from Distributed Game Development by Tim Fields Copyright © 2010 by Elsevier Inc. . Excerpted by permission of Focal Press. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.