Wednesday 30 July 2014

How to Work With a Writer (Or a Guide to Why Your Writer is Sulking)

So the day's finally come. Your studio has been politely informed by the publisher that all successful games have a story written by a dedicated writer now and (perhaps using these tips) you've found yourself one. What now?

Not all jobs start out like this, but it's still common enough for a writer to wind up in a room full of people who have never worked with a writer before, who had no hand in hiring them, and really would quite like to get on with making their game now. I hear you. A writer's job is to understand the project's particular requirements and to support the team (some more from that perspective here).

This being said, there are also some good practices for teams engaging a writer that will make everyone's lives a lot easier. These are, of course, ideals, and subjective ones at that - not every project will be able to support all of them.

This is the guide to how to get the most out of your writer, or how to work out why they're sulking.

Know what scale of narrative your team can support, and be clear about it
Writing is not intrinsically valuable, in the context of game development. Some games are simply better without it, others are better with only a little of it. A small amount of good writing is better than a lot of bad writing. Know what you can support, and make this known to your writer at the outset so they can consider it and plan accordingly.

If you want your game to be 3D and story-driven, both you and your writer are going to have to work a lot harder to implement the narrative than if it's to be 2D and abstract. For the story to work well you need someone at the top who is overseeing every element of the experience - level design, object placement, visuals, voice work, the lot. This is your narrative designer. Now, that person might also be your writer, but they might just as well be your creative director or team lead. What matters is that someone is in that role, because otherwise you're going to end up with a bunch of disjointed elements, an incoherent narrative and a writer in a sulk.

Be aware that story is a two way enterprise
Story is rarely something that can just be bolted on at the last minute to good effect. As much as your writer should come onboard and work towards the framework you have, some give and take will make for a more cohesive product. Yes, your writer could bend over backwards to shape the story to your every specification - but absolute rigidity here due to schedule or budget or whatever is just going to close off fruitful avenues.

Of course, sometimes budget or schedule does force the issue. That's fine, it happens - but in those cases it's extra important that you be clear with your writer from the get go what those restrictions are so they can do their best within them (or flat out turn you down if it's completely bonkers). No one wants a sulking writer.

The more fluid the story development, the better
It's an unfortunate fact that often enough good stories are developed in a quite different order to how many studios order their internal development. In level design, for instance, altering the layout of one level needn't have repercussions for the layout of other areas. You can happily design the big budget levels and art assets , sign off on them, then rehash the intro. 

In story, rehashing one scene can have radical impacts on others. In fact, redrafting is central to producing a strong story. This is the reason that the fear of god will come over your writer when you start talking about building the pivotal scene for your vertical slice, before you finish planning the main plot arch. Any section of the story that's locked down early is like a tetris piece that doesn't dissolve. You can work around it, but that high score will be much further away. For these reasons you'll get the best narrative results when you schedule development in a way that leaves story-sensitive elements as open as possible, for as long as possible. Obviously there is a balance here.

You may also want to ensure that your writer is available throughout development, so that when you make changes to the game design on the fly they can make appropriate updates to the story. Sure, you could just book your writer for two months at the start of the project to write the script and knock it off the list, but this will scare them no end. Things will change during development which will put their writing out of context, and their reputation will depend on whether or not you pick up the phone to have them correct it. Some of the work I'm most proud of has been at the end of a project, where I'm entrenched with a team doing crunch time, keeping pace with their design changes, and developing creative solutions on the fly.

Writers want to collaborate with you, not be used as a service.

Give your writer some space to write
On most of my projects I have had teams who gave me a brief and told me to ask if I needed anything. This is great because it gives me the freedom to experiment with what works, and to spend the time where I think it's needed. On some projects I have been more directly managed, and which works best is really dependent on the nature of the job. On FTL, for instance, where I'm just producing independent text events to populate particular sectors of space, I don't need space to plan or redraft because for once the kinda work I'm doing is well-suited to a factory-line approach. 

On projects where the role is more involved - a full narrative design role - it could be quite restrictive to have someone else decide what you're working on today. Sometimes designing a character will give you ideas for a dialogue scene that you just have to write while it's fresh. Sometimes you won't really know who the characters are until after you've finished the plot. Sometimes you'll just write something bad in order to get to something good. Provided your writer has a good idea of the scope of the project and the writing budget they can use some freedom to best deploy their skill set. You don't need to sit on them to make sure you hit your production deadlines, you just have to be clear with them what you need and when - and a good writer will deliver it.

Header image is from Hitbox Team's narrative design write up, which is itself a wonderful primer for how to make those big, story-driven games we talked about earlier.

You can read more about how to work with writers, including recommended rates, at the Writers' Guild of Great Britain.


  1. Any questions, additional ideas or objections? Let's hear 'em.

  2. So what would happen if the story created game play that wasn't fun? Or vice versa? Which way would be the best way to fix that? Change the story first, or change the game play?

  3. That's a very broad way to look at the problem. I wouldn't say it was a matter of story or design giving in first.

    If you have conflicts at the very top level - let's say you want to tell a love story, but the gameplay is about shooting people - then I think you should go back to the drawing board and decide which game you want to make.

    My comments are aimed at more particular decisions.

    In some cases, it will best best for the final experience - and most economical - if story gives way. Say for gameplay reasons you need the player to lose their communications device - we can write that into the story easily enough.

    In other cases it will be best if gameplay stays flexible. Does this door really need to be here? Do these levels have to play in this order? Does it really make sense to have so many empty drawers?

    This idea that we have to choose between gameplay and story I think can be misleading. We're all working towards a holistic experience. It's not a matter of prioritizing gameplay over story or the other way around - it's about leaving yourself the leeway to implement creative solutions on the fly.