Script Doctoring - Professional Techniques for Video Game Writing - page 166

Don't come in and insult the work that's been done already. Odds are that
some of the people you will be working with have contributed to the material that
has been deemed unsatisfactory, and they may still have an emotional attachment to
it. Remember that they've been asked to believe in that material for months, if not
years. Or, they may still be friendly with a writer who is no longer on the project
and feel the need to defend their work. In either case, trying to establish yourself by
putting down what has already been done is a sure-fire way to make enemies, and to
make your job harder.
Remember, your job is not to come in to pass judgment on the work that's in
place. It is to figure out what's needed to move forward, and one of the best things
you can do towards that end is examine what's been done for its good points. Be-
ing respectful toward the work that's been done shows respect for the people who
did it.
Don't try to reinvent the game unless you're told to do so. A corollary of the
need to discover the scope of work you're empowered to do, this axiom is about
as straightforward as it gets. Everything you do—add characters, rewrite lines, add
cutscenes—has the potential to cause other people to have to do more work or spend
more money. Throwing your creativity around willy-nilly will create confusion about
what assets are actually needed, not to mention who's doing them and whether there's
room for it in the budget. More to the point, doing a complete overhaul of the game
based on your vision is fraught with all sorts of peril. Odds are you don't understand
the asset pipeline and schedule completely, so demanding new assets, motion sets,
cutscenes, and the like isn't going to endear you to people you're going to be working
with. It might not even be possible at all, and if you're relying on those new assets to
make your stuff work, you'll be out of luck.
And the project will be, too.
Don't set yourself up as the final authority. As seductive as the fantasy of coming
in at the last minute to save the day can be, it shouldn't be confused with the reality
of the situation. The odds of a writer being handed complete control over a project
to make sure everything else jibes with the story are somewhere between “low� and
“nonexistent.� Instead, make sure you set up working relationships with the point
people on the team so that you're in the loop on decisions that relate to story. This
can work just fine and makes sure that writing concerns are taken into account when
changes are made. What won't happen is everyone else kowtowing to writing's needs,
and if you expect it to go that way, you'll look foolish.
It's perfectly sensible to expect to be in the loop when changes affecting story get
decided on. And yes, this can include everything from level design to seeing which
motions are included in the animation set. But expecting story—and by extension,
yourself—to be the final arbiter over what goes in the game is asking for trouble and
a very short working relationship with the rest of the team.
Don't prioritize your agenda over the team's. There are a lot of people working
on a game at any given time, and ideally, they all have the same agenda: to make