* Noah Falstein的《A Point of View》。我们将故事叙述视角划分为“第一人称”或“第三人称”——我们也以此谈论视频游戏视角。因此我们很容易会认为二者存在关联性，但其实并非如此。文章清楚阐述二者存在的差异。
* Chris Bateman的《Diversity in Game Narrative》。这主要概述游戏存在的各种故事结构。
* 《Challenges for Game Designers》第13章。
用Bateman的话说，这是自行分解的分支故事，允许玩家做决策，最终将全部内容压缩成若干命令事件。例如，在《Silent Hill》中，玩家享有若干选择， 或发展故事，或沿途呈现某些额外故事元素，这些都会影响结局。但无论玩家有没有进行额外操作，有些事件他们无法回避。
假设存在第二人称摄像头视角，它主要指玩家从正面观察主角。毋庸置疑，这会令多数游戏陷入混乱局面。最贴近的例子就是晦涩的掌机游戏《Robot Alchemic Drive》，其中玩家控制人物角色（第三人称），而角色反过来会通过遥控装置控制庞大机器人（第二人称）。从此意义上看，机器人就是主角，游戏就是采用第二人称摄像头视角。
原型 & 固定模式
Level 10: Nonlinear Storytelling
Last time, we learned some basic linear storytelling principles, as told to us by people that worked with books, plays, and movies. And this is fine and good for games that have a linear story. Many video games work this way, where the story is essentially told as a movie broken up into small parts, and the player has to complete each section of the game to see the next bit of movie. I do not mean this in any kind of derogative way; many popular games work like this, and many players find these games quite compelling. Even personally, I have had times when I would be messing about in the subscreens optimizing my adventuring party, only to have my wife call from across the room: “stop doing that and go fight the next boss so you can advance the plot, already!”
However, not all games are like this. As we’ve seen, player decisions are the core of what makes a game. Some games have a strong narrative intertwined with gameplay. For these games, it would make sense for player decisions to not only affect the mechanical outcome of the game, but to affect the narrative as well.
For some game designers, a true “interactive story” is something of the Holy Grail of games. In reality, we often fall short of giving the player the feeling that they are actually the starring role in a compelling story of their own creation. How have we told interactive stories in the past, and how can we make better ones in the future? It’s largely an unsolved problem, but we can at least cover the basics of what is already known, and that is our focus today.
Note that most board games do not have strong embedded narrative, so this entire discussion is mostly relevant to video game narrative, as well as tabletop RPGs. However, some modern board games are in fact attempting to combine the tabletop board game experience with that of the RPG, including story elements that the players must interact with as part of the gameplay.
I will be at SIGGRAPH all next week. While I will make every effort to post on time, I may not be able to respond quickly to email and I may be slow in validating blog comments or new forum accounts, so please be patient. Naturally, if you are attending there yourself, feel free to say hello in person – I’ll be speaking on Monday morning about the results of the Global Game Jam.
Read the following:
* A Point of View, by Noah Falstein. We talk of the point of view of a story as “first person” or “third person” – and we also talk of the point of view of a video game in similar terms (First Person shooter, Third Person stealth, etc.). It is easy to assume that the two are equivalent, but they are not. This article makes the differences clear.
* Diversity in Game Narrative, by Chris Bateman. This is a brief overview of the different kinds of story structures encountered in games.
* Challenges for Game Designers, Chapter 13 (Designing a Game to Tell a Story). This short chapter covers today’s topic and can also serve as a review of some topics from last time.
Kinds of Stories
We can roughly classify different stories by their overall structure. The structure is determined by what kinds of choices are available to the player, how open or constrained those choices are, and what effect those choices have on both the ongoing story and the final ending. Each structure has its advantages and disadvantages, which we will discuss below.
Linear stories are the traditional narrative, with some gameplay elements thrown in that do not affect the story. In this case, the story and gameplay must be separate entities, because the story has no choices and the gameplay must include decision-making of some kind (else it is just a story and not a game). They can be thematically linked, and the story may influence gameplay (perhaps when a certain pre-scripted story element happens, it causes a new gameplay effect to come into play), but the gameplay cannot influence the story because there is only one story.
Linear stories have one major advantage over all other story structures: it is easy to apply traditional storytelling techniques, which have been developed over thousands of years. Such a story can have a powerful emotional impact – witness that we still talk of Floyd’s death in Planetfall and Aerith’s death in Final Fantasy 7 as key moments in the history of game narrative… even though neither events was under player control.
Linear stories have the obvious disadvantage that, due to a lack of decisions, they are not very game-like. As stated above, there is a natural barrier between linear stories and game mechanics, which limits the effect the story can have.
The first and most obvious thing to do to a linear story, if we want to add decisions, is to add choice points at various places. When the player reaches a certain point, they decide what to do, and then the story goes down one of several continuing paths until another choice point is reached. An example is the old-school Phantasy Star III for Sega Genesis; twice in the game, the main character is given a choice of which of two girls to marry (and then the story continues to the next generation of characters), leading to a total of four branches, each with its own story and its own ending.
Branching stories have the advantage of being interactive. If you include a sufficiently large number of choices and your choices cover all of the things that a player would want to do, the game can respond believably to any number of player decisions. At first, this would appear to be the ultimate solution to game narrative since it can handle just about anything.
However, there is one major drawback of using a branching story: it is expensive! With only two choices (which is not very many), the story writers of Phantasy Star III still needed to write four stories. A third choice would have had them writing eight stories, and including a mere ten choices would require writing 1024 stories! Consider the number of decisions you make as a player in a typical strategy game, and you’ll see that the amount of work to write a branching story can quickly explode into something unmanageable.
To make things worse, note that a player that goes through the game once will never even see the vast majority of content. It requires multiple replays just to see every path through the story… and even then, the player must decide which is the “real” story and which are the alternate timelines that didn’t actually happen. (If the developers ever make a sequel to the game, they must deal with this problem as well.)
This is Bateman’s word for a branching story that collapses in on itself, allowing the player to make choices but then collapsing all of them eventually into several mandatory events. In Silent Hill, for example, there are several choices the player can make that may advance the story or reveal some additional story elements along the way, and these will influence the ending. However, there are certain events that the player is forced to encounter no matter what else they have or haven’t done.
Parallel paths solve the problem of branching narrative by keeping the advantage of player decisions while still keeping the total amount of story manageable. So, at first, this would appear to be the ultimate story structure.
As you might guess, there is still a problem: since the player is forced into certain events, the entire plot arc is now essentially linear again. We have lost the player’s feeling that they are directing the story, because no matter what they do there will be certain parts of the story that are the same no matter what.
One potential solution is to have the player decisions alter the game’s ending. The player may still encounter the same plot arc, but the final outcome is determined by the choices the player made. Unfortunately, that means the relationship between cause and effect can be easily lost – the player’s decisions are (by definition) not seen until the very end, and it is often unclear what the player did to cause a certain ending.
And, we still have the problem that the player must replay through the entire game multiple times just to see all the endings.
This is Bateman’s term to describe stories that are divided into small pieces, perhaps with several plot arcs going on at once that may or may not intersect. The player then chooses which paths to follow and in what order. One example of this is World of Warcraft, where the player can accept any of several quests to advance different elements of the story. Another example are the Elder Scrolls series of games (like Morrowind and Oblivion), where the player may follow certain storylines based on how they want to advance their character, and the player may find other quests or subplots that they choose to pursue (or not) along the way, and these subplots may or may not have their own effects on the main plot line.
The advantage of a threaded narrative is that it is extremely expressive. You can have multiple storylines happening concurrently, as with nonlinear films like Pulp Fiction or Love, Actually (except, unlike those movies, have the plot lines advance according to player intent).
Also, the story may have multiple beginnings and middles and endings, but the player has access to all of them and can advance any combination of them in any order, so we have finally solved the problem of forced replays. The player can see everything there is to see with a single play-through, if they are thorough enough.
As you might guess, there is still a problem here. First, since some events may affect others, testing out all possible paths through the story can get even more complicated than with a branching narrative. (For programming geeks, a branching story with two choices per choice point is O(N^2), while a threaded narrative is potentially O(N!). Yes, factorial.)
Writing a threaded narrative is hard, because events can happen in any order, leading to the potential for the player to do things in an order that doesn’t make sense (for example, perhaps they are given a quest to assassinate a rival leader in the middle of a war, before the war actually breaks out, or after the war is concluded). The story writer must be careful to allow access to certain story events only when it would make sense to do so. Keeping track of all the variables that determine when a story event is or isn’t active can get very complicated very quickly.
Lastly, a threaded narrative runs the risk of confusing the player, if there are too many concurrent plots happening at a single time and the player does not immediately see the relationships between them. This is also a danger with books and movies that try to tell several stories at once.
Dynamic Object-Oriented Narrative
This last structure is Bateman’s term that, as far as I can tell, he invented to describe the game Fa?ade (which you should absolutely download and play if you have not yet seen it). The idea is that there are several mini-stories, each with potentially several entry points and exit points. A single mini-story’s exit point may lead to a final ending, or to another mini-story. The mini-stories may be thought of as “chapters” in a book or “acts” in a play (except that you may not “read” all of the chapters or may read them in a different order, depending on the choices you make and how you exit each chapter).
This kind of story has the advantages of parallel paths, but without a linear story arc. Each mini-story has its own choices, and the overall collection of mini-stories itself acts like a larger branching or parallel path story. Each individual mini-story is self-contained, which reduces the required time to write the complete story.
This kind of story has two disadvantages. The first is that there’s still the forced-replay problem: a player must play many times to see all of the story paths (which is perhaps why Fa?ade needs to last about ten or twenty minutes, and not ten or twenty hours). It is also a highly experimental structure, so we do not yet have enough games to really analyze what does and doesn’t work in this form. Fa?ade itself took a couple of guys with PhDs in Computer Science to develop, so this is not the kind of story structure that is easily accessible to a traditional story writer.
Points of View
The camera in video games is generally either first-person or third-person.
A first-person view means the camera is, essentially, glued to the main character’s forehead looking forward. The player sees what the character sees. This can lead to a greater sense of connection with the main character, because the player is inside the character’s head, so to speak. The disadvantage is that this is not truly a first-person view, because a typical human’s peripheral vision is wider than the screen (and a typical human can turn their head faster than a typical first-person video game camera), which can break immersion at times for players who are not used to the limitations.
In a third-person camera view, the player is instead looking at the main character, usually from a behind-the-shoulder perspective so that you usually see the character’s backside. This gives a wider view of the area and is more realistic in terms of giving the player the visual information that the character would have. Of course, by looking at the main character all the time, it brings a sense of otherness – you can’t look at your own backside without the aid of mirrors, so this camera view is a reminder that the main character is not you.
Combining this with McCloud’s point on icons versus realism (from last time), we might guess that a first-person character is closer to an icon and tends to do better as a “blank slate” character that the player can project their own personality onto, while a third-person character that is drawn realistically should have strong characterization.
A second-person camera view, if it existed, would involve the camera that spends the entire time looking at the main character from the front. Needless to say, this would be confusing in the vast majority of games. The closest I’ve seen is an obscure console title, Robot Alchemic Drive, where you control a human character (in third person) that is in turn controlling a giant robot by remote control (in second person). To the extent that the robot is the main character, this game uses a second-person camera for control.
We also use the words “first person” and “third person” when discussing literature. There, it works a bit differently.
A first-person story is when the story is told from the narrator’s own point of view. The main character is addressing the reader directly, telling you a story of what happened to them.
A third-person story, which is more common, is when the story is told from an outside perspective (much like a typical movie camera, where the view just represents a “fly on the wall” and not an actual character’s viewpoint). This may be “third-person omniscient” where the reader can see things that happen and even hear several characters’ thoughts, or “third-person limited” where some information (such as character thoughts) is concealed from the reader.
A rare kind of story in literature is that of second-person, where the story is told from the reader’s point of view. This kind of story is rare because it is very hard to write in a way that is believable.
You might be realizing about this time that almost every game narrative is told in second person. This is the case whenever the player is controlling the main character, which is most of the time.
And this is another reason why storytelling in games is so hard.
Sometimes, the overall plot arc of the game is fixed and linear, but there are a number of characters (specifically, “non-player characters,” referred to as NPCs) that the player can interact with. In video games, where interpersonal relationships must be quantified, there are two common ways to treat NPCs and their relations with the player.
A “flag” in this context is just a binary (yes-or-no) value. An action did or did not happen. The player did or did not talk to a certain NPC, and if they did, they either did or did not choose a particular conversation path. As a result, certain new NPCs or conversation options may appear or disappear.
The advantage of flags is that it is very simple to do. Everything either happens or it doesn’t, making the logic that drives the characters pretty easy to follow. It’s also easy to implement in code; programmers can do binary logic easily.
The disadvantage is that there is not a lot of depth to these characters, if there is only black and white and no shades of gray in between. You can add more complexity by combining binary values (“only make Aragorn appear if Frodo chose to travel to the Prancing Pony and he successfully avoided capture by the Ringwraith and he puts on the Ring”) but at this point it can get complex to follow, reducing the benefit of simplicity mentioned earlier.
Instead of a yes/no dichotomy, use numeric values to measure things like how strongly a character feels affection or hatred towards another character. If you have to decide whether an NPC behaves in a certain way, check to see if its affinity value is past a certain threshold value. (In tabletop RPGs, it is common to also add a die-roll to the mix, so that things may or may not happen based partly on chance.)
The advantage of an affinity system is that it is still fairly simple, it can handle more complexity than a flag system, and it is much more expressive.
However, you must be careful with affinity systems. There is a danger of having a very muddy system (where the player can’t tell why a character behaved in a certain way), especially if several affinity variables or a random die-roll are included in determining the outcome. In short, it is hard to get this kind of system to “feel right” without a lot of playtesting.
Some games include a conversation system, where the player is given a choice of things to say, and then the NPC they’re talking to responds.
Conversation systems can be thought of in the same way as game narrative systems. A conversation can be:
* Linear. I walk up to an NPC and choose the “Talk” command. They tell me something. That is all.
* Branching. I initiate a conversation. The NPC says something, and I am then given a choice of responses. Based on my response, the NPC may say something else and then give me a brand new set of responses.
* Parallel. I initiate a conversation. The NPC says something, and I am given a choice of responses, then they respond, and so on. There are several combinations of responses that can get me to the same outcomes, however.
* Threaded. I initiate a conversation, and am given a set of different ways to begin. The NPC responds to what I say, and each action I take within the conversation may open up new paths of conversation and close older, no-longer relevant conversation threads.
* Dynamic. I go through a branching or parallel conversation. Depending on the outcome, I proceed to a new conversation (or a new area of exploration within the current conversation).
Writing dialogue in each of these methods is proportional in difficulty to writing a story of each form.
Writing Good Characters
Some characters in stories are “round” – they have many facets to them, a deep character with many layers, and are highly detailed and developed over the course of the story.
Other characters are “flat” (or “shallow”) – they are very simple, don’t have a very deep personality (at least, not that the audience can see), and do not develop or change much (if at all).
Normally if we say a character is “flat” it sounds a bit derogatory. Are flat characters always bad in stories? I don’t think so; not all characters need to be complicated, deep, or well-defined. Even in Shakespearean plays, some minor characters are flat (I’m looking at you, Rosencrantz and Guildenstern), but the main protagonist and villain at least should be round.
A rule of thumb is that a character should develop over time as we seen them through the story. As a corollary, minor characters with very little “screen time” can be flat since they don’t have much time to develop anyway; the characters who we see the most often (generally the main characters) should develop a great deal. A flat protagonist is probably not a good idea if you are trying to make a strong character.
Archetypes versus Stereotypes
Here’s a question I was once asked in a job interview: describe the terms “archetype” and “stereotype” and the difference between them.
McKee says that story is about forms, not formulas. Archetypes are forms; stereotypes are formulas.
“Villain” is an archetype. The Snidely Whiplash-esque, mustache-twirling, top-hat-and-black-cape-wearing, purely-mean-for-its-own-sake bad guy is a stereotype.
Archetypes are useful. They allow us to tell a story with believable characters that fit familiar forms. Stereotypes are overused, and typically make a story less believable because the audience has seen these same characters before from other stories, so they do not seem unique. Generally, avoid stereotypes, unless there is very good reason (such as if your story is a parody that is making fun of a particular character stereotype).
You might have seen this before in a grade school literature class. The idea is that stories start with a small amount of exposition to set the tone, then they have rising action where things get more intense, then they reach some kind of climax (a final battle or confrontation, etc.), then there is falling action and resolution at the end as the story reaches its conclusion.
Note that this is not just true for story, but for gameplay as well. Games have exposition (we call it the “opening cinematic” and “tutorial level”), rising action (most of the game), climax (final boss fight), falling action (occasionally some post-fight sequence like a timed escape from the building before it blows up), and resolution (end cinematic).
You get a more dramatic experience if the dramatic arcs of story and gameplay are aligned and in synch with each other. This is a lot harder than it first appears; in many games, the most difficult part of gameplay occurs somewhere in the middle of the game, when the enemies and challenges are getting harder but you haven’t yet found new weapons and abilities to power yourself up to compensate. As the player gets more powerful and better at playing, the challenge of a game often decreases over time, even as the intensity of the story is increasing. You can tell these games when the final boss fight is introduced with this high amount of drama and foreboding, and then the player wins after swinging their sword around for a few seconds – it feels anticlimactic and not very believable.
In short, as you balance your game, pay attention to the story and whether the story drama is proportional to the dramatic moments in gameplay.
It’s Still a Game
Remember that, as a game designer, you are still making a game and not a story. In most cases, the story should not preclude gameplay. At the very least, you should be extremely careful when you are tempted to make a concession in gameplay for the sake of the story, or when you plan to overload the player with non-interactive story bits.
When writing the narrative for a game, return frequently to your core aesthetic – your overall vision of the optimal experience your game will offer – and make sure that the story supports it!
There are lots of ways to take a traditional linear story and make it more interactive. All of these have advantages and drawbacks. If the Holy Grail of a full interactive story is even achievable, we have still not discovered how.
But we should keep trying, and exploring the various non-linear story forms that are uniquely suited to games.（Source：gamedesignconcepts）