Instant Ebook Access, One Click Away – Begin at ebookgate.

com

Distributed Game Development Harnessing Global

Talent to Create Winning Games First Edition Tim
Fields

https://ebookgate.com/product/distributed-game-development-
harnessing-global-talent-to-create-winning-games-first-
edition-tim-fields/

OR CLICK BUTTON

DOWLOAD EBOOK

Get Instant Ebook Downloads – Browse at https://ebookgate.com

Click here to visit ebookgate.com and download ebook now
Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Learn Unity 4 for iOS Game Development Create amazing 3D

games for iPhone and iPad 1st Edition Philip Chu

https://ebookgate.com/product/learn-unity-4-for-ios-game-development-
create-amazing-3d-games-for-iphone-and-ipad-1st-edition-philip-chu/

ebookgate.com

Make Fun Create Your Own Toys Games and Amusements First
Edition Bob Knetzger

https://ebookgate.com/product/make-fun-create-your-own-toys-games-and-
amusements-first-edition-bob-knetzger/

ebookgate.com

Global Software and IT A Guide to Distributed Development

Projects and Outsourcing 1st Edition Christof Ebert

https://ebookgate.com/product/global-software-and-it-a-guide-to-
distributed-development-projects-and-outsourcing-1st-edition-christof-
ebert/
ebookgate.com

End to End Game Development Creating Independent Serious

Games and Simulations from Start to Finish 1st Edition
Nick Iuppa
https://ebookgate.com/product/end-to-end-game-development-creating-
independent-serious-games-and-simulations-from-start-to-finish-1st-
edition-nick-iuppa/
ebookgate.com
Professional Windows Phone 7 Game Development Creating
Games using XNA Game Studio 4 1st Edition Chris G.
Williams
https://ebookgate.com/product/professional-windows-phone-7-game-
development-creating-games-using-xna-game-studio-4-1st-edition-chris-
g-williams/
ebookgate.com

3D Game Textures Create Professional Game Art Using

Photoshop 2nd Edition Luke Ahearn

https://ebookgate.com/product/3d-game-textures-create-professional-
game-art-using-photoshop-2nd-edition-luke-ahearn/

ebookgate.com

Game Design Workshop A Playcentric Approach to Creating

Innovative Games 3rd Edition Fullerton

https://ebookgate.com/product/game-design-workshop-a-playcentric-
approach-to-creating-innovative-games-3rd-edition-fullerton/

ebookgate.com

Twenty Lectures on Algorithmic Game Theory 1st Edition Tim

Roughgarden

https://ebookgate.com/product/twenty-lectures-on-algorithmic-game-
theory-1st-edition-tim-roughgarden/

ebookgate.com

iOS Swift Game Development Cookbook 2nd Edition Simple

Solutions for Game Development Problems Jonathon Manning

https://ebookgate.com/product/ios-swift-game-development-cookbook-2nd-
edition-simple-solutions-for-game-development-problems-jonathon-
manning/
ebookgate.com
Distributed Game Development
Harnessing Global Talent to
Create Winning Games

Tim Fields

AMSTERDAM • BOSTON • HEIDELBERG • LONDON

NEW YORK • OXFORD • PARIS • SAN DIEGO
SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Focal Press is an imprint of Elsevier
Focal Press is an imprint of Elsevier
30 Corporate Drive, Suite 400, Burlington, MA 01803, USA
The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB, UK

© 2010 Elsevier Inc. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or by any means, e­ lectronic
or mechanical, including photocopying, recording, or any information storage and retrieval s­ ystem,
without permission in writing from the publisher. Details on how to seek permission, further
­information about the Publisher’s permissions policies and our arrangements with organizations such
as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website:
www.elsevier.com/permissions.
This book and the individual contributions contained in it are protected under copyright by the
Publisher (other than as may be noted herein).

Notices
Knowledge and best practice in this field are constantly changing. As new research and experience
broaden our understanding, changes in research methods, professional practices, or medical treatment
may become necessary.
Practitioners and researchers must always rely on their own experience and knowledge in evaluating and
using any information, methods, compounds, or experiments described herein. In using such information
or methods they should be mindful of their own safety and the safety of others, including parties for whom
they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or ­editors, assume any
liability for any injury and/or damage to persons or property as a ­matter of product liability, negligence or
otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the
material herein.

Library of Congress Cataloging-in-Publication Data

Fields, Tim.
Distributed game development: harnessing global talent to create winning games/Tim Fields.
   p. cm.
Includes bibliographical references and index.
 ISBN 978-0-240-81271-7 (hardcover: alk. paper) 1. Computer games–Programming. 2. Computer
software–Development. 3. Electronic data processing–Distributed processing. I. Title.
QA76.76.C672F55 2010
794.8’1526–dc22 2009049368

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library.
ISBN: 978-0-240-81271-7

For information on all Focal Press publications

visit our website at www.elsevierdirect.com
10 11 5 4 3 2 1

Printed in the United States of America

I dedicate this work to all of the wise mentors who have taught me so much over
the years: V. Fields, V. Jewett, B. Fregger, E. Boling, D. Stafford, L. Acton,
J. Ybarra, DB23, E. Roberts, Alanha, P. Watt, S. Barcia, L. Lapierre,
R. Wallace. And always, RS.

iii
This page intentionally left blank
Contents

About the Author....................................................................................................................................... xi

Chapter 1 Preface and Overview................................................................................... 1

1.1 Introduction........................................................................................................1
1.2 How Is a Team Leader to Juggle All of This?............................................2
1.3 Who Is This Book For?......................................................................................3
1.4 Preamble on Distributed Development....................................................4
1.4.1 Why Would I Use Distributed Development?...............................4
1.4.2 So You Don’t Like Outsourcing and Think It’s a Bad Idea.........5
1.4.3 The Difference between Traditional Outsourcing and
Distributed Development................................................................6
1.4.4 Who We Will Meet in Our Case Studies, and Why
We Care about What They Have to Say.......................................7

Chapter 2 Overview of the Development Process......................................... 9

2.1 The Basic Games Development Cycle........................................................9
2.2 Concept Discovery..........................................................................................10
2.3 Pre-Production.................................................................................................12
2.4 Full Production.................................................................................................16
2.5 A Word on Demos...........................................................................................19
2.5.1 How to Prepare Properly................................................................20
2.5.2 How to Use Distributed Development Teams to
Alleviate Demo Problems..............................................................20
2.5.3 When They’re out of Control.........................................................20
2.6 Alpha, Beta, Final..............................................................................................21
2.6.1 Finaling.................................................................................................21
Interview with David Wiens, Project Manager at Disney Online....... 25
2.7 Manufacturing and Distribution................................................................28
2.8 Launch Day........................................................................................................28
2.9 Post Launch Support and Updates...........................................................28
2.10 Summary............................................................................................................29
Interview with Rhett Bennatt, Art Director, Aspyr Games.................30
v
���������

Chapter 3 Your World and Your Internal Team. .............................................. 35

3.1 Types of Distributed Collaboration: How to Organize
Your World.........................................................................................................35
3.1.1 Organization of Key Players: Developers, Publishers,
Customers, and Retailers................................................................35
3.1.2 Traditional Distribution Model.....................................................36
3.1.3 Digital Distribution Model.............................................................37
3.2 Organization of Distributed Development Teams..............................39
3.2.1 The Core Team...................................................................................39
3.2.2 What to Do with the Wii?...............................................................40
3.2.3 Separate Multiplayer.......................................................................40
3.2.4 How Many People per Group?.....................................................41
3.2.5 Subcontractors..................................................................................41
3.3 How to Pick Your Internal Reps...................................................................42
3.3.1 Flexibility..............................................................................................42
3.3.2 Diplomacy...........................................................................................42
3.3.3 Travel.....................................................................................................43
3.3.4 Technical Skills...................................................................................43
3.3.5 Dedication...........................................................................................43
3.4 Key Roles and How to Identify Good Candidates................................44
3.4.1 Producer...............................................................................................44
3.4.2 Associate Producer...........................................................................46
3.4.3 Development Director....................................................................46
3.4.4 Art Director.........................................................................................47
3.4.5 Technical Director.............................................................................47
3.4.6 Senior Designer.................................................................................49
3.4.7 Integration Engineer and Build Master.....................................49
3.4.8 Technical Art God.............................................................................50
3.4.9 Audio Guru..........................................................................................50
3.4.10 News Flash: A Team Is More Than the Sum of Its Parts........52
3.5 Insourcing: It’s Like Hiring Family Because Dad Told You To............52
3.5.1 How to Use Insourcing Effectively..............................................53
3.6 Summary............................................................................................................54
Interview with Robyn Wallace, General Manager, Blue Castle
Games...................................................................................................54

Chapter 4 External Partnerships................................................................................ 63

4.1 Where to Find Candidates and Teams.....................................................63
4.2 How to Know What You Need.....................................................................64

vi
 Contents

Questions for Fay Griffin, Development Director, Electronic Arts..65

4.2.1 Partner Evaluation Matrix..............................................................69
4.2.2 Warning Signs When Evaluating Teams....................................71
Interview with Luke Wasserman, Senior Producer, 2K Sports..........73
4.3 How Developers Can Find Partners and Publishers............................77
4.3.1 On Agents............................................................................................78
4.3.2 Why Developers Need to Self-Promote Early and
Always...................................................................................................80
4.3.3 Warning Signs for the New Developer......................................80
4.4 How Developers Should Evaluate a Development Deal...................81
4.4.1 The Assignment.................................................................................82
4.4.2 Pay..........................................................................................................82
4.4.3 Royalties...............................................................................................85
4.4.4 Delivery and Acceptance...............................................................87
4.4.5 Intellectual Property Rights..........................................................88
4.4.6 Credit.....................................................................................................89
4.4.7 Future Relationship..........................................................................90
4.4.8 Key Employees...................................................................................90
4.4.9 Use of Subcontractors.....................................................................90
4.4.10 Termination.........................................................................................91
4.4.11 The Value of an Appendix..............................................................92
4.4.12 Strategic Value...................................................................................92
4.5 Roles and Responsibilities............................................................................94
4.5.1 Marketing............................................................................................95
4.5.2 Localization.........................................................................................95
4.5.3 Manufacturing...................................................................................96
4.5.4 Quality Assurance.............................................................................96
4.5.5 Publisher-Independent Quality Control...................................97
4.5.6 First-Party Certification...................................................................97
4.6 Summary............................................................................................................97
Interview with Sergio Rosas, President and Founder of CGBot......... 98

Chapter 5 Getting off on the Right Foot........................................................... 105

5.1 Making Sure You Have a Shared Vision................................................ 105
5.1.1 How Do You Best Establish a Shared Vision?....................... 105
Interview with Bill Byrne, Professor, Art Institute of Austin........... 108
5.2 Defining Project Parameters: Scheduling Goals, Techniques,
and Milestones.............................................................................................. 112
5.2.1 Types of Scheduling...................................................................... 112

vii
���������

5.2.2 How to Structure Milestones..................................................... 113

5.2.3 Dealing with Multiple Platforms Simultaneously.............. 119
5.2.4 Devising Collaborative Schedules: Scheduling from
the Ground Up................................................................................ 125
5.2.5 What Does Good Look Like?...................................................... 126
5.3 Kickoff Meetings........................................................................................... 127
5.3.1 When You First Discuss the Possibility of Working
Together......................................................................................... 128
5.3.2 When You Hammer out the Terms........................................... 128
5.3.3 When the Project Is a Go and the Contract Is Signed....... 128
5.3.4 When the Bulk of the Staff Starts to Come Online............. 130
5.3.5 When Key Team Members Meet (Art Directors’
Summit)............................................................................................. 131
5.4 How to Keep Balance among Internal and External Teams:
Avoiding “Us versus Them” and Other Common Problems........... 132
5.5 Tools for Keeping the Team in Sync....................................................... 134
5.5.1 Source Control................................................................................ 134
5.5.2 Using Source Control across Multiple Sites and Teams.......134
5.5.3 E-mail................................................................................................. 135
5.5.4 Subgroup Aliases........................................................................... 136
5.5.5 E-mail Archiving of Critical Information................................ 136
5.5.6 Flagging and Tagging.................................................................. 136
5.5.7 Etiquette........................................................................................... 136
5.5.8 Instant Messaging......................................................................... 137
5.5.9 Video Conferencing...................................................................... 137
5.5.10 Shared Documentation Space: Wikis, Sharepoint,
and Google Docs........................................................................... 138
5.5.11 Defect Tracking............................................................................... 138
5.5.12 Asset Review.................................................................................... 139
5.6 Summary......................................................................................................... 140
Interview with Everett Lee, Production Director, Sony
Online Entertainment.................................................................. 140

Chapter 6 Maintaining the Organism................................................................. 147

6.1 Establishing and Maintaining Trust....................................................... 147
6.2 Progress Checkpoints and Milestone Tracking Progress............... 148
6.3 On Equipment and Software Needs...................................................... 150
6.3.1 For Developers................................................................................ 150
6.3.2 For Publishers and Those Who Loan out Gear..................... 150

viii
 Contents

6.4 How to Know When Things Are Going Wrong, and

What to Do about It..................................................................................... 151
6.4.1 Play the Build................................................................................... 152
6.4.2 Metrics............................................................................................... 153
6.4.3 Try to Break Down Communication Silos.............................. 153
6.5 What to Do When the Job Requires More Work Than You’d
Agreed Upon.................................................................................................. 154
6.5.1 Find out Why................................................................................... 154
6.5.2 Determine If You Need Additional Resources..................... 155
6.5.3 Even When It Is Difficult or Expensive, Do What You
Say You Will Do............................................................................... 157
6.6 How to Deal with Product Goal or Design Changes........................ 158
6.7 How to Gracefully Exit When Required................................................ 159
6.8 Finaling and Product Submission.......................................................... 161
Interview with Phil Wattenbarger, Director of Product
Development, Certain Affinity................................................... 168
6.9 The Postmortem........................................................................................... 176
6.10 Planning for Your Next Date..................................................................... 177
6.10.1 For Publishers.................................................................................. 179
6.10.2 For Developers................................................................................ 180
6.11 Summary......................................................................................................... 181

Chapter 7 Site Visits and Common Situations............................................. 183

7.1 Site Visits.......................................................................................................... 183
7.2 Who to Send and Why................................................................................ 184
7.2.1 Critical Meetings............................................................................ 185
7.2.2 Collaborative Creation................................................................. 185
7.2.3 Getting to Know Individual Strengths and
Weaknesses...................................................................................... 185
7.2.4 Soaking up Their Attitude........................................................... 186
7.2.5 Troubleshooting............................................................................. 186
7.2.6 Celebrating....................................................................................... 187
7.2.7 Surprise Inspections..................................................................... 187
7.3 Representing Your Company and the Project While
On-Site............................................................................................................. 187
7.4 Language Barriers........................................................................................ 188
Interview with Frank Klier, Development Manager.......................... 190
7.5 Cross-Pollination........................................................................................... 192
7.6 Dealing with Distractions.......................................................................... 193

ix
���������

7.6.1 Understanding Local Politics..................................................... 193

7.6.2 Ferreting out Destructive Non-Work Distractions............. 194
7.7 Cultural Differences..................................................................................... 195
7.8 Regional Conditions.................................................................................... 196
7.9 Helpful Tools for Staying in Touch with Home Base........................ 198
7.9.1 A Cell Phone with an International Rate Plan...................... 198
7.9.2 Instant Messenger......................................................................... 198
7.9.3 Skype.................................................................................................. 198
7.9.4 Blackberry or Other Mobile E-mail Device........................... 198
7.9.5 Remote Desktop............................................................................ 199
7.10 Failure Study: When the Schedule Is Wrong....................................... 199
7.10.1 What to Do When Your People Are Spending Too
Much Time On-Site........................................................................ 201
7.11 Failure Study: When Your Vision Is Clouded........................................ 202
7.11.1 When You’re Shooting for the Wrong Target....................... 202
7.12 Failure Case: When the Bugs Eat You.................................................... 204
7.13 Failure Case: The Decision-Making Bottleneck.................................. 205
7.14 Hot Potato Projects...................................................................................... 206
7.15 Summary......................................................................................................... 208
Interview with Mark Greenshields, CEO of Firebrand Games....... 208

Chapter 8 Review, Conclusions, and the Future......................................... 213

8.1 A Review of What We’ve Discussed........................................................ 213
8.1.1 Chapter 1: Preface and Overview............................................. 213
8.1.2 Chapter 2: Overview of the Development Process............ 214
8.1.3 Chapter 3: Your World and Your Internal Team.................... 214
8.1.4 Chapter 4: External Partnerships.............................................. 215
8.1.5 Chapter 5: Getting off on the Right Foot............................... 216
8.1.6 Chapter 6: Maintaining the Organism.................................... 217
8.1.7 Chapter 7: Site Visits and Common Situations.................... 218
8.1.8 Overall Conclusions...................................................................... 220
8.2 What the Future Holds............................................................................... 220

Index............................................................................................................................ 223

x
About the Author

Tim Fields is a 16-year game industry veteran producer, project manager, design
lead, and business developer. Tim has helped small studios and top publishers
such as EA and Microsoft run teams that create great games. He has worked on
shooters, sports games, racing titles, and RPGs using talent and teams from North
America, Asia, Europe, and the United Kingdom. Tim has been involved in one way
or another with franchises like Need for Speed, Halo, SSX, Brute Force, and Call of
Duty. He loves visiting about game development and design and can be reached at
[email protected].

xi
Chapter
One
Preface and Overview

1.1 Introduction
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 delight-
fully 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 brinks-
manship 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 acces-
sible 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

© 2010, Elsevier Inc. All rights reserved.

doi: 10.1016/B978-0-240-81271-7.00001-1 1
chapter one • preface and overview

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 com-
munication, 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

2
 1.3 who is this book for?

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 manage-
ment 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 soft-
ware 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 pro-
fessional 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 prog-
ress 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

3
chapter one • preface and overview

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 some-
day 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 prod-
uct 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, dizzy-
ing 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 run-
ning 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 distrib-
uted 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

4
 1.4 preamble on distributed development

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 devel-
opment 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 develop-
ment, and 20% of those projects polled spent more than $2 million on an ­externalized

5
chapter one • preface and overview

c­ omponent.1 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 atten-
tion 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, regard-
less 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 T he Difference between Traditional Outsourcing and

Distributed Development
It’s critical that we draw a distinction between two fundamentally different devel-
opment 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 branch-
ing 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 con-
tent team at a major publisher. In all of these cases, there are ­numerous research

Game Developer Research (April 2, 2009). Survey: Outsourcing in game industry still on increase.
1

Available at http://www.gamasutra.com/php-bin/news_index.php?story=23008.

6
 1.4 preamble on distributed development

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.

1.4.4 W
 ho We Will Meet in Our Case Studies, and Why We Care
about What They Have to Say
No games are built by a single individual anymore, no matter what a few egoists like
to believe. And as entertaining as I am, our topic here is too important to trust to just
one voice. So we’ve recruited a few industry veterans to help lead us.
This book contains a number of interviews conducted and presented in Q&A for-
mat, designed to offer advice from experienced development directors, producers,
lead programmers, art directors, motion graphics experts, and the like. They share
their hard-earned wisdom and war stories with us, each dealing with some element
of distributed games development. These are some of the top names in the field,
whose products collectively have grossed hundreds of millions of dollars during
the past decade. Their experiences are generously shared with us so that we might
learn from them and continue to produce our own great products.
Although any fool can learn from his own mistakes, a wise man just might get
ahead of the curve and learn from the experience of others.
Now let’s talk about how to make great games.

7
This page intentionally left blank
Chapter
Two
Overview of the
Development Process

2.1 The Basic Games Development Cycle

It’s likely that if you’re reading this book, you may have already been through one
or two game development cycles. Now that our industry has become a bit more
mature, it’s likely that many of you have been through five complete cycles or
more. And a rare number of you may have game credits in the double digits. So you
might know the basic framework of a development cycle these days. On the other
hand, our industry is still fairly immature, and terminology and procedure differ
even between established publishers. So we’re going to discuss a simplified ver-
sion of a production cycle as a way of setting some terminology and making sure
we’re all thinking about roughly the same core phases of planning, development,
and ­product launch.
For those of you who haven’t yet had the pleasure of going through a full devel-
opment cycle, or who have been so heads down in the day-to-day functions of your
job, this chapter serves as an introduction to the formal phases of game develop-
ment. The steps described here are applicable to development no matter how many
different teams or individual contributors are on a project. It’s a framework that
works equally well for distributed development and more traditional team orga-
nizations. Interspersed throughout this chapter are observations on ways you can
ensure success at each phase and how and when to incorporate distributed teams.
So let’s dive in and look at the game development process!
Let’s start at the beginning and briefly discuss each phase of a typical ­development
cycle (Fig. 2.1). We’ll also address some of the challenges and situations that tend
to be unique to distributed development projects.

© 2010, Elsevier Inc. All rights reserved.

doi: 10.1016/B978-0-240-81271-7.00002-3 9
 chapter two • overview of the development process

figure Project
2.1 begins.

Concept discovery Pre-production

All key externals

All key questions
(Dev + Art +
answered; vertical slice
Audio) signed.

Production

Game available to players!

Finaling Submission & launch Support & updates

Online updates, patches, downloadable content

The Basic Development Cycle

2.2 Concept Discovery

In the beginning, you’re likely to already have an idea for the kind of game you
want to make. Or maybe your host organism, publisher, or team has come to you
with something they are pretty sure they want to be made. If this is a movie-licensed
title, or a sequel in a well-understood franchise, then the concept discovery phase
may be slightly less complex for you, and you may be able to spend less time in this
phase. If this is a new intellectual property that you hope to get off the ground, then
you’re likely to want to spend extra time here. Either way, what you’re doing at
this point is positing different product propositions and determining how they work
for your target audience. It’s possible that you’ll also need to spend some time on
understanding who your target audience is in the first place. There are many ways
to approach this phase, but here are a few general suggestions:
• Don’t get too attached to any one concept or idea at this point.
• Use inexpensive methods to mock up many different concepts.
• Short descriptions of features should be put in front of average users.
• Get concepts in front of consumers often, and work to understand what they
mean, not just what they say.
• Mock game boxes are a good way to judge purchase intent between different
possible products.
• Survey Monkey-style surveys are a great way to let users prioritize features so
you know what they care about most.

10
 2.2 concept discovery

• Find out whether the intent to purchase changes considerably based on setting,
a different main character, or different art styles.
• If you cannot afford proper focus groups, get local game store managers and
their friends to offer input and compensate them with pizza.
• People will tell you what they think you want to hear, so study carefully their
intent, and try not to let the way you ask questions “lead the witness” too much.
Frankly, this phase is critically important even if you are creating a product that
lives inside a known product family. Even if the core mechanics, setting, audience,
or characters are carried forward from a previous title, this is still the cheapest way
you’ll ever have to test consumer reaction to various possible features. Heading
down the wrong path here can doom you to an expensive debacle that no amount
of hard work can make up for on the back end. From a concept standpoint, few
people are likely to buy Barbie’s Chainsaw Golf, no matter how good the artwork
or how stellar the multiplayer component. Better to learn that now and throw the
idea out before you spend precious time and money on development. From a fea-
ture perspective, few people are likely to care about an advanced create-a-character
system inside your casual puzzle game; use this phase to recognize these kinds of
pitfalls, and don’t waste time on this feature just to cut it later. (Obviously, these
examples are over the top in order to make a point, but it is easy for a development
team to fall in love with an idea that the consumer just won’t care about. This ini-
tial phase is the time to put a bullet in those expensive forms of hubris.)
Beyond just imagining, mocking up, and validating potential concepts and fea-
tures, you should also be using this time to form some alignment between your key
­stakeholders. Make sure that marketing thinks it can sell the game you’re narrow-
ing in on. Make sure it fits into the SKU planning that your publishing team is doing
for the release window you’re considering. Make sure the key members of your team
have the appropriate amount of enthusiasm for the software you’re going to build. Get
alignment from everyone who matters, and if they don’t seem too interested, find out
why not. Don’t let a land mine in some division of your team or publisher catch you
unaware once you’ve already committed a fortune and your reputation to this project.
Another way to spend time during this phase of the project is on identifying the
likely “big buckets” or general categories of work that will need to be done to build the
type of game you wish to make. What kinds of content will you have, and how much
of it will you need? What software systems do you currently own that you can lever-
age to make this kind of game? What new systems will you need to invest in? Will you
“roll your own,” or are there off-the-shelf solutions you can use? And so on.
Note that there is a risk of falling into the “design by focus group” trap here.
We’ve all played games that seem watered down, like they’ve been designed to be
an amalgam of the best ideas from the previous year’s hits. The best antidote to
this potential poison is a core design team (which isn’t necessarily a part of the
“designer” job family) that is passionate and empowered. Build such a group and
encourage its members to stand by – and test – their convictions, and you won’t
end up with a generic, knock-off product.

11
chapter two • overview of the development process

Although the line between the concept discovery phase and pre-production can be
slightly blurry, especially since at least some of the assets you are creating and some
of the design work that is being done will move forward into the true pre-production
phase, you’ll need to resist the temptation to hurry to pre-production. Whatever inex-
pensive early prototyping and validation techniques you use at this point, there are a
few key things you should know before you consider this phase complete:
• Who is your target market?
• Why will they buy this game?
• Who is your chief competition?
• What are the core features that matter most?
• What are the key technologies required?
• Who are the key human resources required for you to succeed?
• Does everyone who matters in your food chain believe this product can be a hit?
• What platforms are you making this game for?
• What is your target launch window? (In what quarter will you release?)
• What is the general scope of this game (8-hour single-player campaign, casual web,
pervasive massively multiplayer online [MMO], etc.)?
If you don’t have at least a coarse grain answer to most of these questions, you’re
likely not yet ready to move out of the concept discovery phase.
These days, because you’re likely to be using distributed development methods,
you’re likely to have an extra step here, beyond what you might have done histori-
cally. You’ll need to determine what partnerships you have to make to get this prod-
uct out the door. You need to reach out to likely partners, evaluate their work, and
verify that they have the capacity and interest to collaborate with your team. Also,
of course, you’ll need to determine if mutually agreeable financial and contractual
terms can be reached. All these details are discussed in-depth in the next chapter,
but as you’ll notice from Fig. 2.1, at this phase you should really have all of your
primary collaborators identified and have at least gone through enough early phase
negotiations that you are reasonably certain you’ve got the support you need to
build the product you and your audience wants.

2.3 Pre-Production
Although the border between the concept discovery phase and pre-production can
be somewhat shadowy territory, your goals before exiting the pre-production phase
are clear. You need to know answers to the following questions with a fairly high
degree of certainty:
• What are you building?
• Who will build it?

12
 2.3 pre-production

• How will it be built?

• When should each piece be complete?
• Why will all of these pieces combined be a great product?
To break some of these questions down into more discrete chunks, you should
ask yourself (and be able to answer) the following:
• What are all the features this software needs?
• What is the plan for building and testing each feature?
• What content is required?
• Who will build each piece of content?
• How long will it take to build and integrate everything?
• Are the right teams and people in place in order to get the product built fast
enough, to quality, and within your budget?
• What are your major risk items, and how do you mitigate them?
• What does your high-level schedule look like?
• Are all of your distributed teams in place, under contract, and staffed appropriately?
• Is the publishing and marketing arm of your publisher prepared for this
product?
• Do you have sufficient resources to build and test the game you’re about to build?
Simply put, this is the last time you can back out of or change plans relatively
cheaply. Once you start full production, your monthly staff costs will tend to increase
a great deal, and getting out of contracts (even using some of the techniques dis-
cussed in later chapters) will become much more expensive. So use this phase to
make sure that everyone who needs to sign off on and believe in your plan can do
so comfortably. Course corrections in subsequent phases of development are more
expensive and, therefore, much more painful.
You’ll face many critical and unique challenges during this phase, especially
when using distributed development. First, determining the correct workload for
each developer and partner takes a lot of time. Coming to terms on costs and other
contract details can also be a lengthy process. Plan accordingly because every-
thing, ultimately, will have to go through legal approval on both sides. Beware: The
wheels of justice are notoriously slow to turn.
During this phase, you’ll also need to make sure that your workflow and pipe-
lines are in place. Under a distributed development model, this means you’ll need
the ability to transfer build data, to get your source control systems in place and
on site at each location, and to understand who is in charge of troubleshooting
the data transfer or other technical issues that arise with your communications
pipelines. Establishing tight pipelines can be considerably more complicated when
there is significant distance or several groups involved. These issues are discussed
in-depth in later chapters.

13
chapter two • overview of the development process

Finally, before you can truly exit the pre-production phase, whether you’re using
traditional or distributed development models, you’ll need a playable example of
what the shipping product should look and feel like. This example has come to be
called the “vertical slice.” This slice should showcase every major game feature,
your art style, some relatively polished gameplay, and refined audio. In short, this
should be nearly a consumer demo-level quality of a piece. Every major publisher
will want something like this before greenlighting a costly move into full produc-
tion. But even in the publisher’s absence, you’ll need to get to this level in order
to prove to yourself or your investors that what you’re about to invest a lot of time
and resources in to build actually works as a game. If your vertical slice provides
compelling gameplay and distinct visuals and is memorable in a way that will help
distinguish it from the competition, offering a unique consumer proposition, then
you’re probably looking at a success.
What makes a good greenlight presentation:
• A great build of your game that shows it’s visual promise and unique gameplay,
in approximately 30 seconds
• A clear understanding of your audience and how your product compares to
other products they’ve bought
• Concise explanation for the costs of the project, with enough supporting detail
to address any questions
• A realistic timeline and schedule
• A clear diagram listing all the teams and subcontractors you’re using and what
each is responsible for
• Major risks and their mitigation
For distributed developers, there’s another critical component involved in making
this vertical slice. Because part of the proposition here is to prove that you are able
to build a full game to this level of quality, ideally you’ll also need to have tested
and stressed your workflow and pipelines. This means that you’ll need to ensure
that each external resource you plan on using can contribute to the creation of the
vertical slice. Think of it as a trial run of a complex manufacturing assembly line.
The very first item that rolls off the line is not necessarily meant to be sold or used;
it’s meant to let you slowly test each and every component of your workflow. Leave
plenty of extra time here for troubleshooting and repairing all of the inevitable
workflow problems that arise. The content and features that you build here should
take longer than everything you build hereafter. You’re using this time to work the
kinks out of the system. If you don’t do this now, then you’ll have to do it piece-
meal during production, when you’ve got many other complicated issues in play.
It helps to have dedicated operations or IT people on every team communicating
directly with one another to sort out many of the initial technical problems you’ll
encounter.

14
 2.3 pre-production

The following are common problems here, which usually need attention:
• Data transfer rates between various teams turn out to be woefully inadequate.
• Version mismatches between different content creation packages (Maya, etc.)
complicate the handoff of assets.
• Communication personnel holes are revealed as details fall through the cracks.
• Minor differences in the development environment have unexpected conse-
quences. (Questions arise, such as “Which visual studio processor pack is the
team in Shanghai using?”)
• It takes far longer to build some kind of asset than expected. (e.g., “Unwrapping
UVs on every face takes days! We need a new Maya script to help with this!”)
• The work quality or professionalism of one or more of the partners proves
lacking. (“Every time we get a build with new code from the Singapore team,
­multiplayer becomes really unstable. They need to be testing more thoroughly
before submitting.”)
It’s safe to say that this is the most difficult part of the development cycle to get
right, for both traditional teams and distributed teams. There’s a natural tendency to
rush into production because everyone is excited; because your team is finally get-
ting to build things, which is why most of them get up in the morning; and because
you know you’re set to reach the finish line and you’re concerned about how little
time you have to get everything built. However, these are the emotions you most
need to control. Jumping into production too early is the best way I’ve seen (short
of building the wrong game in the first place) of ending up having to redo or throw
away lots and lots of work, endangering the game that you’re so eager to build.
Also, there’s little that’s more demoralizing to a team, or more expensive to a stu-
dio, than cutting features or content that are almost there but not quite. In fact, the
only thing worse is shipping something crummy that should have been cut.
If you’re part of a mature publishing organization, you’re likely to have some
kind of formalized greenlight process. If you’re not, you’ll want to institute your
own. Simply stated, you need all key decision makers from development, market-
ing, and publishing to get together and have a frank discussion about the oppor-
tunity, the promise, and the costs of publishing the game you’re about to spend a
lot of money building. There’s a tendency on the part of the development team to
want to convince the rest of the organization that the product is one that should be
built. However, if the team can’t get wholehearted agreement from the rest of these
groups, you should have serious trepidation about embarking on full production.
You’re just about to commit many resources – minds, hearts, and cash – to build-
ing something. Make sure your stakeholders have officially bought in and are ready
and excited to hold up their part of the bargain.
Don’t short-change yourself in pre-production. You need this time to understand your
game and to work out the kinks in your process before you move on to full production.

15
 chapter two • overview of the development process

2.4 Full Production

Can you hear that? It’s the satisfied humming sound of a well-oiled machine, run-
ning smoothly and efficiently. Those excited voices? Those are the sounds of your
team when they are happily creating great content, enjoying a new feature that just
came online, and expressing their confidence in the idea that what they’re build-
ing is going to be great. If your concept and pre-production phases were properly
executed, and no nasty surprises arose that changed the world on you, then your
production process should sound like this.
Of course, the soundtrack to real life is seldom as melodious as the one we imag-
ine. For most teams, the production phase is a stumbling, shambling lurch from one
milestone to the next, usually punctuated by subteam Scrum-style sprints every few
weeks. Although at first this process might seem a fairly straightforward matter of
determining what the milestone needs to entail, executing on it, and then moving
on to the next one, there is typically a bit more complexity.
Let’s take a look at the way one milestone flows into the next and some of the
key beats that will need to be hit along the way. Figure 2.2 is a simplified diagram
showing two milestones.
Since the first milestone or two in the production phase tends to be special cases
of working out a few kinks or getting a few core tools up and working so that all of

figure 8/13 8/22

Official milestone build Milestone success declaration &
2.2 deficiencies list published
delivered to QA

7/26 - 8/2
Leads planning 8/14 - 8/21
next milestone specs QA milestone review

Milestone
begins

Milestone 3 Previous milestone deficiencies

added to next milestone tasks
8/23
7/13 7/20 7/27 8/3 8/10 8/17
7/7 8/22
8/7
Begin integration of branches
9/27
Official milestone build
delivered to QA

Next milestone
begins

Milestone 4

8/17 8/24 8/31 9/7 9/14 9/21

8/14 9/27
9/16
Begin integration of branches

Simplified Milestone Flow

16
 2.4 full production

your teams can be effective, we’ll assume that the project has already been through
these kickoff milestones. So let’s say that you’re a few milestones into production.
Things are moving smoothly.
In this hypothetical, we’re looking at two typical mid-production milestones. They
could really be from almost any type of project. The first milestone is on July 7.
The team should know what they’re working on, and that they have 6 weeks before
they are expected to deliver a milestone build to the QA department, which will
then review the build and make sure that the project leads are aware of anything
deficient that needs to be addressed. Our discussion will start on the third and
fourth milestones.
Let’s take a closer look at Milestone 3 (Fig. 2.3). Assuming that all of your
teams and subgroups know what they should be working on, and that they under-
stand the team’s dependencies and deadlines, the first few weeks should focus on
development. Your primary job during this period is to help facilitate communica-
tion between teams, to check out new features and content as it is created, and
­generally to help facilitate the development process any way you can.
Midway through this milestone, a new task should begin to dominate your
thinking. You’ll need to work with the leads and subleads across all teams to plan
the details of the next milestone. This is obviously tricky because you’re only half-
way through the last one. Thus, first, your leads will need to gather a sufficient
amount of information from everyone on their teams about the game’s current
rate of ­progress. You’ll want them to try to project forward a few weeks to deter-
mine where all of your key features will be. You’ve already achieved a high-level
understanding regarding what this next milestone needs to accomplish from your
work in the pre-production phase, so now your job is to determine the details
of exactly who will be doing what, starting in approximately 3 weeks, to get the
game to its overall goal. This step of the process is really an exercise in educated

8/13 8/22 figure

Official milestone build Milestone success declaration &
deficiencies list published
2.3
delivered to QA

7/26 - 8/2
Leads planning 8/14 - 8/21
next milestone specs QA milestone review
Milestone
begins

Milestone 3

7/13 7/20 7/27 8/3 8/10 8/17

7/7 8/22
8/7
Begin integration of branches

Sample Milestone Detail

17
chapter two • overview of the development process

­ est-­guessing. (Remember, however, that you’re only projecting ahead by a few

b
weeks, and ­hopefully your leads are experienced in this process so that the guesses
they make are likely to be pretty informed.)
Once your leads have come up with the next milestone goals and the team has
worked out task lists, you’ll need to have them vetted by the general team for accu-
racy, clarity, and achievability. You’ll also want your QA leads to become involved,
once the team has approved the next milestone task list, because during the next
week or so, QA will need to come up with their test plans for milestone four (M4).
This planning exercise should take no more than 4 days, but its important to remem-
ber that this step touches each team you work with and involves a fair amount of
communication both up and down the ladder. Because your workers all still have a
milestone that they’re in the middle of, you’ll want to make sure that as little of this
burden as possible is passed down to them. (This is where your mid-management
layer of associate producers, development directors, and group leads will have their
mettle tested.)
After your mid-milestone planning session, you should have a few days left to
really push toward wrapping up any outstanding milestone tasks. Then it’s time to
start the process of integrating everyone’s work into a single coherent build.
Stated simply, the integration phase begins the moment that the teams working
on disparate branches (the rendering branch, the art branch, etc.) start to collabo-
rate on pulling together the different code blocks and content bases, incorporating
the various pieces into the main trunk. Most teams, distributed or not, go through
this process periodically, and your technical director should be very experienced
at this. For more highly distributed teams, there will probably be more branches to
the tree, and integration is likely to be a little trickier. That’s the reason why in this
example, we’ve set aside a full week for this step.
Notes on integrating the different branches:
• You don’t have to fold all of the branches back into the main trunk at every milestone.
• You don’t want to wait too long between integration stages, however, because
the longer you wait, the more complicated the task will be.
• It is possible to deliver multiple builds to QA from the different branches. Just
don’t get into this habit because eventually you’ll need to integrate it all into a
cohesive whole.
• The task of branch integration is one of the most commonly mis-estimated. I’ve
seen branch integrations that were supposed to take 2 days end up taking a
month. Make sure you leave yourself enough time to complete this process, even
if it means delaying some work until the next milestone.
• Locking out the branches and the main for a few days, sharply limiting the
number of engineers who are responsible for branch integration, usually helps
restore stability quickly and efficiently.
• Because you may have to lock down certain branches, establishing a set off-hour
time for branch integration can help limit downtime.

18
 2.5 a word on demos

Once your branches are tidied up and you’ve got a working build for each
­ latform, a build that demonstrates all (or most) of the various features and ­content
p
you’d hoped to accomplish for the milestone, it’s time to hand it off to someone else
to validate that what you’d hoped to achieve was, in fact, accomplished. Usually
(and ideally), this will be your QA group. Occasionally, this duty is assumed by
the production or management group responsible for going through the mile-
stone plans, line by line, to ensure that everything you set out to achieve works as
expected. Provided that everything is there and working, no more need be done –
you’re ready to move on to your next milestone.
Of course, sadly, real life is seldom so harmonious. Usually, some of what you’d
hoped your teams would accomplish won’t get done; what you’ve ended up imple-
menting works differently from what you expected; or design changes brought
about by necessity, mid-milestone, ended up changing the software in some funda-
mental way. In all of these cases, you’ll need to identify what didn’t get done and
address it on the next milestone work list (unless, of course, it’s been decided that
the feature is no longer needed or the specification for the software has changed in
some other way).
Since your mid-milestone planning already produced a detailed work item, don’t
force your teams to wait around while their milestone build is reviewed for defi-
ciencies. Instead, have them start working on the next milestone right away. Once
you have a full understanding of any hangover work from the previous milestone,
work with your team leads and other individuals to slide the hangover items onto
the list for the next 5 weeks.
Often, when too many of these sorts of unexpected extra work items combine
with integrations that take longer than expected, and other surprise delays occur
(which is common), you’ll find yourself needing to take a serious look at the project
schedule as a whole, and what you’d hoped to accomplish in the upcoming mile-
stones, to determine where you’ll find the time for all of the unexpected but highly
predictable extra work. Get ahead of this game whenever you can by expecting
some amount of hangover and integration delay and planning accordingly. I sug-
gest that a conservative estimate of 15% additional time allotted for unaccounted
for tasks such as these is appropriate. Plan for it now, and you won’t have to crunch
for it later.

2.5 A Word on Demos

If the name “E3” strikes a little fear in your heart and you remember the sick feel-
ing of having been up too many nights in a row while your DICE deadline loomed,
then you’re likely to find this section familiar. You might even shudder at the mem-
ory of trade show and magazine demos and of both press and public playing your
unfinished game. You might remember moving pizza boxes off the floor under your
desk so that some weary team member could catch a few hours of sleep before
­continuing the hunt to find and kill each devastating bug. If you’ve been around

19
chapter two • overview of the development process

game development for a while, you’ve likely experienced your share of demos.
They’re a necessary evil in this business, allowing your marketing team to gener-
ate hype for the game in advance of your launch. Sometimes they can even be of
benefit to the development team, focusing their energy and firepower on getting
one portion of the game polished and playable and helping the team get early feed-
back from potential customers on what works well and what doesn’t. The following
­sections present some ways to plan for demos to reduce their impact on your team
and a few thoughts on how distributed development can help.

2.5.1 How to Prepare Properly

A demo doesn’t have to kill your team or blow your schedule out of the water, pro-
vided you’ve properly planned for it in advance. Part of this process, obviously,
is knowing in advance that you’re going to need to show something to someone,
before the game is ready to go into a box. But you can likely predict these types
of demands within at least a 60-day window; you know when the trade shows are
coming, you know when your game is scheduled to be ready, and you (should)
know how aggressive you want your marketing team to be. So:
• Plan a milestone around the likelihood of a particular demo.
• Make sure your first playable demo can function as a consumer demo, when
possible.
• Get your QA team engaged early.
• Use branches to get a demo stable and polished, without slowing development
on the main line.

2.5.2 H
 ow to Use Distributed Development Teams to Alleviate
Demo Problems
If you have the resources, and you’re likely to have multiple demos to deliver in a
short period of time (more likely if your title is hotly anticipated), consider cultivat-
ing a side group and branch focused only on demos. This will allow the rest of your
team to keep working on shipping the product. Try also to get marketing to work
directly with this group in order to ensure that what’s being built is something that
marketing can use and that they can themselves demo effectively.

2.5.3 When They’re out of Control

I’ve seen teams get stuck in a cycle of creating a new demo every 2 or 3 weeks.
Usually, the first demo isn’t great, and publishing’s top brass ends up wanting more
regular reassurance. It is your job to prevent this from happening, to have the ­courage

20
 2.6 alpha, beta, final

to stand up and put a stop to it, or at least pick and choose your battles carefully. If
the team is doing a lot of throw-away work for demos, you’re likely to have problems
with the overall game. See if there are other ways you can communicate your status
to upper management. If the audience is different, can you reuse your demo builds
effectively? Will a few screenshots do the trick? Will another demo really result in
a higher number of sales? What’s the real motivating factor behind this supposed
need?
Don’t let your team end up becoming demo monkeys, duct-taping together one
dog and pony build after another. It’ll kill your project and your team.

2.6 Alpha, Beta, Final

2.6.1 Finaling
Happy day! You’re almost there!
After months or years of planning, design, prototyping, and pre-production,
you made it into the production phase of the game (Fig. 2.4). Your hard ­working

Production Final figure

21 Weeks 11 Weeks 2.4
1/28 - 6/20 6/20 - 9/5

Art Alpha A1 A2
5/28 7/21 8/11 9/5
4/1 5/1 6/1 7/1 8/1 9/1
1/29 - 6/20 6/20 - 9/5
Production Final

M3 Alpha
25 days 15 days 6/24 - 9/8
4/25 - 5/30 5/30 - 6/20 Final
DevAlpha Alpha A1 PS3 Final
Hand-off Hand-off Hand-off Hand-off
PS3 Beta
5/28 6/15 7/19 9/1
Hand-off
Internal Alpha 8/18
DevAlpha 6/20 Wii Final
5/30 Hand-off
Wii Beta
8/22
Hand-off
8/11
Wii PS3
Beta Beta
8/15 8/22

From Production to Final Wii

on 2 platforms, slightly staggered Final
8/29
PS3
Final
9/5

Alpha, Beta, Final

21
chapter two • overview of the development process

e­ ngineers crammed in as many great features as possible, your artists have

madly modeled and polished polygon counts, and your scripters and designers
have ­created some unique and mind-blowing sequences of gameplay. Even the
audio is starting to sound pretty good. Now you’ve got to finish the thing. Ship
it. Put it in a box. Congratulations. You’ve arrived at the most difficult part of
your job!
Putting any product through a final production phase, getting it ready for public
consumption, is difficult. It’s frequently compared to giving birth, and the meta-
phor seems apt. It’s usually a painful, bloody mess that involves lots of specialists,
with whom you’ll need to become far more intimate than you’d probably like, for
the duration of the production process.
Your finaling process usually begins soon after you’ve reached a level with the
game where it is fully working, can be played through all the way in all of its vari-
ous modes, and has all of its representative content in place (from models to char-
acters and music). Most publishers and development houses would call this an
“alpha candidate” or something similar. The point is that the game is all there and
is more or less working. From this point on, you should be able to clearly identify
all of your product’s shortcomings and all the work remaining to get the product
into a box.
Your goal during this time period should be to remove as many defects as pos-
sible from the project (usually called bugs), to get the product as polished as possi-
ble in the time allowed without adding too much additional risk to your dates, and
to finish any lingering small tasks that remain incomplete. This will also be when
all translated (or localized) content should be put in place and typically when all
last-minute performance or game balance optimizations are made. Once these
tasks are complete, you’ll submit various versions of the game to the different
quality assurance groups that represent your external partners. (Note that these
are not your internal QA testers and managers; they’ve been partnering with you
for months.) These quality assurance teams are usually distinct political groups
inside the publisher. In the case of console products, they are the “first party”
quality control and certification groups that work for Microsoft, Sony, Nintendo,
and the like.
So what is different for you, the manager of this distributed development pro-
cess? In a typical traditional development model, the producers, project managers, or
development directors act as a focal point for feedback on the game. This feedback
will come in very quickly and often at odd hours. For those used to the distributed
development model, this phase may not be as much of a shock to the system as it
could be for more traditionally structured teams. Why? Because you should already
be used to getting information and managing communications with remote teams, in
different countries, from people you may have seldom met. You should already be a
veteran at dealing with the 24-hour development cycle that distributed development
tends to favor. For you, all that has happened now is that the extended family that
comprises your team has expanded to include localization, CQC, ECG, first party, and
other far-flung stakeholders who tend to go by acronyms rather than names.

22
 2.6 alpha, beta, final

First, because your team is more spread out than a traditional team, extra strain
will be put on your communications systems. Your defect tracking process needs
to be tighter, and managing turnaround on fixes to critical issues will be more
­complex than what you’ve faced in traditional models of development.
Communications systems are the first place you’ll feel the strain. Simply put,
everyone involved in managing the process will suddenly have to become a highly
efficient traffic director, able to route new issues to the appropriate subgroup and,
ideally, the appropriate individual within that subgroup. For example, let’s say a
critical bug arises, identified by some underappreciated tester. First, the bug must be
brought to your attention. You need to recognize that this is no ordinary problem –
it’s a major problem that needs immediate scrutiny. You’ll need to triage the matter,
either quickly by yourself or with an assembled group (perhaps over the phone), to
determine whether or not you’re going to fix the bug and who needs to evaluate that
fix. Then you’ll need to quickly route the problem to the person who can best repro-
duce and evaluate the issue in order to determine what solution is most likely to fix
the problem without causing other unforeseen consequences. To do this, you’ll need
a thorough understanding of every major part of the software and of which of your
teams was involved in writing it. If it’s a straightforward problem, such as a bug in
rendering, and all of your rendering engineers work in the same office, great! But
what if it isn’t so straightforward? You’ll find that the more complicated boundary
issues that might be either in code or in content, or issues that exist where sys-
tems overlap, tend to really strain your organization and communication systems.
These particularly difficult bugs will sometimes require direct real-time debugging
between people located in different areas, sometimes without a common spoken
language. So plan for these kinds of coordination issues, and give yourself extra time
during this final phase to work out these defects. Even if only 2% of your total issues
are these kinds of difficult to resolve boundaries cases, they can still represent hun-
dreds of difficult to solve bugs. Make sure that each of your teams is armed with a
phone system (or Skype or other VOIP solution) that can be used at anyone’s work-
station, and make sure that everyone understands that diplomacy is a most prized
virtue. You don’t want a stressed out rendering engineer in San Diego getting into a
shouting match with a character animator in Hue, Vietnam.
Your defect tracking system needs to be given special consideration. You’ll
have to track and assign your bugs across all team boundaries. It’s likely that
your core team and developers each already have a system they prefer to use.
It’s equally likely that there are multiple systems in place, each with strong pro-
ponents within the individual teams. If possible, in the beginning phases of the
project, you’ll want to consolidate your tracking systems so that all teams and
stakeholders can log into the same system. Ideally, you should have a web cli-
ent available for remote locations, where it might not be possible to have a proxy
server or a sufficiently fast VPN connection to the primary host of the system
to get the job done. But be sure to test the speed of the system at each location,
using a previous project’s fully populated bug database, to make sure that the
tools in place are sufficient to the task ahead. Frequently, things scale well with

23
chapter two • overview of the development process

a few hundred bugs but not nearly as well with a few thousand. The following
suggestions, it is hoped, will make your life easier when the time comes to deal
with the onslaught of bugs:
• Make sure each client has fast enough access that editing and sorting bugs isn’t
painful.
• Make sure that subleads have the right to assign bugs to their reports.
• Work with your QA group to identify the correct flow for bugs.
• Make sure each sublead understands the software and the bug flow.
• Ensure that the different platforms or development environments required can
be identified and sorted by the software.
• Consider identifying individuals by group in the software so that it’s easier for team
members at remote locations to know who to bounce a bug to when the need arises.
• Identify likely human bottlenecks. Anyone responsible for the distribution of
more than 10% of the total bug count is a bottleneck. Anyone responsible for
more than 30% of distribution has the power to kill your project. Bottleneckers
are discussed in a later chapter.
• Fight against the tendency to want to have all defects go through a single person.
One person just can’t scale his or her time up enough to avoid introducing delays
once the volume increases.
Turnaround time for fixing critical issues must be ruthlessly shortened. Pagers,
on-call agreements, off-hour triage times, and other clever solutions need to be
employed in order to move quickly. Why? Because the alternative is that you miss
tight third-party acceptance deadlines, and these end up impacting either your
manufacturing time or your ship date; because issues won’t necessarily be discov-
ered during the last month of the project; because surprises will arise; and so on.
No matter how good your planning is in the earlier phases of the project, there will
always be some number of last-minute “gotchas” that arise when a group of fresh
testers, all using a new process, start looking at your software.
You’ll need to fix these issues quickly. So, for example, when you’re alerted
via e-mail late on a Friday night that you have failed a memory card text message
guideline, or some similar problem has presented itself, you may need a new build
to be turned around by Monday. If this is a submission candidate, then you’ll need
to give your internal QA team enough time to sanity check the build that you plan
to hand off. Thus, you’ll really need your fix to be understood and implemented by
Saturday night.
Finally, keep your team members well rested during this process so that they can
respond crisply. Wells Fargo stops used to keep some portion of their horses rested at
all times so they could be prepared to deliver a critical message as fast as possible. At
the risk of comparing brilliant developers to horses, do the same with your team. Make
sure that even the hardest workers on your team are getting the breaks they need.
Rested people make fewer mistakes. Insane work hours are never the right answer.

24
 interview with david wiens, project manager at disney online

Interview with David Wiens, Project Manager

at Disney Online
“How Development Teams Can Work Well with QA”
figure
2.5

 avid Wiens has been making games better since 2001. He has worked in localization and as a
D
QA lead for Electronic Arts on numerous AAA franchises, including NHL, FIFA, James Bond, SSX,
and Need for Speed. He is currently a project manager for Club Penguin at Disney Online Studios
in Kelowna, BC. David holds an MBA in Finance from the University of Manitoba. He can be
reached at [email protected].

Q: Tell us a little bit about yourself, your history, and your experience working with
distributed game development. What’s your most recent title?
A: I started with Electronic Arts in the Localization QA department in 2001. Over the years
I held various titles in both the Localization QA group and later on in the Localization
Production group. Working in Localization required you to be able to work with remote
groups, be it either on the testing side or on the production side. On Need for Speed
Undercover I had the job title of QA Development Manager and responsibility for all
aspects of functional software testing. Both the development and testing side were dis-
tributed in various locations.

Q: In your role as a QA development manager for a highly distributed development

project with fierce deadlines, what were some of the techniques you used to help keep
all the different teams on the same page?
A: Early on during the production or milestone phase it was weekly meetings and reports
sent to all different teams informing them of what QA was working on, had accom-
plished and planned to focus on the following week. As we moved into the finaling

25
chapter two • overview of the development process

phase, e-mails, reports, and the amount of meetings increased. I personally use Outlook a
lot to set up recurring reminders to ensure that critical reports are sent in a timely man-
ner. I also use the Task List a lot to write down tasks I need to complete or items I need
to follow up on at a later date. As a project manager you need to figure out what works
best for you to keep track of all the different aspects of the project you are responsible
for. On top of that you need to try and build relationships with all the key people on the
various teams you interact with. A lot of information comes your way informally through
these relationships and will help give you a clearer picture of what is happening on your
project.

Q: What do you see as the biggest problems associated with achieving a high quality
bar on games that are built using distributed teams?
A: Ensuring each group has the internal capabilities and capacity to complete the work it
is given. When working with tight deadlines, any slippage can throw off the schedule and
you either have to find ways of making up time by redistributing work or some features/
functionality may need to be cut to bring the project back in line.

Q: When you think about the full production phase of game development, when all
the teams are pushing for the next milestone, what advice do you have for team leads
on how to best work with your department to ensure that milestone builds are able to
be evaluated thoroughly and quickly?
A: Bring QA in early and show them what you want accomplish. Break your deliv-
erables down into items that can be verified by your QA group (features, game
functionality, etc.) and items that are production/development checks (i.e., imple-
ment new SDK). Then work with your QA group to write test cases that ensure that
all aspects of the feature/functionality will be tested properly at the time of the
milestone.
You should work on trying to get your list of deliverables locked down for the next mile-
stone before the QA group does their full milestone check, and report on the current
milestone (i.e., lock down deliverables for Milestone 2 before QA completes their full
milestone check of Milestone 1). This way, while QA is doing their milestone checks,
development is already working on the next milestone and fixing major crashes or any-
thing that is hindering the QA group from completing their work.
One last thing. If a feature is scheduled to be completed by the middle of the milestone,
do not wait until the end of the milestone to get it verified. Work with your QA group to
have it pre-verified. This helps find software defects early and helps reduce the amount of
time QA will need during their full milestone check. If they have seen a feature fully func-
tional earlier in the milestone, they can spot check it to ensure it is still working and focus
on the rest of the outstanding deliverables.

26
 interview with david wiens, project manager at disney online

Q: What kinds of tools or techniques would you encourage small developers to make
use of to help make the milestone review process go more smoothly?
A: I would encourage small developers to start early on ensuring software stability. At
­various points before the milestone build needs to be delivered, compile it and check
to see what major problems exist or have been introduced, and work to fix them. All too
often QA receives a build that doesn’t boot or fails early on in the testing. This delays QA’s
ability to verify deliverables and send Development their results.

Q: Talk to us about the role of embedded testers in the final phases of a project. When
do you think QA staff or managers should be onsite with developers (if at all)? What
value do you think this adds to the process?
A: Embedded testing during the finaling phase of a project should be used in areas where
a quick turnaround is needed between QA and Development. For example, in cases where
QA is seeing problems with the game that the development group is not seeing or is
­having trouble reproducing, or high-risk areas that require testers to use ­specialized tools
or hardware (i.e., optimization testing). By embedding these testers, you are ­giving the
group of developers dedicated resources which they can work closely with on ­resolving
issues as they arise.

Q: What other advice do you have for readers who are about to embark on building a
game using several teams that are geographically separated?
A: In my opinion, communication is one of the most important aspects of any project.
With having teams in different locations/different time zones, any weaknesses in your
lines of communication will become clear fairly quickly. Working to make sure the right
people are involved in the right meetings or receiving the right reports will go a long way
toward keeping everyone on the same page.

Q: We’ve visited in this book about the importance of concept discovery and the
­pre-production phase in defining project specifications. What role do you believe
Quality Assurance should play during these early phases of a project?
A: I think Quality Assurance can play a role in giving input into features they think would
be of value to the game, generating new ideas, and giving feedback on possible ideas or
themes that Production/Development is considering. This may be a stretch for some QA
groups where most of their work is on the quantitative side of things, but I think this is
where Quality Assurance can provide added value, if asked. Within each QA team there
are the hard-core gamers and probably long-time fans of the game they are working on.
They will have strong opinions of what they like or dislike and have ideas as to which
direction they would like the game to go.

27
chapter two • overview of the development process

2.7 Manufacturing and Distribution

Once your project has finally been approved by the publisher’s agents, and the first
party platform, you’re done, right? Well, not quite. You’ve still got to manufacture
all those discs and boxes, if it’s a retail product. This means another opportunity
for things to go wrong.
Since product recalls from the shelves are incredibly expensive, and tend to
generate ill will with retailers, at the very least you’ll want to test a copy of the
game that’s been burned to final media through the manufacturing process. The
manufacturing plant can likely express mail you a copy. Get your brightest tes-
ters, who are both experienced enough with the game to detect problems quickly
and understanding enough of the importance of this process that they won’t cry
wolf on small issues, to test the game as vigorously as time allows. Only in this
way can you avoid the kind of strange mistakes that only crop up on final man-
ufactured discs but occasionally ruin product launches and relationships with
retailers.
Once you’ve tested this version, and it’s known to be good, you probably won’t
have anything else to do until the game hits store shelves. (But stay by your phone,
and don’t dismantle your development organization just yet.)

2.8 Launch Day

I strongly encourage you to withhold a final payment to each extended team until
some time after the intended launch date for your project. No matter how well
you’ve planned, or how thorough your QA department is, things can sometimes
slip through the cracks.
Once your product becomes commercially available, more eyeballs will be on
it than ever before. If your team is making a major release game, you’ll potentially
have millions of hours of play logged within the first few days. The public is bound
to find problems that you missed.
So be aware and ready on launch day – and for the week that follows. Have
your people trolling the forums looking for early reports. Don’t send your team on
extended vacations until after you’re pretty certain you’re not going to need to issue
a rush job patch or take some other kind of emergency evasive action.
And, of course, if your game is an MMO, your fun is really just beginning.

2.9 Post Launch Support and Updates

For the last ten years (1999–2009), there were two common and fairly separate
ways things could go, once your project had been accepted and put on store
shelves. If you were building a console product, you were done. Your team could

28
 2.10 summary

take a break (and usually some number of them would disperse onto other proj-
ects or other walks of life). Then you’d start planning for the next project. If
you were building a PC project, you’d start thinking about a patch. If you were
launching an MMO, your heartache was just beginning since support and regular
updates are key.
The two models have grown much closer together since the advent of the wired,
always online console. First, users now expect that titles not be “fire and forget” –
and no longer are console patches demanded just for crashes and major security
issues. Even console titles are expected to deliver title updates in response to com-
munity feedback, perceived balance issues, and so on.
Moreover, in recent years publishers of console products have found that one of
the more insidious threats to their profits is the growing popularity of used game
sales. One of the ways to counter this problem is to create longer lasting value by
offering downloadable content or other types of product updates that keep users
engaged. Hence, for months or even years after a title is released, you’ll often be
expected to issue regular updates, extensible multiplayer modes, and other ways of
maintaining user engagement.
Details regarding the management of a permanent development team of the type
required to support year-on-year updates and expansion packs is beyond the scope
of this discussion. However, clearly it poses particular challenges for a highly dis-
tributed team, spread across several discrete companies. If you find it likely that
you’re going to be asked to support the product for an extended period of time,
you’re going to have to find a way to do the following:
• Ensure that you have long-term ownership of any key talent centers.
• Eliminate proprietary knowledge that resides only with one or two people.
Eventually, you’ll lose them.
• Document both processes and tools.
• Invest in operations and certification experts on your team. You’ll be doing lots
of it.
• Start working to build a data mining process to get direct information on how
your users interact with your product.

2.10 Summary
That’s enough overview of the process. In the next chapter, we’ll talk about the
major groups you’ll want to bring in and what kind of people you’ll want to ­surround
yourself with to ensure success for your distributed development project.

29
 chapter two • overview of the development process

Interview with Rhett Bennatt, Art Director, Aspyr Games

figure
2.6

 hett Bennatt has been making games and movies for more than 10 years. Rhett holds an
R
MFA in Digital Media from Texas A&M University. He currently works as an art director for
Aspyr Media in Austin, Texas. Rhett has been involved in creating art and managing teams on
Starlancer, Freelancer, Brute Force, Perfect Dark, The Sims, and Guitar Hero. He can be reached at
[email protected].

Q: Tell me a little about your background in managing international distributed

teams in the U.S. and abroad?
A: My first experience doing any kind of distributed development work was with Digital
Anvil in Austin, Texas. We used a team in Kiev called Boston Animation to generate char-
acters and animations for a third-person action shooter. That was 10 years ago.
Since then, I’ve managed external content development for Microsoft, and on two addi-
tional projects for a company called Aspyr Media. We built three titles under The Sims
brand for Electronic Arts, generating all new content. Some of these were just reskinning
existing assets, and some were all new.

Q: When you’re trying to determine how to coordinate between an internal art team
and external partners, what criteria do you use for deciding who should do what?
How do you ensure consistency between the two?
A: Luckily in this case I had an art lead who had a lot of familiarity with the franchise,
because he’d worked on a Sims game before. So he was instrumental in helping us under-
stand the specifics of what we needed to build. So the way we decided was that any type
of object that was going to be something new that required new functionality – that
we’d have to animate and build hardpoints for and so on – those I wasn’t comfortable
farming out.

30
 interview with rhett bennatt, art director, aspyr games

Q: So the complexity of the assets was the deciding factor?

A: Absolutely. So for many objects, we could just determine what special boundaries
needed to be maintained, then we’d provide reference art and guidelines and rely heavily
on the creativity of our partner team. We knew they had creative staff and we’d let them
run with it, then have our art lead who was so familiar with the content review it.

Q: Did you find that there was any cultural nuance that affected their creativity, or
gave you content that you weren’t expecting?
A: Not really, they were pretty familiar with it, and we had lots of reference. Sometimes
they would come up with something that would end up being a very pleasant surprise
– something we didn’t expect! It’s part of my philosophy to hire really good artists, and
then art direct just by explaining boundaries and not telling people what to do. In this
case, the team we’d hired to collaborate with was excited because they got to really put
a lot of themselves into the project. And I think that may be the nature of that particular
culture, in Mexico, or that particular company.
I’ve heard though that other companies in other parts of the world, like China, are often
more comfortable with exact specifics. So sometimes you may not want this kind of cre-
ative latitude. For some types of projects, creating licensed cars or something, you might
not want that kind of creative interpretation. So it really depends on the project.
The beauty of distributed work is that every project you have the opportunity to pick
your best team for a particular job, and you don’t have to employ them all the time.
You can work with people, find out who is good at doing a particular thing. And a lot of
firms have found out that they can specialize – become great at a particular thing. And
as long as that something is significant enough, then that’s a good business model for
them.

Q: When you’re working with different teams who have never met each other per-
haps, and especially with creative people, how do you instill a sense of ownership
in a creative team without making them feel like they are part of an “art assembly
line”?
A: The best way I know to do that is to allow some room for creative license. There may
be some projects where that’s not appropriate, but I’ve never had to work on one. You
want to have your teams invested in some way, have them be excited in some way. One
great way is to have them see their content in game as frequently as possible, I’ve seen
that pay dividends frequently. Even if it’s just sending them screenshots, it helps them
get excited. There may be some reason they aren’t allowed to have a build of the game,
if they’re not too integrated into the process. But having them see their work, and see
how it impacts the product gives them a lot of reward. No matter what, you need to
do this. But beyond that, you need to find some way for people to have that creative
license. No one wants to feel like they are just a cog in a giant machine – even when
they are.

31
chapter two • overview of the development process

Q: Working for a publisher, when you’re looking to hire a development house for
­content, what are you looking for first? Let’s say they are a first-time studio opening
up somewhere. What would you want to know to hire them?
A: I probably wouldn’t. I wouldn’t want to try to start up something like that right now.
I’ve been solicited by so many studios and art houses over the last few years. There are a
lot of talented groups out there. So you find groups you can rely on and trust, and you’re
likely to keep using them until they fail you.
So for me, it’s all about recommendations. I probably won’t respond well to anyone who
is soliciting me – I’ve got a long list of studios that I trust that I’ve gotten from other direc-
tors and producers that I trust. I also look a lot at credits from other big games, high-
quality games. When I have the opportunity to meet with studios personally, at game
conventions and so on, I try to do that to establish that relationship. I want to have that
comfort level that I’ve met them a number of times. Then maybe I’d be willing to do some
sort of test.
You’ve got to trust whomever you’re dealing with. You’re about to sign a contract that is
legally binding on both sides, and with development costs what they are, none of us can
afford to make a mistake. If things don’t go right, it’s my fault. Even if it’s their fault.

Q: So what’s a warning sign when you’re in the middle of a contract? What clues you
in that something may be going sideways.
A: The biggest issue I see is that consistency can begin to drop off. How do you ensure
that your team remains your team? If you don’t sign key individuals for a contract that
lasts 4 or 5 months, then maybe suddenly things start to change halfway through. Or
maybe it’s as simple as your needs and demands changing.
So you’ve got to truly understand the capacity of your studio. What type of content are
they used to doing? You need to do benchmark processes to establish a quality bar, fine.
But then say you’re building a hundred assets that first month, and you get the quality
to be fine. But then you ramp up to three hundred assets. Means they’re putting more
­people on. How effectively do they scale? This is when the content starts becoming
inconsistent. Too many people, and the art direction on their side can get overwhelmed,
because they just can’t scale up well.
And then on our side, as we scale up, we’ve got to have adequate resources to be able to
provide feedback as well! Because there is art direction on both sides – it’s the only way
to get quality and consistency.
But when you’ve picked someone that you trust and feel good about, you can work
together to work out the problems and deal with the difficulties in scaling, and any
inconsistencies.
And of course, you’ve got to have reasonable expectations. You get out of the relation-
ship what you put into it.

32
 interview with rhett bennatt, art director, aspyr games

When you’re off-site, you’re not looking at the same things. Your perspectives are differ-
ent. Your partners don’t always know exactly what game they’re making. Not intimately
in any case. But that’s where we are in game development. You can’t have sustainable
development with huge teams in the same place.
So I think there is a lot of benefit in taking game development global. I think we’re learn-
ing things from our partners all the time, which I think is great. And they’re learning from
us as well.

Q: In the last 10 years we’ve seen an explosion in team size, in complexity, in the
assets we’re building, and in the associated rise in global distributed development.
How do you see the way we build games changing over the next 10 years?
A: I think the biggest improvements will be in the IT technology side of things. When
we’re working together, how do we communicate better, and remain more in step? Other
than time zone differences, I think that the barriers to fluid communications are going
away. And even the time zone issues are going away. Regular, constant communication
between, say, a studio in Shanghai and the large parts of the U.S. game development
community on the West Coast of the U.S. You’re going to see people working from home
more, and when they’re working becomes more variable. So an artist in Texas might be
working at the same time as my artists in Bangalore.
Having really fluid communication letting you have more face-to-face time, even across
distance. E-mail is so impersonal, especially on the art side. There’s just too much nuance
you miss. Artists especially can be sensitive, so as much of a true human-to-human com-
munication you can achieve the better. So hopefully people will begin to enjoy collabo-
rating in this global development environment. Because they’ll get more out of it than
just the job they’re doing. They’ll start learning about the culture they’re working with. It’s
the path we’re on. And we’re not going to turn back.
Nationalism is a dangerous thing, but in another few decades, there is going to be even
less of it. The world is getting more connected, and the more connected we get the
better.

33
Exploring the Variety of Random
Documents with Different Content
The girl was likewise clad, with bare midriff and a halter of white fur
about her breasts.
"This is the universal garb for counsellors of our make," the girl said.
"Others wear different clothes. Still others wear none, having no
sex."
"I'm Jonathan Morgan. Do Zarathzans—er—have any names?"
"Silly. Of course. I'm Adatha Za."
Jonathan grinned and said, "Glad to know you. And now that
introductions are over, suppose you let me in on the big secret
around here. Just what am I doing on Neeoorna?"

Adatha Za was startled.

"You do not know? Didn't Shar Bytu tell—but perhaps he left that to
me, seeing that I am not a—reptile."
Jonathan looked her over and laughed, "I'm mighty glad you're not,"
and he noticed that Adatha Za—whose civilization was eons beyond
that of Earth—looked pleased.
They walked toward a balcony overlooking a bed of scarlet flowers
patterned between strips of green grass. Great lights beamed into
the blackness of the Neeoornian night from high on the parapets,
lighting the scene before them. And high in the heavens, black and
moving against the blue of the starry sky, strange shadows chased
one another between the stars.
Adatha Za lifted a bare arm and pointed to that great blotch in the
heavens. Her arm trembled against Jonathan even as she pointed,
and he read stark fear in her eyes and in the drooping corners of her
scarlet mouth.
"You see those black flames? No one knows what they are. They kill
us, one by one, when we attempt to fight them. They are growing.
Already they have eaten one of the moons of this planet. Soon they
will reach Neeoorna itself—indeed, they are past the fringe of the
heavenside. And after Neeoorna they will eat the twin suns, and
other suns and other planets. Zarathza and Earth, too. There will be
nothing beyond the black flames, Earthling. It will eat our entire
universe!"
Jonathan was aware that his spine tingled, looking up. He felt deep
inside him, the alienness of those dancing darknesses. They were
not of the known universe. They came from somewhere outside,
from another world. So different from Earth that their mere presence
spelled doom for anything normal to his world. Unhidden, they had
emerged from some deeper space, and were voyaging across his,
advancing inexorably, like flames of fire lapping across thin paper.
The girl's bare shoulder pressed his, trembling.
"I'm frightened, Earthman," she whispered. "When I think of
Zarathza in the path of that—those blights from hell, I—oh, I don't
know how to say it!"
"Yes," he answered soberly. "It isn't nice to think of Earth waiting
her turn, either. Not knowing. Happy until realization comes—"
Earth! It was so far away, so secure and homey. Unaware of this
danger growing millions of light years from it, a danger threatening
extinction to men and the pursuits of men, eating like a living
monster into the suns and planets. Jonathan put an arm around the
girl; held her against him. Lonely, they stood together, awed.
The girl lifted her head and smiled tremulously. She tossed her head
and her hair brushed her shoulders.
"Let's forget them," she brightened. "I succeed pretty well. It's just—
at times—that I feel low down."
"I feel low myself. Don't anyone know anything about them? Can't
somebody think of something?"
Adatha Za leaned back against the marble rail of the balcony and
looked at him and said, "You are big and strong. What would you do
to something that was threatening you?"
"I'd fight," he grunted.
"We fight, too. But our opponent always wins. And when we fight,
we always die."
Adatha Za sighed. Looking down at her, seeing the sweetly curved
mouth that not quite pouted and the straight thin nostrils and deep,
dark eyes fringed with long lashes, Jonathan realized she was a
rarely beautiful girl. He felt suddenly as though he had been jabbed
sharply under the ribs.
"Seeing you makes me want to fight something," he grinned,
laughing a little. "Funny, I haven't felt like this since I was in high
school. It's like the little boy who turns somersaults before the pretty
little girl who's just moved next door. I guess I never noticed the
little girl before."
Adatha Za looked at him, her dark eyes alight; but her thin brows
raised, faintly questioning.
"Some-somersaults? What is that?"
"Oh, just a way of showing off. Putting your head down and—here,
I'll show you."
He dropped to the tiled flooring of the balcony and tumbled. Halfway
over, he found himself looking upside-down at a tall figure who
glared down at him incredulously. Jonathan flushed hotly and landed
hard.
He sat there and felt foolish.
Adatha Za started up, catching her breath in her throat.
Jonathan drew a deep breath. There was a strange malignancy in
the eyes of this man who stood in the arched entranceway and
looked down at him. Malignancy and contempt, and his thin lips
sneered with the livid disdain that moved him.
"You're just asking for trouble, mac," he said quietly, getting to his
feet. "I'm not used to being looked at like that."
The man stood straight and haughty, but his eyes blazed. Jonathan
felt as though he had been spat at. He started forward; felt Adatha
Za's hand on his arm, squeezing him hard.
"This is Morka Kar, Jonathan. He is from Zarathza. This is the
Earthling, Jonathan Morgan."
The Zarathzan did not incline his head. He flashed an irritated look
at Adatha Za, then looked back at Jonathan.
"The guests of Shar Bytu have gathered to meet the barbarian," he
snapped. "He sent me to see if he were awake. I see he is. Be good
enough to show him the Temple, Adatha Za."
He swung on his heel and walked away. Jonathan quivered and took
a step after him, but the girl beside him tugged on his arm, saying,
"It is always his way. He is abrupt, and so self-controlled that
anything like gaiety annoys him."
Jonathan grunted. His lips that had been hard, slowly softened.
"That baby was just begging for a left hook," he growled. "And
something tells me he'll get it, too."
"Morka Kar is a great scientist. I came in his retinue from Zarathza,
to help fight the flames."
"I still don't like him!" Jonathan drew a deep breath and asked, "He
—he isn't your husband? Mate, I mean. Or—your fiance?"
Adatha Za laughed.
"You use quaint expressions. But I follow your thoughts. No, he is
not my husband, nor my engaged. But he does want me. You see,
on Zarathza I am tapu. Sworn to science research, forbidden to wed
a Zarathzan."
Jonathan reflected on that for a moment. He glanced sidewise at her
and grinned, "What about an—Earthman?"
Adatha Za pinched his arm and laughed, "Strictly, there's nothing
against it. Zarathza never even heard of Earth until recently!"

III

The Temple of Embassy gleamed in ethereal beauty under the

beams of Neeoorna's five moons. Its ivory pillars lifted slender
fingers to the black basalt dome. About its periphery an arched court
circled to the entrance where its massive metal gates were
embossed with crouching griffins.
Jonathan and Adatha Za passed along the magnificently marbled
corridors and entered a deep council room tiered with seats. He
paused in the doorway and stared.
On saltwhite benches the representatives of a thousand worlds
turned and looked at him. There were reptiles from Neeoorna,
lavendar-tinted Zarathzans, blobous creatures from distant Sarboola,
thought things of far galaxies, ethereal Tartulians, and queer black
beasts that had the intelligence of genius. Against one wall glass
enclosures held beings from planets so cold they needed artificial
refrigeration to live here. Near the opposite side of the chamber,
steamy glass vases held other life forms whose structure needed
tremendous heat to exist.
There was a tall round rostrum of some glimmering metal raised like
a throne in the center of the room. There stood Shar Bytu, towering
over the assembled hundreds. There was a flash of his greenish
forearm, and Jonathan stepped forward.
"Approach us, Jonathan Morgan," Shar Bytu called. "We of Neeoorna
and the worlds of our universes have waited for you. You are the
only Earth creature we could contact, though we tried many. Come,
join us."
As he went down the aisle, Jonathan cast sidewise glances at the
utterly alien beings that stood and looked at him. Here and there,
though, he saw others like himself and the Zarathzans. Humans.
Men with two arms and two legs. Women with lissome figures and
soft red mouths. He felt a little warmer, and held his head higher,
after seeing them.
He came up the steps and stood beside Shar Bytu. The reptile
nodded, smiling somewhat.
"We had set great hopes on you. Earthling. Before your eyes you see
creatures of bafflement and wonder tinged with a near-despair. The
shadowy flames are a mystery and a menace to us. We had hoped—
we had hoped strongly, that you might bring the solution to their
strange deadliness. I know now they are as queer to you as to us."
"There's more than those flames that's queer to me," replied
Jonathan grimly. "First on the list is how I ever managed to get here
at all. Where I got all those tricky powers from—"
"That," deprecated Shar Bytu by a gesture of his six-clawed hand.
"That is but a simple explanation. You will understand it when I
point it out. You are merely the ultimate goal of evolution."
"Oh," nodded Jonathan, and wondered if he looked blank.
"What is the ultimate goal of evolution but perfection?" resumed the
reptile. "On Earth Nature has experimented with the dinosaur, the
bird, the fish. One by one she discarded them because they were
not fit to survive their environment. But all the while Nature was
learning. It was making strides. It tested and discarded. The reptile
and the early forms of bird and fish and insect life were tossed into
the discard. Nature knew there was something lacking.
"She made man. She gave man the inherent ability to fit himself to
any environment. She gave man a brain, a brain that gave off
energy in the form of thought. Measured energy. Electrical energy.
Energy that can be measured and graphed. But Nature, prodigal in
her gifts, was also prodigal with man's mind. She gave man nine
million brain cells—far more than he ever used. Only a great genius
used one percent of those cells!
"Then why was Nature so lavish? In man she had reached her
absolute ultimate. There only remained for man to perfect the
tremendous, unguessed power of his brain. By thought! By sending
out beams of sheer solid thought, by dipping into those millions of
brain cells for the ultimate power, the power that would make man—
perfect!"
Jonathan closed his eyes, shuddering. He opened his eyes and
looked at Shar Bytu.
"How do you know all this?" he whispered.

He thought in the frightened core of him of changes in the space-

time continuum, that unguessable eons may have rolled past since
last he left the Earth. That Earth was old beyond thought—
Shar Bytu chuckled, "No, I do not have the gift of prophecy, nor am
I repeating history. Except by analogy. For as Nature has treated us
of a hundred and sixteen suns, so Nature will treat man. Nature and
evolution are inexorable, being linked with time. And so she will
produce the perfect man—the man absolutely adapted to his own
environment.
"We of Neeoorna did this to you, by certain—ah—methods. We
operated on you by means known to our scientists for ages. When
we have an atavar in our clinics, we open his mind fully to enable
him to throw off all connection with past ages. So it was with you. It
was not difficult.
"As a result, you are a man immune to harm. You have absolute
control over your body, over inanimate objects that exist about you.
Once you are aware of what danger threatens, you may avert it by
so arranging the electronic groupings within your body either to
merge and blend with the danger, or harden into a shield of antidote
or corrective.
"Of course, as your brain evolved, it needed the body to feed it, to
give it energy. Thus the body became an essential part of it. But the
body changed, too, the body will respond to any environment, as a
necessary corollary of the brain.
"In short, you are the ultimate evolution. It became the perfect tool
of the mind. It did anything the mind ordered it to. So of the third
planet of the Sun Duryu. Or Sol."

Jonathan drew a deep breath. He knew with deepest conviction that

he had heard truth, bizarre as it was. He was not a man any more.
He knew that, within himself. He was as far beyond man, or would
be now, with study, as men were above the Neanderthals. He was
ultimate man. Man in his final stage. Man multiplied by all the
powers that be. Man to the nth degree.
Man nth!
"Now that I'm here, I've failed you," he grunted hoarsely.
"Not yet. Oh, no. Many of us have failed. They are no longer—here.
We still hope that you may, out of your experiences on Earth,
construct us an edifice upon which our scientists may find some
clue, some hint. All we ask is some idea as to what it is we face. Just
a thought. One tiny clue.
"But now you must see how we fight ourselves."
A gigantic, bulbous being, a fishbelly-white due to the heavy cloud
formation that sheathed its native planet five light years from
Neeoorna, rose to his feet. He turned his many-faceted eyes to the
rostrum.
"Shar Bytu," he intoned sonorously, "I ask the right of test for us of
the planet Moratoyo. We would seek to cast a shower of atoms at
the flames. We have made recent improvements over our former
weapon—"
Shar Bytu nodded, and his clawed hand brought an ebony mallet
upon the rosewood pulpit where he stood.
"So granted. Session adjourned. The guests of Neeoorna will meet
at the proving grounds."
In silence the scientists filed from their seats. Jonathan caught sight
of Adatha Za among the Zarathzan delegates, and ran to her. Her
hand nestled warmly in his. She flashed her dark eyes at him and
smiled.
"I'm more out of place here than an Atheist in church," he said.
"Stick to me. I still have to get my bearings."
Her fingers tensed on his, squeezing. He heard her whispered, "I
will."
The proving grounds lay semi-circular behind a great green spread
of lawn. At the north end of the vast field an arc of white marble
terraces lifted rosy columns to the sky. Below the pillars stretched
marble benches, now rapidly filling with emissaries.
The Moratoyons marched to a gleaming gun set in concrete in the
center of the dusty field behind the lawn. The gun shone a queer
white, with two red domes surmounting its breech, and fitted on
either side with knobs and levers. It quivered and gleamed in the
heat haze that shifted over the proving sands.
Jonathan felt Adatha Za press against him with thigh and shoulder.
She choked a whisper to his ears, "It is their atom-gun. It cannot be
compared with some others we have seen, but if they've improved it
—" her voice broke with a soundless sob. "We hope it may work. But
we are—afraid."
Jonathan could almost feel the anxiety and hope around him like a
living thing. From the somewhat transparent thought beings of
Sallarsee to the robotmen of Kankang, each sat watchful; grim,
intent. Those who had lips tensed them to thin lines. Those who had
eyes narrowed them expectantly. The others floated or stood,
quiescent.
The Moratoyons on the field moved swiftly. They clamped brakes
and levers down and locked them; spun wheels and twisted dials.
From the steel and cement cradle where it rested, the great cylinder
of dull white metal lifted its blunt nose slowly, almost cautiously, and
aimed it at the sky.
"It shoots atoms supercharged with light-photons," whispered
Adatha Za.
The chief scientist of all Moratoyo paused and looked at Shar Bytu,
who nodded. The Moratoyon whirled, shouting harshly, watching his
men leap for the firing dials.
One after another the dials spun.
The firing pin was punched.
"God!" choked Jonathan hoarsely, staring in numb horror.
Where once the gun stood bright and shining there was a faint red
mist that hung close to earth, beating bloodily in the flood of the arc
carbon-dioxide lamps as though welling with life. Then it began to
dissipate as a faint breeze wafted across the field.
There was a little hole in the ground, where the gun had been.
Jonathan became aware slowly of Adatha Za's hand that clung like a
vise about his left wrist. He looked at her, saw her eyes convulsively
closed; saw two tears trickling from beneath her long dark lashes.
Her moist red mouth trembled as she whispered, "They all fail. All of
them. Like that. One moment they are here. Then they are gone. It
is almost as if they destroyed themselves."
Jonathan put an arm around her naked shoulders and hugged her
against his chest.
"Buck up," he grated. "We aren't licked yet. Why, hell! We haven't
started to fight, yet!"
He saw Morka Kar sneering at him from two stadium seats away, his
thin mouth curling in fanatical contempt. He felt the hate beat redly
from the man's eyes. Jonathan bared his teeth in answer to that
fierce, unspoken taunt.
He said, loud enough for the Zarathzan to hear, "One of us will find a
way. We're bound to. There's a key to that riddle. There has to be.
The universe can't end—not like this—"
"Perhaps," said Morka Kar loudly, "the Earthling might amuse the
shadows by—tumbling?"
Jonathan didn't know until later that Adatha Za put out a hand to
restrain him. He was away like a sprinter, and his big left fist was
lifting, swiftly. His fist hit Morka Kar, a little to one side of his jaw.
It snapped the Zarathzan's head around and backwards, and lifted
him off his feet, and dropped him three seats below.
Morka Kar lay there outstretched, unmoving. Jonathan grinned
hugely and rubbed his knuckles. It began to penetrate after a while
that the others were staring at him in complete horror.
Adatha Za gasped and sobbed, then came and stood silently beside
him, her soft hand reaching for his fist. She held her dark head high,
and her eyes glared defiance.
"A beast—"
"—useless to expect help from things still ruled by emotion—"
"—a mistake. Shar Bytu should not—"
He heard the murmurs and the whispers, but Adatha Za was
speaking, saying, "Morka Kar insulted him before the assembly was
called. He is not like us, this Earthling. He fights when he is
attacked!"
Shar Bytu waddled forward, his reptilian face grave. He blinked a
little curious, at Jonathan.
"We cannot have disturbances among ourselves," he said. "We need
scientific and philosophic calm to meet the shadow menace."
"It wasn't what he said," Jonathan said softly. "It was the way he
said it. He was asking for it."
"Asking for what?" puzzled Shar Bytu, looking about.
The reptile, moving his ponderous head in looking for what Morka
Kar had asked, struck Jonathan as unconsciously funny. He grinned,
and was buoyed up.
He said, "I'm sorry. I don't want to break up any gathering like this.
Apparently my action strikes you as something primitive. I don't look
at it that way at all. I didn't ask to be brought here, or to be given
the powers to make the trip. Now that I'm here, however, I'll do
everything I can to help. Naturally. But no Zarathzan's going to walk
all over me whenever he feels like it."
A snarl answered him. Morka Kar was climbing unsteadily to his feet,
aided by two Goqualian metallic robotmen.
"Shar Bytu," fumed the Zarathzan, shaking off the hands that held
him. "It has been long since a being of my standing indulged in
personal combat, but I wish to meet this Earthling. Just the two of
us. Face to face, mind to mind, in mental monomachy!"
Adatha Za went white. Shar Bytu looked gravely unhappy.
Shar Bytu whispered, "I had hoped to learn something from the
Earth man—"
Jonathan interrupted, "You're all conceding victory to Morka Kar.
Maybe so, maybe not. That isn't just what I want to say, though.
The main thing that occupies us is the problem of the flames, or
shadows.
"Much as I hate to admit it, I'm afraid I'm not much help against
them. You see, when you gave me the powers of ultimate evolution,
my scientific and other knowledge didn't keep pace with them. There
are thousands of Earth men who would have made better
ambassadors than I. Apparently I was more psychic, perhaps more
malleable in brain structure, than they. I don't presume to know the
whys and wherefores of that. I'm here and I'm glad I'm here. If I
can help, I will.
"But—much as I hate to admit it, I'm out of my depth. Those
shadows, or whatever it is out there in space, is beyond me. So if
you lose me—which I hope you don't—you aren't losing too much."
Jonathan took a deep breath; went on, "A poet on Earth once said
something about not loving a woman loved he not honor more. Well,
I love the universe, but I'm not hiding behind any danger to it when
a man wants to fight me for a woman I—love."
He heard Adatha Za's quickened breathing; felt her hand touch his
arm and squeeze. He stood there with her hand on his arm and
looked about him, at the thought beings and the robotmen and the
reptiles. On a few faces, on the faces of those who looked most like
men, he read a grave applause. On the features of the others, a
blank attention, as though he spoke of geology to a monkey. They
just couldn't get his viewpoint at all.
But Morka Kar did, and he snarled. His sullen mouth writhed and his
eyes glowed fiercely as he glanced from Adatha Za to Jonathan.
"Another thing," grated Jonathan, and he looked Morka Kar full in
the eyes, "I may be an animal, but I know others who possess
animal characteristics—no matter what they mistakenly call
themselves."
Morka Kar fought in the metal arms of the robotmen who flanked
him. Shar Bytu turned and fixed him with a cold eye.
"You will be still, Zarathzan," he whispered icily. "I have long heard
your taunts to one or another of our group. As yet the deputation
from Zarathza has not attempted the flames, though I have heard
many words spoken by them of it."
Morka Kar quieted swiftly.
"The mental monomachy will occur tomorrow at this place. Until
then I forbid Morka Kar and the Earthling to meet. If harm befalls
either of them, the other shall pay with his life. See to it."
He turned and waddled away. Morka Kar seethed a glance at
Jonathan, then followed the reptile. The others split into groups,
silently transmitting puzzled thoughts.

Adatha Za sat on the stone bench and looked up at him, and her red
mouth was rueful. Her eyes beneath the dark fringes of her lashes
accused him.
"I had hoped that some day you would visit Zarathza with me," she
said softly. "Now you—"
"Now nothing has changed," grinned Jonathan, dropping beside her
and taking her soft hands between his. "Shar Bytu made me infinite,
didn't he? How can Morka Kar hurt me?"
Her eyes widened in concern. "But Morka Kar is also infinite, as you
put it. He will fight your mind. You do not know the sciences that
Morka Kar knows. Not knowing what he can do against you, you will
be helpless. He will stun your brain, drive it mad, then—destroy it."
"If I can't think as fast as that bullying windbag, I'm willing to be
destroyed."
Adatha Za sounded annoyed. "It is not a question of thinking fast,
although that does enter into it. It is more a matter of knowing how
to oppose the weapons that Morka Kar will create to fight you."
"—that he will create?"
"Certainly. Of old on Zarathza, men carried swords and shields. Later
they used percussion guns, still later, atomic disintegrators. But as
the years passed into eons, and as life on Zarathza evolved, it was
discovered that these weapons were of no use against a trained
mind that could shoot a bolt of mental force against the weapon to
destroy it. So men went naked into combat and there they thought
up their weapons swiftly, through force of mind alone. Their
opponents met their mental creations with defenses and weapons of
their own. The more unusual the weapon, the easier it was to decide
the victor."
Jonathan whistled.
"My ideas on weapons stop about at a .45 caliber automatic. A
sword is useless. So's a bow and arrows. Or a spear. You say
Zarathza had atomic disintegrators a long time ago, eh?"
The girl shivered.
"Atomic disintegrators are seen only in museums today," she
whispered. "And you of Earth do not even have them. Lallista! You
are a dead man walking around."
"Hey," chuckled Jonathan, grabbing her arms and pulling her around
to face him. "Chin up. I may not know much about weapons, but I'll
bet I've still got a trick or two up my sleeve. I'll show that windbag
where he gets off. You wait. You'll see."
Her eyes begged his for reassurance. She lay close against him and
her mouth quivered into a smile.
"You were—joking me, then? You do know of weapons that you
haven't mentioned?"
"Sure," he boasted gaily. "Lots of them. Brass knuckles. Galloping
dominoes. A ginrickey. A mickey finn. The Brooklyn Dodgers."
"I am so glad," she whispered. "That makes me feel so much
better."
She did not see his frown as she walked with him across the white
composition walk toward their guest quarters. He wasn't thinking of
himself. He was wondering what Morka Kar would do to her—after
he got through with him.
"Just the same," the girl was saying, "I think that I will show you
some of the weapons Morka Kar may use. Those, at least, that I
know. We will go and sit together beneath the moons, and I will
teach them to you, one after the other."
Jonathan looked at her red mouth and grinned, "I'll show you a
weapon, too. On Earth we call it a—kiss."
The night was warm and the moons that hurtled across the
Neeoornian sky shed a pale lustre on the gardens where Adatha Za
and Jonathan Morgan sat. Between her legs lay a box filled with
strips of queerly colored metals, vials of shining dull and iridescent
chemicals, containers and compartments of tubes and alloys.
"It is from these that Morka Kar will fashion his weapons," she said,
fingering the objects before her. "From the mints provided by the
monomachy coffer, he will be enabled to throw weapon after
weapon at you. For instance, this—from this he will make a
molecular magnetizer that will cause the molecules that make up
your body so to attract each other that your body will shrink in upon
itself—assume the density of a dwarf star—fall through the earth to
the center of this planet! Or with this he could form a ray that is hot
as the hottest sun in the universe. He may not use that. It is a
weapon that even Morka Kar fears. It is too deadly. Were it to
escape his mental control, it could blow up the entire planet. Now
from this tube—"
Jonathan listened dutifully. He was in this away over his head, and
no amount of last minute cramming would help. To assimilate this
knowledge would require years. He wasn't quitting, but he realized
that if he did win, it would be by some method purely Earthian, and
not by a study of Zarathzan weaponry.
He looked at Adatha Za. He put his hands on her soft shoulders and
turned her toward him. Her eyes were questioning.
"We have a weapon on Earth, too," he whispered. "It's a kiss. Do
you Zarathzans have the kiss?"
With arched brows the girl followed his thought, then shook her
head a little disdainfully, saying, "No. That does not seem to be any
sort of armament I know. Is it a good weapon?"
"The best there is on a night like this—with a girl like you."

