作者：Alexander Freed

我们曾讨论过一些高级别的理论，也曾涉及过业务内容。如果你正致力于为你的团队游戏创造一份完整的故事文件，并且你并不清楚该如何做，那么以下便是一些对你有帮助的建议。

没有人会喜欢编写情节总结。如果你拥有一个能够支持一款游戏的故事（即为好几个小时的互动体验量身打造的故事），那么将其压缩在几页纸上会是一项非常艰难的工作。除此之外，你必须确保情节总结足够清楚，逻辑上不会分崩离析（所以不要莫名其妙地让主角突然从A跳到B），并且与电子游戏世界中的大多数情节总结一样，你必须让美术史，影片设计师，关卡设计师等人能够从中找到疑问的答案。

尽管很困难，但是组织总结却是大多数游戏作家在某些时候必须完成的任务。所以让我们来谈谈一些需要考虑的关键点。

什么是情节总结，它又是面向谁而写的？

情节总结（或者说是大纲，故事大纲等等）是关于游戏故事，主要事件和角色行动的叙述。这并不是一份技术文件，尽管它可能会（或不一定）将故事分成一些明确的游戏玩法元素，资产要求等等，并且它所侧重的是关于讲述一个故事。它也不是独立存在的—-一款游戏的个体部分可能需要一些更详细的情节总结（如“章节”，位置，开放世界情节线等等）；“关键路径”文件将详细描述游戏进程所需要的每个游戏玩法步骤；而这也将作为某些人（也就是我们所提到的第二个问题）所需要的一种高级的参考文件。

较短的情节总结（1至2页）能够帮助你面向公司高管，潜在的授权者等不会直接参与内容创造，并在真正投钱之前想了解自己所面向的是什么内容的外部人员传达游戏理念。如果你要创造的是这种类型的情节总结，你便能够找到许多有关小说或电影的故事大纲资料。如果你更加注重通过感觉进行“销售”，那么这种类型的情节总结便非常适合你。

而如果你的读者只有你自己，即你需要为自己的计划编写大纲，那么这类型的总结便没有用。

如果你是面向一支设计团队编写文件，并且该设计团队是基于描述了游戏玩法每个步骤，还会列出每场战斗，每个人物道具等内容的关键路径文件，你可能就要将其与你自己的情节总结完全区分开来。你很有可能深陷于很少有人能够理解的技术细节中。虽然关键路径文件也很有帮助，但它却不适合作为故事理解内容。

相反地，我们今天的关注点将是面向开发团队成员的情节总结，即基于多种内容（游戏邦注：包括设计，图像，工程，音频等等）并且是征求反馈，获取高级“支持”并帮助团队真正理解故事所有关键部分的方式。最理想的情况是，你能够在开发早期阶段便写好这样的总结，但事实上它总是出现在非故事游戏开发的后期阶段。

对于并不了解叙述特定内容的团队成员（游戏邦注：如工具工程师或QA项目经理）来说，情节总结就像是帮助传达整体项目前景的某一面的参考性文件；它能够帮助人们更好地理解他们所创造的内容，并且一份清楚且吸引人的情节文件总是能让读者更加兴奋。

而对于那些与故事内容具有直接联系的团队成员来说，总结性文件便更加重要。这是抵御不可预期的问题和误解的第一道防线。一份精心编写的情节总结能够帮助系统设计师识别潜在问题（如“玩家一开始不能使用法力，这是一种可学习的技能，并且其影响范围可能会被削减”），能够帮助美术师把握完善游戏的机会（“为什么当环境团队创造了完美的内部装饰时所有场所都会变成被白雪覆盖的森林？”）等等。它允许来自不同部门的人能够做出最纯粹的故事评价，能够传达所有背景信息，并确保所有逻辑都是合理的。这同时也是项目创意总监，编剧或者其他扮演着作家角色且拥有项目故事决定权的人对于故事的评判。

这样的总结也可以瞄准编写团队，并传达多位作家最终所确定的完整故事内容。再一次地，这样的总结也能够让团队提供评价并识别一些潜在问题，但一旦一名作家因为太过了解故事的完整背景而离开时，另一名作家就必须接手他的工作。如果一支写作团队所使用的情节总结不够清楚，那么不同作家的作品之间便会出现不可避免的矛盾。

