Most of the training writers get revolves around – get this – writing. And that makes a certain amount of sense, seeing as how at the end of the day, the writing is what you’re there to do.
Unfortunately, writing isn’t the only aspect of the job. There are a whole lot of other things you need to do as a game writer to ensure you are in a position to write well, to write efficiently, and to write in a way that jibes with the needs of the project. The best writing in the world won’t get the job done – and neither will you – if you’re constantly tangled in a web of impossible feedback, slow signoffs, confusing direction, and contradictory scheduling demands. So take these lessons into consideration. They just might save – if not your life – then at least your job, your sanity, or your schedule.
Build Your Feedback Loops And Guard Them Jealously
Everybody in games gets feedback. Whether it’s level reviews designed to give feedback to designers or playtest sessions, every aspect of a game gets reviewed, critiqued, and commented on so it can be improved in the next iteration.
Which is why it behooves you, as a writer, to set up feedback loops within your team so as to maximize your productive writing time. What that means is figuring out who should be commenting on your writing, getting them to agree to do so, and making sure they do so in a timely fashion so that you can take the feedback and run with it. Note that this does not mean embroil your senior producer in a daily debate over the merits of the Oxford comma; it does mean figure out who needs to give you signoff, and make sure they do it in a way that works for you and them.
Of course, the flip side of that coin means jealously guarding the borders of your feedback loop. Story is something that everyone has an opinion on, and if everyone who wants to weigh in on your work gets to, there’s a reasonable chance you’ll end up with a list of 37 mandatory signoffs before you get to change your first pronoun. It’s not that feedback from people outside of your core loop is bad; far from it. Regular script and story reviews with folks who aren’t already soaking in your stuff are wonderful things. But not everyone needs to be involved in every discussion about every line, no more than everyone on the team needs to sign off on every level or feature review. If you have to wait for those 37 approvals on every single deliverable, when folks are sick or busy or out of the office or, well, you get the idea. But you won’t get the authorization, not in a timely way. So when you build your loops and get everyone to buy into them, also make sure your stakeholders will defend the process you’ve all agreed on. You saying “no” to more feedback can make you look like a prima donna; a producer invested in your production pipeline saying “no” looks like someone who’s sensibly defending an efficient pipeline.
So pursue feedback, and make sure it gets back to you fast. The less time you sit around waiting for feedback – or watching two people with conflicting feedback fight – the more time you have to sit down and actually write.
Learn Which Voices To Listen To
Human beings like to give feedback. It’s part of our nature. We want to be involved, we want to feel like we’re contributing, and we want to make things better.
Unfortunately, those tendencies can be used for evil as well as good, particularly when it comes time to generate feedback on game writing. At any given time, somewhere there is a game writer who has just gotten two mutually contradictory notes on something she’s writing, and will be expected to satisfy the demands of both sets of notes in the next draft.
Obviously, this is untenable. It’s also largely inescapable, unless you get – and reinforce – clear guidance on whose feedback carries weight. Sit down with your leads and hammer out a definitive list of who gets actual oversight and whose feedback can be read as just suggestions. That’s not to say that people who aren’t part of the inner circle won’t have good thoughts. But you’ll absolutely need to know, when push comes to shove and two notes are in conflict, which one carries more weight. (You also need the people who define that pecking order to back you up when you follow it, but that’s a whole other matter).
Make Friends In Other Departments
With the possible exception of twine projects, games are not made by writers alone. There are a great many other people on any given project, and as a writer you will be interacting with a great many of them – or their disciplines – as development trundles along.
With that being said, it’s a great idea to get to know some of these people, and to do so in a friendly, non-threatening manner. There are all sorts of reasons for this, starting with it’s good for you, but just as importantly, it will make your work better.
Establishing friendly relationships with folks in other disciplines means that when there’s a disagreement or a conflict, you’ve got a relationship in place to help you talk it out. That’s a helluva lot more efficient than walking into a conference room with total strangers who don’t know you or why you’ve made the decisions you have, and who don’t necessarily know how to communicate effectively with you. The more friends you make on the team, the better you can understand the needs of their disciplines and put that into effect in your work, saving everyone a lot of agita. And, to be blunt, this will make it easier for you to raise questions informally before they become formal, full-blown situations.
Find Out What They Need, Not What They’re Asking For
Using words precisely is hard. That’s why there are people who specialize in doing exactly that; they’re called “writers.”
All joking aside, though, not everyone can communicate directly what they actually want. So, rather than just relying on design documentation to describe writing deliverables, it’s best to sit down with the folks who need those writing assets and talk with them, in order to find out what they’re actually looking for. Because if they haven’t been able to fully articulate what they’re looking for – and this isn’t a knock on anyone, it’s just how it goes sometimes – and you give them exactly what they ask for, then odds are it isn’t going to work as designed in game. And if you throw in things like language barriers or multiple intermediaries, well, it can just get messy.
So be sure to make the effort to really collaborate. Check in frequently with samples to say Is this what you want? How’s this? and take the feedback seriously. The quicker you can zero in on what’s actually supposed to be there, the sooner you can start hammering it out, and the less time you spend going down blind alleys or, worse, generating game assets that won’t do the job.
Learn to Say “No”
Not every request, even when it comes from the top, is a good one. Ideally, you’ll be working in a space where you’ll be able to raise objections to bad suggestions/requests/demands without having to implement them. And if you are in that space, do not hesitate to use that power.
That’s not to say you need to fight tooth and nail on every adverb. Saving your bullets for the fights that really matter simply makes sense. But when a truly bad idea comes down the pike, you should feel comfortable enough – and empowered – to challenge it if it’s for the good of the game. I don’t like this isn’t a good enough reason to say no. This is a problem because… is, and then be prepared to show your work. If you can explain why implementing a request will make the game worse – it breaks this other element, it doesn’t work with the protagonist as we’ve established him, it sounds bad in prototype, it’s going to require $200K in re-recording – then you can stand up on your hind legs and draw a line in the sand. It won’t always work, but if the evidence is on your side, it’s worth doing. And if it staves up a potential mistake, well, you’ve got more cred for the next time you choose to plant a flag.
Remember the Magic of “Why”
A lot of people are going to have ideas for your work or feedback on it. Not all of that feedback is going to be good, and not all of the good feedback is useful feedback. Which means there are going to be a lot of times you’re going to be saying “no” to ideas people are giving you.
Now, there are different ways to handle this. One is simply not to include the suggestions and then ignore any questions about why you did it that way. This model is generally known as either “dumb” or “bad,” as it generates hostility and resentment, and makes it that much less likely that anyone’s going to listen to anything you have to say about any other aspect of the game.
On the other hand, what you can do productively in cases like that is get back to the person responsible for the suggestion with an explanation – not a value judgment – as to why you’re not incorporating their suggestion. Explaining why something doesn’t work or can’t be used – even if it is good – goes a long way. It keeps you from looking like an arbitrary jerk, and it potentially gives the person you’re talking to some insight into your decision making, so their future input can be more in line with what you need. And while you can’t take the time to sit down for four hours to discuss every single phrasing choice with everyone who has a concern, taking time to follow up with people who’ve shown a genuine interest in the writing means other decisions you make down the line might get more benefit of the doubt from them.
Learn to Say “Bleep Off”
But do it politely.
Look. Everyone’s going to want a piece of your time, most of them have no idea how long a writing deliverable takes, and most of them aren’t going to come to you unless it’s an emergency. All of this means that you can acquire a stack of High Priority Emergencies faster than a rogue Kardashian can spin off a reality TV show.
It doesn’t take a genius to realize that you can’t do all of them simultaneously. Some of them have to come first, and some are going to have to wait, and some – gasp – might not fit into your schedule at all. Which means learning to stand up to those swooped-in death requests. Ask what the priority is. If they say “urgent”, then ask if it’s more urgent than any of the three other urgent things you’ve got on your desk. Don’t hesitate to get the requestors of your other crises involved so they can fight it out amongst themselves for your time and you don’t get a rep for being “difficult”. (“Difficult,” by the way, is dev-speak for didn’t do exactly what I wanted him to do. It lurks in performance evaluations like a pocket of MRSA, and is just as dangerous.)
And be prepared to say, politely but firmly, I’m sorry, I need to get these other things done. I’ll be free tomorrow; if you need it before then, you need to take it up with the producer/lead/person who controls my schedule. Not only does this turn a lot of the “immediate” requests into something less urgent – because pestering a producer is more daunting than pestering a writer – but it also raises the issue of the bad scheduling that produced this urgent need to the producer level. And if there’s one thing producers love to do, it’s straighten out process problems so they don’t recur (and waste time and money).
Words to Live By
How you work is, in many ways, as important as your work. It’s in everyone’s best interest – yours, your writing’s, your coworkers’ and your project’s – that you not only do good work, but that you work (and play) well with others. To expect that the quality of your writing is going to blithely overcome all hurdles (and blithely split all infinitives) is dangerously naïve at best, willfully ignorant at worst. Nobody’s writing is that special – not yours, not mine, not anyone’s.
So do yourself and your words a favor. Put yourself into a place on the team where it’s easy and positive to work with you. You will find you’ve put your words in a better place to succeed, too.
For more of Richard Dansky’s advice for writers here: