112 THE GAME PRODUCTION HANDBOOK, 2/E
part of the lead’s role and provide the management or technical skills the lead is
lacking, or may unofficially grant lead status to a junior member of the team who
shows a lot of promise as a future lead. If you are stuck with a lead who becomes
a liability, try to deal with the situation without further alienating any of the team
members who are under this lead.
7.4 TEAM BUILDING
Team building is a critical part of the game development process and often
one of the most neglected. There is a common misconception that assigning a
group of people to work together creates a team, which is definitely not the case.
A group is comprised of individuals whose work is directed by someone who
is head of the group. A team consists of a group of people who are working to-
gether toward a common goal and are holding each other mutually accountable
for the outcome, which is a big difference from a group. To have strong teams,
the teams must be built and supported throughout the project.
EFFECTIVE LEADS
Jamie Fristrom
Torpex Games
An effective lead can’t just be an expert in his field; he also has to possess strong
people skills and the ability to be a leader. People skills determine how effective his
management style is for getting people to do what they’ve been asked to do. It is
common for people to get promoted to a lead position based on their talent alone,
but they often don’t have the leadership skills for the position. If a lead cannot cor-
rectly manage the people under him, these people will not progress in their skills or
careers and will become frustrated, which contributes to low morale and puts the
project at risk. If someone is not working out as a lead, it is fine to put them back in
their old role. This was done a few times at Treyarch without any big problems.
It is better to promote people who exhibit natural leadership skills instead of
assuming it is something that can be learned. There have been situations in which
someone is promoted to a lead position, and it is evident within six months that this
person is not suited for the job. At this point, it is probably too late to train him to be
a lead, so your choices are to replace him with someone else, appoint a co-lead, or
hope that he can finish the job without putting the project at substantial risk.
TEAMS 113
As the project leader, one of the producer’s main responsibilities is to build
a strong team by any means necessary. This task is not for the faint of heart or
for those who are timid around people. For one thing, you must be able to deal
effectively with all different types of personalities and get them all working in
harmony with each other. You need to deal with your team as both individuals
and a team by creating the best working environment you can for the individual,
while still doing what is best for the team.
Also, a producer takes some risk in getting people to participate in “team-
building” activities, especially because such activities can best be described as
corny or cheesy. However, if the producer makes no attempt to build a team,
he will never have a team, just a group of people doing work as directed by their
lead or producer—meaning no sharing of ideas, no collaboration, no sense of
ownership or pride in the project, and no passion—which can lead to less than
stellar games that don’t register on consumers’ radar. This section discusses some
simple team-building techniques that have proven to be effective in a game de-
velopment environment.
CHALLENGING PERSONALITIES
Melanie Cambron, Game Recruiter
Intelligence, combined with creativity and quirkiness, is common in the game
industry and also makes this business unique relative to other industries. The in-
dustry often attracts (or breeds) people who are brilliant at their jobs but have dif-
ficulties socializing and meshing with others. With these types of personalities, you
have to educate both the client and the employee on the situation and try to find a
way that this person can fit. Because game development is collaborative and socially
oriented, it is a rare instance when an arrangement can be made so the person can
just sit at his desk and complete his tasks without interacting with anyone. When
you are looking to add talent to your project, be certain their personality blends well
with the team.
Similarly, it is vital that the team be led well. Egotistical, verbally abusive leads
have destroyed teams, creating working environments so bad that talented people
leave the company just to get away from this person. Management needs to continu-
ously monitor team dynamics and create a working environment that allows open ex-
pression so they can be made aware of situations like this and nip them in the bud.
In sum, social chemistry is critical to a strong team, and whether brilliant junior
programmer or veteran lead designer, the social stuff does matter.
114 THE GAME PRODUCTION HANDBOOK, 2/E
Getting to Know Each Other
How well do you really know your teammates? Even though you might have
worked on one or two projects with them, do you know exactly what they con-
tribute to the project, or better yet, do you even know their first and last names?
Small development teams of ten people or less may know this information,
mainly because everyone on the team fulfills multiple roles and is dependent on
the work of several others on the team.
However, as development teams get larger, it is not uncommon for someone
not to know everyone’s full names or even who is on his team. This basic infor-
mation is important for people to know. This might seem elementary, but there
are instances every day of someone asking their friend in a loud whisper, “Hey,
who’s that guy? Is he on my project? What does he do?” Providing answers to
these simple questions can go a long way in building a strong team.
One of the first things to do when a new team is assembled is to have every-
one introduce themselves and briefly describe what they will be doing on the
project. They only need to spend a minute or less doing this; most people will not
remember everyone’s names after this initial meeting anyway, but this exercise
starts the “getting to know you process.”
If anyone new is added to the team, send an introductory email to the team
a few days before the person starts working there, and then on his first day make
personal introductions to everyone on the team. There is nothing more awkward
than for someone to come into the office on Monday morning and see a stranger
sitting at a nearby desk. This awkwardness increases if the new person and his
teammate are never introduced to each other, especially if neither party can
overcome shyness and make their own introductions; they could end up working
side by side for weeks and still have no idea whom each other is.
If there is money in the budget, consider having a project kick-off event at
a local bowling alley or restaurant to give people the time to socialize with each
other in a nonworking environment. People might feel more comfortable inter-
acting with each other in this casual setting, and it allows them to get a better feel
for what the other people’s personalities are like.
In addition, create nameplates with the person’s name and department. For
example, “John Doe, Character Artist.” These are displayed on people’s desks
and provide an unobtrusive way to reinforce everyone’s name and what they do
on the team. As people put faces to names and see who is responsible for which
cool features in the game, they might start talking with people they’ve never
interacted with on a personal level. Nameplates also make it easier for a new
person to become familiar with his teammates and their job roles.
Set aside a few minutes at each weekly team meeting for one or two peo-
ple to give a five-minute presentation on their game development background,
favorite development techniques, hobbies, or anything else they want to tell the
TEAMS 115
team about. People on the team might find that John Doe shares their same
interest in hang-gliding, World of Warcraft, or big band music, which goes far
in creating more rapport among team members. In addition, these presenta-
tions are something fun and interesting that the team can look forward to in the
weekly meetings.
BUILDING A STRONG TEAM
Wade Tinney and Coray Seifert
Large Animal Games
At Large Animal, we are committed to building a strong team that works well
together. Although it may be easier for the 12-person company than it is for larger
companies with hundreds of employees, team building can be effective at a com-
pany of any size if there is a commitment to do it.
We want everyone working at Large Animal to feel a strong sense of creative
ownership of the games we make. The fact is, everyone on the team has a deep
impact on the game, and the finished product is a reflection of their collective
effort. Great ideas can come from anyone, and we want everyone on the team to
feel comfortable sharing their thoughts with everyone else. Also, we find that people
enjoy themselves the most and do their best work when they are excited about the
material, and they like to do lots of research to get to know the content with which
they’re working. For example, when we worked on Rocketbowl, we took the whole
team bowling so they could figure out other gameplay mechanics that would work
well with bowling. These sorts of “field trips” are not only a great way to stimulate
new ideas about the game you’re working on, but they also give people a chance to
establish rapport with each other outside of the office—another important aspect of
building strong teams.
Effective team communication is important even when it’s not directly about
the games we are building together. At Large Animal, we all eat lunch together
almost every day and discuss the latest movies, games we’ve been playing at home,
and other outside interests. We also play board or card games, which is a great
excuse to interact with each other in situations that don’t solely revolve around work.
Not only do these analog games often give us ideas and insights into the digital ones
we make, but it’s amazing how much you can learn about your fellow team members
and their individual strengths by sitting across the game table from them. Otherwise,
we might never have known that our lead programmer, Yossi Horowitz, has such
an incredible poker face. We believe that the most efficient team communication
116 THE GAME PRODUCTION HANDBOOK, 2/E
Role Definition
People on the development team have a strong desire to contribute and want to
know exactly what their role is on the team. Conflict is generated if roles are not
clearly defined. For example, if there are two lead artists on a large development
team, and they have not defined what areas each of them is overseeing, confu-
sion results. Artists on the team won’t know which lead to go to with questions
or problems, and the leads themselves won’t know how to definitively allocate
any new art responsibilities, which might result in features and assets being
unfinished when the game ships. The artists and the leads will become increas-
ingly frustrated with this situation, leading to less efficient and lower quality
work and possibly conflict between the leads and the artists.
This frustration can also occur if a junior programmer does not specifi-
cally understand what his tasks are on the project. If the lead engineer tells
a junior programmer to work on the user interface but never states exactly
what the expectations are, the junior programmer won’t know whether he is
supposed to be leading a task force to get the UI designed, prototyped, and
implemented, or whether he is supposed to merely implement the tasks he is
given (but at the same time he might not know who is responsible for assign-
ing him tasks).
These situations can be remedied by clarifying people’s roles. Jim Lewis,
author of Team Based Project Management, has developed a simple role clari-
fication exercise that can be done at the beginning of the project, and should
be done during the project whenever new people are added or there seems to
be role ambiguity. This is also a good exercise for the producer and leads to do
during pre-production, so that everyone is clear on who is responsible for which
aspects of the project.
is built on a rich shared vocabulary of jokes, references, and memories. Conversations
about work are just much more fun to have with someone with whom you enjoy hav-
ing nonwork conversations.
We want everyone to have an understanding of how the individual tasks they
are working on fit into the big picture of that game. One thing we do to encourage
this is by starting each morning with a short team meeting. We spend about 25 min-
utes talking about what everyone did the day before, what people are working on
today, and whether there are any roadblocks that will prevent that work from being
completed. We learn a great deal about each other’s work patterns from hearing
everyone talk about their tasks. Occasionally, someone won’t realize there is a prob-
lem they can help with until they hear about it in the meeting.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.