保持内容具有吸引力

一旦你清楚自己的目标用户是谁，你便会迎来一些需要越过的全新障碍。你的情节总结必须具有吸引，且应该具有可读性。你的目标便是确保这些内容足够有趣，足够感人且具有吸引力。

但这并不意味着你可以使用一些故事中并未呈现的内容去装饰它。你必须像面向公众创造任何内容那样重视它。尽管你的对象是公司内部成员。你是在讲述一个故事而非背诵什么内容。

玩家的立场

你应该站在玩家的立场去编写情节总结（不一定要是玩家角色，因为他们的立场可能会有所不同）。你应该避免传达玩家未同时在游戏中接收到的解释内容或背景信息（例如“当玩家到达Lotus Eaters时，他便莫名其妙地被丢进了监狱里。Lotus Eaters会根据玩家购买的莲花去划定其社会阶层。”），并且除非玩家主动要求，否则不要传达角色细节或背景信息等内容。

player(from xinmin)

例子：玩家遇到了军阀，并且发现一个有着被击落的直升机以及联合国医疗用品的场所。军阀警告玩家游击队员有可能会来收拾这些残骸，但是玩家却不清楚军阀说的到底是不是真的。

为什么要如此安排情节总结呢？这会让写作变得更加困难，但事实上总结不只是关于讲述一个故事，它还需要传达真正的游戏故事体验。如果你不能从玩家的角度去传达内容，你便等同于在讲述一个完全不同的故事，并且不存在任何方式能够将游戏叙述整合在一起。如此其他成员也将不知道该为游戏创造什么内容。

站在玩家的立场去编写总结也能够揭示一些具有问题的地方，如玩家变得被动了。如果你不能编写一个带有情感和主题深度的“玩家执行X事件”这样的事件总结，那么你就要想想你的主角是否真的是主角了。

如果你必须在情节总结中添加“补充”信息，如简短的背景描述或简短的主角列表，并确保它们具有明确的标签且区分于主要叙述内容。即使你添加了这样的补充内容，你也必须确保大多数必要元素也会出现在主要的总结内容中。否则你的读者便会困惑玩家何时以及如何获得这些“必要”信息。

确保情节总结本身是可运行的

将你的情节总结作为故事的一个最小框架。你可能会为了之后创造更详细的最终脚本而留下一些细微差别或者可调整的空间，但你的情节总结本身也必须作为可运行的故事存在着。

如果你因为某些原因突然消失了，那么其他人也可以直接拾起这一任务并编写你的情节总结中所描述的故事，且无需再去应对那些基本的设置和逻辑问题。如果你的情节总结不能作为一个独立故事，它便不是一种规划工具，这时候你便会以“它在最终版本中便会具有意义”这样的想法去解释任何问题，并且一些明显的问题也将变成分心元素，即作家将只是在自己的脑子里解决这样的问题。

当然了，这样的目标过于理想化，你的故事往往不可能像在总结中那样发展。但这却是一个值得你去追随的重要理想。

牢记游戏玩法限制

当你在编写情节总结时，你必须确保你的游戏设计中已经完成了一些基本内容。就像在我们的例子中，你必须拥有一些详细的机制和限制条件。我们将讨论如何处理游戏玩法中一些较模糊的内容，但你也必须确保不逾越种种限制条件。

例子：你是否是面向一款开放世界游戏编写总结内容？如果是的话你必须确保你的情节不会基于非线性方式进行划分。游戏设计是否要求玩家在每个任务后重新变成NPC人物分配者或回到基地中？然后你需要确保发生这种情况是否存在符合故事的理由。你的设计是否是在任务中间不呈现过场动画？然后你需要确保任何过场动画会出现在游戏一开始或最后。

每一款游戏都有自己的限制条件。有些游戏会直接表述出故事，也有些游戏会设置刺激内容和障碍物。不管怎样你都不该忽视这些限制条件，或假设它们将在之后的细节层次中发生改变。再一次地，情节总结是帮助你纠正这些问题的机会；如果你选择忽视它们，你便会失去这样的机会。

暗示游戏玩法，但是不要依赖于它

对于游戏机制的理解是设计游戏故事的关键。第一人称射击游戏需要与点击指向型冒险游戏截然不同的故事。最理想的情况是，游戏机制细节能够有效地匹配故事内容—-如果潜行是上面提到的射击游戏中的一种选择，那么一些叙述内容便应该鼓励这种潜行（或者至少应该允许潜行）。

但是机制似乎会在游戏开发过程中发生彻底的改变。所以情节总结最好能够呈现出游戏风格并揭示一个终极目标，且不依赖于任何具体方法。举个例子来说吧，在一款RPG中宣称“玩家使用全新获得的能量在某个地方冻结一大群敌人”或“玩家必须在一个跳跃谜题中爬到高山的最顶峰”都是很危险的，因为这两种表达都需要特定且调整好的游戏机制发挥作用。对此我们可以做出适当的调整，即变成“玩家可以在战斗中展示自己的全新能量”以及“为了到达山峰玩家需要探索一个全新区域”。你可以在总结中提供一些暗示，但是你也必须确保那些必要内容以及灵感内容的表达足够清楚。确保你至少暗示了一种游戏风格—-就像我必须清楚爬山是否等同于停机时间，或者这里充斥着激烈的谋杀情节。

你还必须牢记其他开发团队成员有可能比你更清楚怎样的机制更有趣且更有用，所以千万不要去挑战系统专家的工作。

在很多情况下，情节总结都是围绕着已决定好且非常详细的游戏机制进行编写。甚至在这些情况下，你最好不要编写能够适应机制变化的情节总结；除非游戏已经完成，否则在开发和测试阶段还会出现许多改变的机会，你肯定也不希望因为潜行系统并不有趣而影响到故事的发展。所以你最好能够坚持计划和目标，并做好改变的准备。

隐含预算

与传达游戏玩法一样，你也必须确保能够在情节总结中传达预算。当你们需要使用一些昂贵的内容去推动故事的发展时，请确保在情节总结中清楚地记录这些“内容”。不要掩饰任何难以执行的场景，美术资产等，并确保任何阅读该总结的人都了解你的期待，如此其他团队成员便能够更轻松地领悟其中的含义。（再一次地，我发现Word’s Comments非常适合突出我所关心的特殊条款，如我正在描述这样的一个场景，并且需要围观的人群，所以我便会添加评论功能去询问别人这是否会为美术，动画等增添难度，并添加一些该场景不可行时的替代方法。）

也就是说如果故事并不需要“一些昂贵的内容”，如果场景可以基于已有的资源以各种不同的方式出现，你便不需要讲清楚所有细节内容了。最理想的情况是，大多数故事都拥有各种灵活性。但是过度模糊的请求也会让读者感到困惑，人们也有可能会想象一些你并未要求的要求，所以再一次地，评论也将帮助你清楚地进行表达。

例子：一群围观者等待着玩家登上山峰。（对此我们还可以想办法应对，但因为这是一个包含情感的重要场景，所以我愿意为此花些钱。）

基于不同游戏类型以及你所拥有的预算，你需要准确描述的费用类型也是不同的。像大型或特殊关卡，原画，特殊的游戏机制等等内容便需要更高的预算。

不要过度依赖

当然了，你也不能过度依赖于情节总结。这甚至不算什么游戏内容。这只是一份蓝图，一个理念，并在真正执行前需要得到许多人的测试。

但这也不意味着你不能为自己的总结内容感到自豪，只是你不该因此而过于自我。你要能够接受批评。重塑故事去创造更出色的游戏。你知道你的故事比任何其他人都优秀，但你的观点却并不能代表整个项目。

你应该反复校订情节总结，完成它，然后将其置于一盘并开始编写真正的游戏故事。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

Yes, You Have To Write a Game Plot Summary; and Yes, It Has To Be Good

by Alexander Freed

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 large 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.（source：Gamasutra）