in enthusiasm? Now why would we ever want to do that? Isn't keeping
the team motivated one of the most important factors of game development?
Doesn't every management book you've ever read stress how important
it is to keep the team motivated?
thing is, almost by definition, videogame developers are motivated.
I've never seen a videogame where the developers didn't want to
put more features and content into the game than they could possibly
have time for. Motivation and enthusiasm, in this industry, is just
about a given. Where this hurts us is when:
do a bunch of things halfway and don't have time to take them
all to completion: we might have been able to finish one whole
level in the time it took to do those two levels halfway.
save bug-fixing for later, and the cost of fixing those bugs goes
cut corners and work inefficiently.
do the wrong things: our pet features, or the publisher's pet
features, instead of what's important for the game.
need to rein ourselves in. We could tell everyone on the team that
they suck and their ideas are valueless, but that may be going too
far in the other direction. Here are a few good ways to apply reins
without turning the entire team into a bunch of listless zombies
who just phone it in.
my column gets to schedules. Why did I wait so long? Given a choice
between doing something right and doing it on time I'll take doing
it right, and schedules can create the wrong kind of mentality,
encouraging people to rush crap out the door. Still, although I
don't place the priority on schedules that others do, if we want
to do things right and on time they are a useful tool.
thing we almost always see in the "What Went Wrong" column
of a lot of postmortems, even ones for successful games, is "we
had an impossibly aggressive schedule that led to much crunch-time
and cutting of half-assed features." Let me play devil's advocate
for a second: maybe this aggressive goal setting is actually making
these projects more successful, because everybody's putting in 110%,
and nobody is gold plating? Steve McConnell would shoot me for saying
that. Aggressive schedules make projects later, not earlier, he
claims, because the cut corners reduce efficiency.
is one team that backs up McConnell, that has successfully shipped
two great games on time in reasonable timeframes that does effectively
schedule: Monolith, with their No One Lives Forever series.
I'd like to believe that if everyone followed their example we'd
see more great games.
in Monolith's postmortem
they did not go into detail in the techniques they used to schedule
their project. The best technique I've used for scheduling programming
comes from Joel Spolsky.
We've used his system to schedule coders with great success. It's
always surprising when you implement it, and you realize just how
few features you're going to be actually able to finish before your
code complete date. That realization is when you begin to know you're
being realistic for the first time.
having a system in place does not guarantee success. I've seen teams
using the schedule system fail, and the reason seems to be because
it was not maintained. Just making sure everyone reports their progress
every day is not enough; when unplanned features rear their ugly
heads, they have to be added to the schedule. And when dependencies
exist, they have to be reflected in people's priorities.
people, such as Erik Bethke and Mike McShaffry, use MS Project to
track their schedules. That's fine, as long as you maintain it.
I've tried working with it and it wasn't for me.
One thing Spolsky, Bethke, McShaffry and myself agree on is this:
the people doing the work must estimate their own schedules.
We can coach them on how to do this; we can help them break a task
down into subtasks; we can even - very rarely - ask, "Why is
this going to take so long?" when our intuition tells us to.
(Usually it's because the developer wants to do a better job than
they have to.) But the buck stops with the individual developer.
They know the systems they're working with; they know their capabilities;
and they need to buy in to the schedule they're going to be working
you can avoid it, don't let a developer switch from one task to
another until the first task is complete. It sounds obvious, but
the temptation is extremely hard to resist in practice. When you're
working on a videogame, everybody wants everything done yesterday.
"When are the drop shadows going to come on line? Why isn't
combat fun yet? We need to get the beginning of the game done, because
that's the hook that sucks the player in! We need to get the end
of the game done, because that's the climactic finale! We need to
get the middle of the game done, because Noah Falstein says so!
(See Noah Falstein's Begin
at the Middle.) In this kind of chaos, priorities shift
before tasks are complete, people are moved off task, and you end
up with a lot of half-assed features and nothing fully-assed. This
is compounded by requiring multiple people to work on features.
When the feature gets handed to person B, he either needs to go
off-task to work on it (gasp!) or he needs to let it sit idle (gasp!)
how do we do it? Just Say No. Educate all the people on your team
about why they shouldn't be switching tasks, and when you see somebody
who seems to be task-switching, call them on it. Look through the
schedule for people who have a few tasks that are all partially
complete. Usually there's a good reason for why they were unable
to complete the original tasks, but it's worth looking into. When
asking for a small unplanned feature or a bug report, make it understood
that you don't need it immediately. "When you get to a good
stopping point, can you do this for me?"
Have A Focus
than a few successful projects in the Gamasutra postmortem files
mention having a "focus" or a "vision" or a
"mission statement", including No One Lives Forever
("We drafted a clear, concise mission statement to make sure
we wouldn't lose sight of our goals."), Ratchet and Clank
("There's a solid structure in place to ensure that we adhere
to the macro design and remain consistent with the game's "flavor."),
Rainbow Six ("We established early on a vision of what
the final game would be and we maintained that vision right through
to the end."), and Deus Ex (Their vision is printed
in their postmortem.).
A friend of a friend (isn't everybody in this industry a friend
of a friend?) said one of the first things they did when designing
The Two Towers was ask, "What is the 'it' of
this game going to be?"
are many reasons to have a focus, but the one we care about here
is this: feature creep is easily curtailed when people - either
on the team or from the publisher or marketing department - suggest
features that are nonessential to your core gameplay. "That's
not what our game is about," you say, and you move on.
Adams has made a joke out of it: when Dilbert answers the phone
at the company without a mission, he says, "I don't know if
we do that." When he answers the phone at the company with
a mission, he says, "We don't do that." It's no joke.
You want to be able to say, "We don't do that," for as
many features as you can.
what it's worth, the vision for the yet-to-be-completed Spider-Man
2--which creative director Tomo Moriwaki explained to the team
in shifts because we can't fit the entire team in one meeting room--is
focused on the way Spider-Man moves, with combat playing a mere
supporting role to that central actor. Other traditional elements
of Spider-Man, such as his photography, his spider-trackers, and
his alter-ego as Peter Parker, are almost ignored so we can focus
on One Thing. We'll see how it goes.
Jake Was Doing In Chinatown
pressure to add new features and keep half-assed features and not
cut people's pet ideas is immense. They'll imply that you are lazy.
They'll ask you, "How much time will it take?" (Eric Bethke's
correct answer to, "How much time will it take?" is "Let
me get back to you." Don't just get back to them with how much
time it will take. Get back to them with a list of other features
you can cut to make the feature they want happen. It helps for people
to see the real trade-off.) They'll ask you, "What are the
risks?" Push back against these forces. Remind people what
Greg John, my producer, has posted on the wall of his office:
is achieved, not when there is nothing left to add, but when there
is nothing left to take away.