Some days we discuss high-level theory. Some days we get our hands dirty with realities of the business. If you’re working on an overall story document for your team’s game and you’re not sure how to approach it, here’s some advice.
No one likes writing plot summaries. If you have a story that can support a game–a story designed for a multi-hour, interactive experience–of course it’ll be painful to reduce it to a handful of pages. On top of that, a plot summary needs to be engaging to read, be clear and thorough enough not to logically fall apart on examination (so no handwaving how protagonists get from Point A to Point B), and–for most plot summaries in the video game world–contain enough meat to allow artists, cinematic designers, level designers, and so forth to intelligently respond with their own concerns and plans.
Despite the difficulties, putting a summary together is a task most game writers will need to take on at some point, so you might as well do the job properly. Let’s talk about key points to consider.
What is a Plot Summary, and Who is it For?
A plot summary (or a synopsis, or a narrative outline–call it what you will) is a prose recounting of a game’s story, narrating the major events and character beats. It is not a technical document; while it may (or may not) break down the story into clear gameplay elements, suggest asset requirements, and so forth, its emphasis is on telling a story. It does not stand alone–more detailed plot summaries may be necessary for individual subsections of a game (“chapters,” locations, open world plot threads, etc.); “critical path” documents may elaborate on every gameplay step required to progress; and so forth–but it serves as a high-level reference document for… well, that’s the next part of the question? Who is it for?
A short (1-2 page) plot summary may be needed to help sell the concept of a game to company executives, potential licensors, etc–outsiders not directly involved in content creation, who may care about the details later but who initially simply want some idea of what they’re getting into before giving a project their blessing and / or money. If that’s the sort of plot summary you’re worried about, there are plenty of good resources out there on writing a story synopsis for a novel or a film. That style of summary is probably what you want–you’re prioritizing a “sell” by feel and overall narrative over particulars or interactivity. This article won’t help you.
If your audience is just you–if you’re writing an outline for your own planning purposes, say–then once again, this article won’t help.
If you’re attempting to write a document complete enough for a design team to actually build a game from–a critical path document, as mentioned above, delineating every step of gameplay, calling out every combat, listing every quest item, and so forth–you may want to separate it from your plot summary entirely. Most likely, it’s going to get so bogged down in technical detail that very few people will be able to sit down, read it, and actually understand the high-level story of the game. A critical path doc has a place, but it’s not for story comprehension.
Rather, our focus today is on a plot summary intended for development team members in multiple disciplines (design, art, engineering, audio, etc.) as a way to solicit feedback, procure high-level “buy-in,” and allow a team to have a clear understanding of all key parts of the narrative. Ideally, such a summary should be written very early in development; in reality, it may come relatively late in non-story-focused games.
For team members without a direct stake in the particulars of the narrative (e.g., a tools engineer or a QA project manager), a plot summary serves as a useful reference doc to help communicate one aspect of the overall project vision; it’s always good for people to understand and be enthusiastic about what they’re creating, and a clear, concise, engaging plot summary document will help generate excitement.
For team members with a strong direct stake in the narrative particulars, however, a summary doc is even more important. It serves as the first line of defense against unexpected problems and misunderstandings. A well-written plot summary allows a system designer to spot potential issues (“the Player can’t start with magic powers; that’s a learnable skill, and it might be cut for scope anyway”), an artist to note opportunities for improvement (“why is every location a snow-covered forest when our environment team does brilliant interiors?”), and so forth. It allows for pure story critique from all parties as well, making sure that all background information is conveyed, that all logic is sound, etc. It may very well be the document that is the focus of story critique for a project creative director, editor, or whoever may serve as a writer’s check and as an owner of the project narrative.
Such a summary may also be aimed at a writing team, conveying the overall events of a story that multiple writers end up detailing. Once again, the summary allows the team to offer critique and spot potential issues, but it also lets one writer pick up work where another leaves off with a strong understanding of the story’s full context. If a plot summary used by a full writing team lacks clarity, there will be inevitable conflicts between different writers’ work.
Keep it Engaging
Once you know your intended audience, you’ve got a host of new hurdles to leap. A plot summary must be engaging. It must be readable. Your goal is to make it as enjoyable, emotional, and intriguing as the plot it’s summarizing. (It probably won’t be, but that’s the goal.)
This doesn’t mean embellish in ways that don’t ring true to the story envisioned. It does mean treat it as seriously as you would anything produced for the public, even though your audience is strictly in-house. You’re telling a story, not simply rattling off a series of events.
Player-focused, Player Point of View
Write the body your plot summary from the point of view of the Player (though not necessarily the Player Character, since their viewpoints may differ). Avoid delivering expository background or setting information that the Player isn’t also receiving in-game at the same point (“The Player arrives in the land of the Lotus Eaters where she is immediately thrown into prison with little explanation. The Lotus Eaters have a highly stratified society based on lotuses consumed…”), and don’t reveal character details or contextualizing information (“meanwhile, the Player Character’s nemesis schemes in his castle”) unless the Player is actually privy to that knowledge.
Example: The Player confronts the warlord and, either diplomatically or through threats and blackmail, learns the location of the downed helicopter and the UN medical supplies. The warlord warns the Player that the guerillas have likely already picked the wreckage clean, but it’s unclear whether he’s telling the truth.
Why handle the plot summary this way? It certainly makes writing one more difficult, but the summary isn’t just meant to tell a story–it’s meant to represent the actual game narrative experience. If you’re not telling it from the Player’s point of view, you’re telling a different story altogether and there’s no way to be sure whether the game’s narrative will hold together. There’s no way for others to judge what needs to be built for the game.
Writing the summary from a Player point of view also helps reveal potentially weak areas where the Player is denied agency, where the Player Character becomes passive, and so on. If you can’t write the summary as a series of “the Player does X” events–with, of course, emotional and thematic depth to it all–then consider whether your protagonist is sufficiently protag-ing.
If you must have “supplementary” information included in the plot summary–e.g., a brief setting description or a short list of major characters–make sure it’s clearly labeled and separated out from the main narrative. Even if you include such supplementals, make sure the most necessary elements are repeated somewhere in the main synopsis. Otherwise, your readers will be wondering when and how the Player actually learns this “necessary” information (and whether you know the answer yourself).
Make it Work on its Own Terms
Consider your plot summary a minimal acceptable framework for the story to function. You may leave out certain nuances and complexities and setups and twists that you intend for the vastly more detailed final script (or even for a more detailed version of the plot summary), but your plot summary must work as a story in its own right.
If you vanish, someone else should be able to step in and write the story described by your plot summary without wrestling with basic issues of setup and logic. If your plot summary doesn’t hold together as a standalone story, it becomes impossible to critique and use as a planning tool–genuine problems will be excused by the notion that “it’ll make sense in the final draft,” and apparent problems will become distractions if they’ve already been solved in the writer’s head without making it to the page.
Of course this goal is an ideal–your story won’t work as well in plot summary form. But it’s an important ideal to strive for.
Keep Gameplay Restrictions in Mind
By the time you’re writing a plot summary, at least some fundamentals of your game’s design have likely been established. In many cases, you’ll have a very detailed array of mechanics and restrictions to work with. We’ll talk about how to handle more nebulous aspects of gameplay in a moment, but be very aware of the constraints you must work within.
For example: Are you writing for an open world game? If so, make sure your plot doesn’t fall apart on a non-linear path. Does the design require that the Player return to an NPC mission-giver or home base after every quest? Then make sure there’s an in-story reason for this to happen. Does your design not allow cutscenes in the middle of missions? Then make sure anything cinematic happens at the start or the end.
Every game has its constraints. Some of them will fundamentally dictate the manner of story you tell, while others will be irritants and speed bumps. But you should never pretend your restrictions don’t exist, assuming that they’ll change or can be fixed on the next level of detail. The plot summary is, once again, a chance to catch and correct these sorts of problems; if you’re ignoring them, you lose that opportunity.
Imply Gameplay, But Don’t Depend On It
An understanding of a game’s mechanics is, of course, pivotal to designing a story for said game. A first-person shooter requires a vastly different story than a point-and-click adventure game. And ideally, the particulars of a game’s mechanics should fit naturally into a story as well–if stealth is an option in the aforementioned shooter, some sections of the narrative should encourage (or at least naturally allow) stealth.
But mechanics tend to change drastically over the course of a game’s development. Ideally, a plot summary should imply the style of gameplay and reveal an ultimate goal without depending on any exact methods. For example, declaring “the Player uses his newly acquired powers to freeze a swarm of enemies in place” or “the Player must climb to the top of a high mountain in a jumping puzzle” in an RPG would be dangerous–both statements require certain sets of properly tuned game mechanics to work. Slightly better alternatives might be “the Player fights in a combat allowing her to showcase her new powers” and simply “the Player is required to explore the peaceful environment in order to reach the top of the mountain.” It’s fine to make suggestions (I find Microsoft Word’s Comments feature useful for separating gameplay suggestions from the core of the summary), but make sure what’s necessary and what’s mere inspiration is clear. And make sure you are at least implying a style of gameplay–I need to know if that walk up the mountain is meant to be a brief, serene bit of downtime, a showcase for puzzles, or a combat-heavy murder spree.
Keep in mind also that other development team members are likely to have a far better understanding of what mechanics are enjoyable and functioning well than you are–don’t try to do the job of the systems experts.
In many cases, a plot summary may be written around predetermined, highly specific game mechanics. Even in these situations, you’ll be better off with a plot summary that can adapt to mechanical changes; unless the game is already built, there’s every chance that specifics will evolve during development and playtesting, and you don’t want your narrative to fall apart just because it turns out your stealth system wasn’t fun after all. Hew to plans and good intentions, but be prepared for things to change.
Imply Budget
In the same vein as implying gameplay, make sure you’re implying budget as well. When something expensive is required for the narrative to work, make sure that “something” is clear in the plot summary. Don’t gloss over mentions of difficult-to-implement scenes, art assets, and so forth–make sure your expectations are obvious to anyone reading, so they can be easily assessed by the rest of the team. (Again, I find Word’s Comments useful for highlighting particular items that I know may be of concern. e.g., if I’m describing a scene in which a crowd of onlookers is required, I’ll add a comment asking whether this will pose difficulty for art, animation, cinematics, etc., and suggest some alternate approaches if the scene isn’t viable as described.)
That said, if the “something expensive” isn’t required by the narrative–if a scene can be made to play out in various ways depending on the resources available–you needn’t be as concerned with spelling out all the details. Ideally, most of the narrative will have plenty of flexibility. Yet confusion can emerge from overly vague requests, as well–people may imagine requirements you didn’t intend–so again, comments can help clarify.
Example: A crowd of onlookers waits for the Player at the top of the mountain. [We can make do with only a handful if required, but this is an emotional, important scene, so I’d love to spend some money on this one.]
Exactly what sort of expenses require explicit mention vary drastically depending on the type of game and the budget you’re working with. Large or unusual levels, original art assets, unique game mechanics, and so forth tend to be big ones–see Learning to Budget at a Glance for more.
Don’t Get Attached
And of course, don’t get wedded to a plot summary. It’s not even game content yet. It’s a blueprint, an idea, that needs to be tested by many other people before it can be deemed worthy of implementation.
That doesn’t mean you can’t take pride in a summary–but leave your ego at home. Accept critique. Reshape the narrative to help make a better game. You know your story better than anyone else, but your vision doesn’t encompass the project as a whole and you’ve got blind spots on the narrative front, too.
Revise. Get signoff. Then put the plot summary aside and start writing the real deal.