Her mouth was warm and soft and moist beneath his. His lips held
hers for a long time before he let her go. She opened her long-
lashed eyes slowly, staring at him.
"That is no weapon," she accused softly. She put her arms up and
drew his head down again, whispering, "—but I like it. I should
really study it some more."
This time it was the girl whose lips clung.
Jonathan laughed, "For a Zarathzan you catch on pretty quickly."
"I'm a scientist," she retorted.
Nestled in his arms, with her hair flooding his chest and shoulder,
Adatha Za said, "I wish—I wish that you and I could go back to
Zarathza together, Jonathan Morgan. In my villa beside the Jaralayan
Sea I would love to study this kiss-weapon of yours. It is such a nice
weapon, even though it does frighten me a little."
She gasped suddenly and tried to sit up, but Jonathan's long arms
held her.
"Now what's eating you?" he wanted to know.
"That kiss—how many times have you experimented with that
weapon on Earth?"
Jonathan chuckled, "Next thing you'll be telling me I do it like an
expert!"
Head to one side, Adatha Za surveyed him. At last she nodded
pertly, laughing a little.
"Yes, I think you do. And no one ever became perfect without
practice!"
"Don't forget. Shar Bytu made me a perfectionist."
Adatha Za sighed as she nestled back into his arms, and whispered,
"There are some things, Jonathan Morgan, that even evolution can't
do."

IV
Adatha Za came for him the next day, to go with him to the Arena.
Her eyes were dark and sunken, her soft red mouth quivering. Her
hair hung loose, uncoiffed. She came into his arms and kissed him;
drew back to look up into his face, trembling.
"I am glad for last night," she whispered. "Though I did have hopes
—some day in my villa over the Jaralayan Sea—"
She buried her face against his chest, moving it slowly from side to
side, distrait.
"Hey," yelped Jonathan, lifting her face with a finger beneath her
chin. "Why the gloom? I thought we'd decided last night that I had a
chance."
"You did—last night. Today ... today Shar Bytu announced that the
winner of the mental monomachy is to attempt the black shadows!
So—"
"Oof," Jonathan grunted, "that sort of knocks the stilts out from
under a guy. No matter who wins, both will die, unless—no, the age
of miracles passed a long time ago. What does Morka Kar say to
that?"
"Oh, he raved and swore, but he dared do nothing to disobey. After
all, he is a scientist, and he is here to fight those flames. Even he
cannot hope to fight all the scientists on Neeoorna right now. I—I
think he will temporize. Have the monomachy declared a draw. That
will allow him to save face and his life at the same time."
"I'm going to win if I can," Jonathan said slowly. "I just don't cotton
to that guy."
Her long fingernails bit into the flesh of his wrists. Her voice was
hoarse, desperate, "By Lallista's brood, Jonathan! Do not anger him.
Your one chance is in Morka Kar's willingness to spare you that he
may spare his own self. If he loses that temper of his—Jonathan, I
want you alive."
He patted her bare shoulder, smiling.
"I'll still see that villa on the sea, honey. Don't fret your lovely head
about it. But it's time to go, now. I don't want this affair called off on
a forfeit."
They walked slowly, hand in hand, along the pebbled path to the
great white Amphitheatre. It rose tall and grim, brooding over the
lovely square that fronted its entrance. The square was deserted.
Their footfalls sounded loud in their ears.
They went up the steps and through the oval doorway. Alone, they
went down the black corridor toward the arena.
The seats were filled, inside the arena room. The batteries of ten
thousand eyes gloomed at Jonathan as he walked toward the great
ivory chair set on the sanded field. He knew Morka Kar watched him
from the ebony throne opposite the ivory chair, but he'd be damned
before he'd glance his way!
Jonathan settled himself in the seat before he looked at his
opponent. Morka Kar sat facing him, both arms resting on the ebony
arms. His thin mouth was twisted in a sardonic grin. His red-shot
eyes glistened with hate.
Adatha Za came forward with an oblong coffer, ornate with jewels.
Dropping to her knees, she unlocked the cover, and threw it open.
Inside, row on row, glittered vials and retorts of liquids and powders,
and long metal bars and needles.
Above Adatha Za's naked shoulders, Jonathan watched a three-
legged Paravian dance-walk its way to Morka Kar. The Paravian also
carried a monomachy casket.
Adatha Za spoke swiftly: "As you see his weapon form, combat it.
Use the antidote. Not knowing that," she was choking now, almost
sobbing, "not knowing that, attack the weapon with your mind. It
has existence, but it is a mentally energized existence. Mental
energy may dissipate it if strong enough. It is not considered good
form—but it is safe."
The dark eyes shimmered through tears as she looked up at him.
"Farewell," she whispered.
And turned and fled.
Morka Kar stretched out a foot and kicked shut the cover of the
coffer before his throne. The clunk of the closing lid sounded loud in
the high chamber, merging with the breathless gasp that shook the
throng. Only a mathless monomachy fighter scorned the help of the
box.
Jonathan looked at Morka Kar and grinned.
He put out his own foot and slammed the cover down. Dimly he
caught, in some remote recess of his brain, the amaze that held the
onlookers. They didn't know, as did Adatha Za, that the contents of
that box were as much a mystery to Jonathan as were the black
shadows. He'd be better off without it. It gave him less to think
about, and he needed all his powers of thought.
Morka Kar snarled. His eyes blazed right at Jonathan—
Purple balls hung in the air before the Zarathzan!
They shimmered and glittered, filled with opalescent mists of green
and red and white and purple. They danced eerily, as though drunk,
as though to the music of some alien piper. They bounced and
swayed on invisible strings in a wild and eerie saraband. They swung
outward, circling.
Then darted straight at Jonathan.

Jonathan threw every bit of mental power at his control into his
defense, but the first bubble did not break before it got within three
feet of him. The others fell apart easily after that.
Jonathan frowned, and an automatic hung in the air before him. It
turned to grey mists and faded, struck by a bolt of liquid fire.
Morka Kar rasped laughter, "Do better Earthling. We of Zarathza
have forgotten weapons such as that."
A haze of colorless hue quivered in front of the Zarathzan. It seemed
only a heat haze; but when he saw the sandy waste inside the
shimmer, when he saw grey and rolling ocean instead of the sand,
and saw ocean turn to roaring flames, he knew he looked on a
weapon utterly foreign to Earth thought.
His knuckles bulged until the skin over them whitened in the fury of
his concentration. Gasping, he saw the shimmer fade.
He cast a beam of radio-waves; saw them strike a beam of like
power and shatter, useless. He hurled acid. It met an alkali. He
threw a bullet and watched it melt in a shield of heat that turned the
lead to smoke.
All the while the Zarathzan taunted him, shrilling, "Ape. Go back to
the steamy jungles of your planet, ape. We do not need a loose-
brain here. Go back, ape!"
A red triangle formed in the air before Morka Kar even as he spoke.
It glowed and burned with green hell-fires. Jonathan dropped water
on it and the green fires raged and grew and expanded, feeding on
the water.
Jonathan shuddered when he finally extinguished them. Beads of
cold sweat rose on his forehead. He was growing weaker. His brain
could not stand this punishment. He had been subjecting it to too
much. It would give, soon. It was not conditioned, as was the
Zarathzan's.
He thought fleetingly of last night, with Adatha Za's mouth burning
beneath his. Never to know that mouth again! She had trusted in his
strength, in his boasts. She had told him of her villa above the sea.
Now he was to fail her. He had bragged of a mickey finn. Of brass
knuckles. What a crude jest. He had even mentioned—
Jonathan sat upright. He thought.
When Morka Kar saw the club in his hands, he hooted.
"A club! The ape has found a club with which to kill. Lallista! He
jests."
Jonathan swung the wood in his hands with easy familiarity. He lifted
it above his shoulders, then brought it about viciously. There was a
sudden splat.
Morka Kar, still laughing his derision, crumpled and toppled from the
ebony seat.
Jonathan discovered his knees shaking. He sat down quickly.
Adatha Za came running, sobbing, laughter.
"You beat him. You beat him. What a strange weapon. What was it?
Morka Kar thought it but a club. He did not deign to spend his
mental forces on it. But you fooled him!"
Jonathan held up the wood and shook it, laughing, "This is known in
America as a baseball bat. A Louisville slugger. The old hickory, the
ash. And the thing that hit Morka Kar was a baseball. Gods! A jest,
he called it."
Shar Bytu looked from Morka Kar to Jonathan, saying, "You must
destroy him. It is the great rule of mental monomachy."
But Jonathan shook his head, wearily.
Shar Bytu looked down at the Zarathzan. He almost seemed to relish
what he did. But it was over in an instant. A few grains of dust
settled groundwards. Jonathan felt sick.
The others gathered around him. Their voices were excited.
"A new weapon to fight the flames."
"The Earthling has solved our problem."
"If it baffled a monomachy fighter like Morka Kar, it might work on
the flames."
Jonathan tried to explain, looking down at their faces.
"No, no," he cried out, talking down their thoughts. "It isn't a
weapon. It's a sport we play back on Earth. I—it—the bat is used to
hit a ball. Morka Kar didn't know that. He thought it just a club.
"Luckily, I could call my shot. A straight fast ball. Not a curve. A
straight—"
Jonathan blinked. He stopped, choking; eyes wide.
"Maybe," he whispered. "Maybe—"
The others grew quiet, watching. They felt his intense excitement,
saw his hands quiver, and the way his lips twitched. Adatha Za clung
to his arm and her eyes were pools of purple hunger.
It wasn't too fantastic—yet.
It all depended on straight lines and curves, and whether a straight
line can ever be curved. The shortest distance between two points.
If the straight line could be moved to turn, then he was wrong.
But if he were right! If this type of straightness could not curve, then
it might conceivably eat its way through a universe which was based
on something that should curve: light.

Dr. Wooden and he had made strides in their experiments on light

rays derived from calcatryte. They had explored the quantum theory,
had forced homogenous light against a metal plate and seen the
electrons it extracted from it. This light energy had been partially
turned into the kinetic energy of the bombarded electrons of metal.
From this it had been a step upward in discovering that calcatryte
yielded a photon shower of such terrific concentration that it ate
right through the metal plate; had given no evidence of stopping
until they had constructed the plasticite screen: pure black, coated
with a fine dust of calcatryte itself.
They had no way of knowing whether the rays stopped at the
screen, exactly. They might go on and on. And if they ate through
metal, releasing the electrons that composed it—they might eat
through the universe!
Jonathan shuddered and looked around him.
He knew his course, now. But to prove it—
He had to go through the flames!
"You proclaimed that the winner of the mental monomachy would go
through the flames, Shar Bytu," he said. "As winner, and as
representative of Earth, I claim that right."
Shar Bytu looked at him and his eyes were like flecks of cold
moonlight. Suddenly, they twinkled.
"The right is yours, Earthling. And something tells me that you may,
at long last, be the one to succeed. I read it in your mind. Yes, your
theory is a good one. To think that menace came from Earth. From
little, uncivilized, barbaric Earth."
He waddled away, his ponderous reptilian head moving from side to
side.
Adatha Za pressed her hot cheeks against Jonathan's chest. Her
voice was low, troubled: "How will you fight the flames, Jonathan?
What weapon is there that can destroy them?"
"No weapon under all the stars and all the suns can destroy the
shadows, Adatha Za. They are alien. The only hope there is—is to
shut them off."
He shot up rapidly from the sanded floor of the Arena. Beneath him
for one long instant, he saw Adatha Za with her lovely face
upturned: hands clasped between her breasts, red mouth bitten until
it swelled, dark eyes misted. Shar Bytu stood beside her, his scaly
hide brushing her naked arm. The others were grouped in twos and
threes: silent and motionless, watching him.
How long they stood there, Jonathan never knew. His mind was fully
occupied in a furious effort of incredible concentrative power: forcing
his body into the rigid and alien pattern that his mind knew would
alone spell safety from disaster.
Light that never deviated from its straight and ruthless path. Light
that would absorb matter, that would shower a stream of electrons
from it, releasing the electrons in a blast of power that fed upon the
stuff it touched. Such were the black shadows!
And as he hurtled onward into the flames, he forced his body into
beams of light, rigid and unbending. He had to merge with the
flames, or be destroyed.
He hurtled onward, toward the ebony maw that shook and glistened
and bellied against the dark of space like a translucent blob of jelly.
He held out his hands like a diver, going into the shadows. The
movement helped him concentrate on straightness. The wind and
the blackness was about him, licking at his lighteous form. Along his
chest and thighs the flames touched, caressing.
The blackness was himself, now; part of him, a segment of his mind,
a portion of his body.
And he went on swiftly.
Toward his goal.
On the planet, Neeoorna, Adatha Za knew the salt taste of her tears.
Her red lips were puffed by the teethmarks driven deeply into their
softness. Her breasts rose swiftly.
The others stood about her, and their minds were blank.
At that moment they comprehended, but joy and awe were stronger
than mere knowledge.
The black shadows winked once. They winked again, fleetingly.
Then they disappeared.

Dr. Wooden stood silent as Jonathan Morgan drew his hand from the
switch that drove a bath of heat at the blocks of calcatryte set in
their metallic cradles. The humming of motors stopped. The blackish
screen in the background went silent, dead.
"Well," said Dr. Wooden, straightening. "Hello."
Jonathan sat down and put out a trembling hand, drew an open
pack of cigarettes toward him.
"I've been far away," he said slowly. "To the other side of the
universe. Billions of miles away, and yet—in your own backyard."
Dr. Wooden grinned and sat on the edge of the sandstone tabletop.
He lighted a cigarette himself, saying, "Tell me."
Jonathan told him. And then he said, "It seems understandable
enough, really. Those powers I possess. What are they but an innate
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com