The documentation of game writing tends to fall into one of two buckets.
The transition from pre-production dreams to full development focus is tough on… well, just about everything, and certainly all documentation and planning. There are, however, some specific approaches that can make a big difference for the narrative design of your game, especially.
Almost any game writer or narrative design you talk to will implore you to bring them on in pre-production as early as possible. I’m not here to undermine the cause, but the “Bucket Two” scenario described above makes it clear that early involvement alone may not be enough to ensure a strong narrative throughline in your final product. To accomplish that, you want to make sure that the story work you do in pre-production successfully translates into vision and guiding parameters for the actual writing done in full production.
Which is certainly not to say that you need to lock in your story early and stick to it, no matter what. We all know that game development is iterative and the story can change just as much as every other element of a game as you “find the fun,” noodle, pivot, refactor, and generally get your project pointed in the right direction. Early narrative development should reflect and generally match all of that. The important part is to exit pre-production clutching the few really important things you need to see you through. And not a cluttered pile of aspirations that will soon be replaced by the actual work of writing words into the game.
Broadly speaking, in addition to the writing itself, you will want two sets of supporting documents, folders, or wiki sections: a narrative bible and an active style guide. These two documents have different uses, slightly different audiences, and different schedules for creation and maintenance.
The Narrative Bible
This document should be due at the conclusion of pre-production, and its primary purpose is to eloquently communicate to the entire team (and stakeholders, and investors, etc.) what the game is and what it’s about. Hand in hand with concept art and art bibles, demo prototypes, and other early work, this is the stuff of design pillars and broad brushstrokes.
A narrative bible does not need to be biblical in length. It does not need to have every plot point of the story worked out. It does not need massive character profiles or 10,000 years of invented history… unless those are somehow absolutely vital to beginning development work.
Far better to answer these questions boldly and confidently:
The pitch document for the Duffer brothers’ acclaimed Stranger Things series recently surfaced, and it provides a remarkable example of what a narrative bible should look like. It answers the bulleted questions above dead-on, and contains almost no plot whatsoever. More wondrous still, very little changed between the initial pitch and the finished show. The biggest change? Arguably, the season-by-season plot!
In addition to those core questions above, the narrative bible should include samples of anything that fills in a complete picture of the game. Storyboards of a sample intro video or key origin story to hook the audience are great. As are maps, dialogue, concept and reference art, key lists of facts and details… all kept mercifully short!
Really, seriously: the narrative bible should be as short as it possibly can be while still achieving its goals. It should feel and read more like an interesting coffee table book than an encyclopedia. This is vitally important because you want and need your entire team to pick it up and flip back through it regularly.
So in summary:
Narrative Bible
Purpose: define what the game is (narratively) about and what the major story elements are
Audience: outward facing, entire team
Deliverable: end of pre-pro
Maintenance: infrequent, only with major pivots and story changes
Style Guide
If the narrative bible is an outward facing document made in pre-production, the style guide is a full production document for, of, and by the writer or writers. You might have just one writer on your team. They might be a rockstar. You still want to have a style guide.
For one thing, a style guide gives QA explicit rules to check all writing against. (Typos can happen to anyone!) And then, of course, you never know when you might lose that rockstar writer, or decide they need extra hands to meet deadlines near the end of development, or when other team members are add text of their own in odd and unmonitored corners of the project.
So let’s be clear: a style guide is a succinct, workaday reference doc. A coffee table book it is not. It’s primary job is to be full of useful and easily searchable lists.
Such as:
In addition to these lists, you will probably want some short notes on overall writing style and tone, with some (short!) key examples. For game characters, notes on their likes/dislikes and how they talk is also important, especially favorite phrases and things they don’t say or do. This is especially key for licensed IP, where these notes may come directly from the licensor!
Your style guide should be started early in full development and updated regularly as new cases come up.
Summary:
Style Guide
Purpose: quick, searchable reference and rules for all the writing in the game
Audience: inward, writers and QA
Deliverable: entire full development cycle
Maintenance: frequently, built up over the course of writing and editing work
Stacking the Buckets
That’s great and all, but how do we help ensure that the narrative bible doesn’t get ignored? And how do you get from there to a working style guide? First, to keep hammering the nail: your document should be as short and focused as it can be to achieve its goals. And pretty. And accessible. (As the old quote goes: I would have written you a shorter letter, but I didn’t have the time.) In fact, it is a good idea near the end of pre-pro (or, in the live operations cycle, as a sprint review) to hold a group “Story Time” meeting, present the bible page by page, and discuss and take questions.
Then, compile the first draft of your style guide from the narrative bible. This should be your principle or lead writer’s first task, and it should be their or some other writer’s responsibility to keep the guide up to date. Significant changes should be broadcast. QA should have immediate access. Leads and stakeholders should review major revisions. Questions from other parties about text and style should be referred directly to the style guide.
All laid out, the narrative work for your project now thrives on the following documentation:
