Building Non-Linear Narratives in Horizon: Zero Dawn

[Music] Hi, good afternoon. Thank you all for coming. God, there's so many of you. I'm super excited to be here and even more terrified. And I come here today to talk to you about quests, nonlinear narratives, and how we managed to put all them into Horizon Zero Dawn. Now, for those of you who might not know, Horizon Zero Dawn is an openw world action role- playinging game exclusive for the PlayStation 4. It is set in a lush post post-apocalyptic world where gigantic machines have taken over and humanity is no longer the dominant species. This talk will be composed of two parts. First, I will delve into our research into quests, linear and nonlinear narratives, quest systems, quest building methods uh in already existing games. In the second part, I will talk more about how this research led us to the development of our own systems and methods and what exactly they are. Now I know it might be a little bit unorthodox for an engineer

to speak at this specific summit but I think there's a good enough reason for that and uh first of all although right now I'm employed as a programmer at Guerilla Games um my background is a little bit more diverse. I used to work in a well company where I had dual responsibilities designer uh where I also worked on narrative and quest systems and before that I had probably one of the best jobs possible which was being a professional game or dungeon master. Secondly, I kind of hope that an engineer might bring a little bit of a different perspective to the common issues that we as game developers face regarding build uh building game narratives and narratives narrative based games. And sec thirdly, quests are a very interesting concept in themselves. And by quest, I'll be talking about the con the things which you might find in role playing games, not necessarily what might you might encounter in literary studies, although these two tend to be closely related. Now, as some of you might be aware, there are two

perspectives from which one can look at video games. One is the narrative perspective, which understands a game as a form of a narrative. Second is the ludic perspective which understands the game as a set of rules. Now quest has been proposed as this way to combine these two perspective into single concept and that is partly because to exist they need both and to I allow myself to quote Jeff Howard from his really cool book quests which treats exactly about this topic. Quests are about action that is meaningful to a player on a level of ideas, personal ambitions, benefit to society and spiritual authenticity. And the word meaningful is exceptionally important here because it also refers to the concept of meaningful choice which is one of the most important ideas in good game design. The meaning of quests emerges from strategic actions. But these actions have thematic, narrative and personal implications. Through quests, the player interacts with both the rules and the narrative and draws meaning from both of them. So to summize

all that, quests are this place in a video game where game design, writing and technology all come together. So to be able to discuss to to be able to discuss this topic, uh let's have a quick look at a structure of a typical quest. Quests are usually composed of multiple discrete phases or steps. Quests usually follow this typical structure of having an obvious start, obvious middle, and obvious end. Each step of a quest can be considered a single piece of a greater quest narrative. Often a step is connected with a quest log entry which informs the player about their progress so far and forms also sort of a written narrative of the player's personal progression through that quest. Also, a quest step can be connected to one or multiple objectives which inform the player about the tasks at hand. And usually progressing through a quest yields some sort of a reward which has a tangible value in the context of the game. So if we have a game which story is told

mainly through quests, we will need a system which will allow for creation and management of that quest. And the shape of that system, its structure, how it functions and most importantly how we understand it has farreaching implications into what kind of quests we can build and by turn what kind of stories we can tell. So, as some of you might be aware, Guerilla Games used to specialize in first-person shooters and action games in general. So, we when we set out to build horizon, we had nothing of this sort. So, in order to fill the gaps in our knowledge, we decided to look at games that came before and also have a look at how other teams have approached this particular problem. And when looking during pre-production of v at various games, we found mult multiple multiple very different approaches. But all of them could h all of them had this common denominator. And that was that all of them could have been placed on a scale which describes how flexible they are and how strictly they define what

the quest in the context of a particular game is. with systems that we could call relaxed on one extreme of that scale and systems that we could call strict on the opposite extreme of that scale. So what is a relaxed quest system? Well, at its extreme, it's a no system at all, meaning it has no centralized way of managing quests and their progression. It even doesn't have a defined concept of a quest. And any logic that exists to drive the gameplay forward is implemented by the designers directly into the scripting language of a game engine used because such an approach doesn't put any limitations on us. In theory, any kind of story that can be expressed through a quest is possible. However, this does come as a great cost uh of complexity and high time of implementation. So in theory we could create intricate stories which use sophisticated story storytelling techniques which do use complex structures but these kind of quests would be also very complicated to create. However these kind of systems

have been used very successfully uh especially in the early days of computer role playing game uh development. So we're talking about games like Might Magic or Wizardry. But also recently a lot of role playing games built on top of RPGMaker platform also use this method partly because the RPG maker doesn't seem to support system of its sort out of the box. So on the opposite extreme of a scale we have a strict quest system and it's sort of a negative of relaxed one meaning it does use a single centralized way of managing all quests and their progression. Meaning each quest has a defined strictly defined rigid structure and any gameplay that exists during in this game and is based upon quest is not scripted out by the designers but built from predefined elements and as you can imagine such systems severely limit what kind of quest can be created. However, it does have a positive impact on the complexity of implementation, time of

implementation and actually also communication and cooperation between teams because everybody involved in building quests has the same idea of what a quest is, how it's structured and how it should function. And such systems have also been very successfully used mostly though in hacken slash games which are known for their mechanical depth rather than the narrative depth. So we're talking about games like Titan Quest or Sacred. Nowadays it's actually quite rare to find a game which uses a system on but exist on any extreme of that scale and that is because our audiences over time has have started to demand more intricate stories and also more sheer amount of content. So most teams trying to are trying to find this middle ground, this middle of explore this middle of the scale to find this perfect balance between story complexity, freedom of expression, but also scalability and development time. So if you were to put uh the games that

we looked during pre-production of Horizon on a graph that represents that scale, it would look something like that. So on the right hand uh extreme and the relaxed side we would have older RPGs like Vampire the Mascad Redemption or Gothic and also RPG Maker based games. On the left hand stricter side we would have games like Sacred or Titan Quest the mentioned hacken slash games and somewhere in the middle exploring this mentioned perfect balance would be modern RPGs like the Elder Scrolls 5, Skyrim or The Witcher 2. The other thing worth looking at is how do we actually merge rules with a narrative to create quests. Well, there are actually two approaches which seem kind of obvious. First is to write a story and then by injecting mechanics into it and rules and challenges add gameplay or the other way around. First to create these challenges, rules and mechanics and then wrap a story around them. Now, these two methods have been used pretty much ever since we started

building narrative-based games uh and have been perfected over the years tend to work well and have produced magnificent results. However, because we are translating narrative into logic or vice versa, sometimes cracks and inconsistencies can show. So, regardless of our best efforts, sometimes we might get a bit of a dissonance between the rules and the narrative. So once we learned all that, we needed to decide what our quest system would look like, what kind of stories we would like to tell, and what kind of tools we would need to be able to tell them. So we came up with this four highlevel requirements for our quest system and quest building methods. So first of all, common types of quests must be quick, quick and easy to create. And I think that's very understandable. I mean, in any game, the content which is most common should be the quickest and easiest to create. But in Horizon, it had an additional meaning. Horizon Zero Dawn was supposed to be an openw world game from the very start. And open world games require a lot of content, a lot of

stories to create this feeling of a living, breathing world. Not necessarily complex ones, but still interesting. Secondly, complex quests must not be complex to create and manage. So although we were okay with having a lot of relatively simple quests and relatively simple stories, we still want to have this grand narrative, these memorable stories, these quests which embed themselves in the player's imagination memory forever. So these two couldn't be in conflict. Our ability to create content quickly shouldn't hinder our ability to create intricate quests. Thirdly, focus on nonlinearity. So again, open horizon was supposed to be an open world game from the very start and open world games offer the players freedom over player choice and ability to approach any problem from multiple angles. And we needed our stories to reinforce these roles to reinforce this feeling of

freedom. Therefore, we needed quests which are nonlinear at their base. We needed quests that can be progressed by by a player through multiple angles and in multiple ways. We needed our system to have nonlinearity at its very core. And fourthly, finally, provide a base common language for both the rules and the narrative. So this addresses an the issue I mentioned earlier of translating the rules into narrative and narrative into rules. And we didn't really set out to solve that particular issue. And I don't think it actually can be fully solved, but we at least wanted to make a one step in the right direction. Meaning we at least wanted to give the designers and the writers this ability to have the same set of ideas and the same set of concepts in their mind, we're starting to build quests. So after defining our requirements and after throwing some ideas on how we would approach this particular issue, we decided that our system would live more on the stricter side of that uh already mentioned scale. And I think that makes

sense. Again, we needed a lot of content and more regist structures are good for quick development and really improve good communication and cooperation between all teams. So, we knew what we wanted. Now, we needed to detail our approach. We noticed that a lot of games, even the one the ones which do feature magnificent nonlinear narrative, still construct quests as sequences of steps. So even though the player has the ability to deviate from the written story, they are still faced with a linear script to follow. And we wanted to approach it a little bit differently. We wanted to present the player with a probability space instead of a linear script to follow. So we needed a way to visualize our probability space. We need a metaphor that will represent it. And a probability space can be well represented as a graph. So for our first idea was to grab graph theory. So for those who might not know graph theory is

one of the fundamental branches of mathematics and studies the properties of the formal structures that we call graphs. These graphs are understood as networks of points connected by lines. So essentially graph theory is this formal study of connections between things. However, that would be wonderful if our target audience of these methods were mathematicians and artificial intelligence researchers. But we needed the system to be usable, easily understandable for people who might not have this techn this kind of technical knowledge. So we needed to look for our metaphor somewhere else. So I went back in memory to the time where I still had this ambition to become a comic book author and I started trying to remember the techniques and methods of forging stories that I learned back then and I remembered something that I really liked which I know as the wall of sticky notes. So what is a wall of sticky notes? Well quite literally it is a wall filled with sticky notes. But what is special about

this method is that every sticky note represents a single plot point, a single scene depending on how granular you want to be in the plot you're trying to create while the whole wall or the board that you are using is the story that you are trying to write. The other special thing about this method is that the lines that you see between these uh sticky notes represent the cause and effect relationships between events. That means that the event that is represented by the sticky note where the line starts is the cause of the event represented by the sticky note where the line ends. A simple example sticky note one scene one. The protagonist enters a village. A distressed villager approaches them and ask for help for a horrible menace have has entered their v their fields and started killing everyone preventing them from working. Scene one, postit one. The player enters a village and is asked for help.

Scene two, sticky note two. The protagonist enters the fields, guns blazing, killing everything that moves, clearing the whole field from the infestation. Battle with the horrible, horrible insects. Scene two, sticky note two. Scene three, sticky note three. The swarm queen, upon realizing that her minions were slain, awakens and engages the player in mortal combat. However, our protagonist emerges victorious. The battle with the swarm queen. Scene three, sticky note three. And our final scene, our final sticky note, the protagonist gloriously returns to the village and gives is given rewards in the form of bags of wheat or something like that. So we have this very simple story this chain of events one flowing from the other connected by cause and effect and we created a chain but as you can imagine a single event doesn't need

to cause a single other event. It is absolutely possible to be the cause of multiple. So we can create this sort of a web a cause of cause and effect relationships between plot points. So once we create this uh web of relationships, we can start writing our story and start um fleshing out our scenes. So we can either go chronologically or from start to finish or we can scramble it about and go all Quentin Tarantino on it. But uh regardless of the methods what we use when the story is written, we have a very good idea of what event causes which and makes us less likely to have logical plot calls. Well, I really like this method. I figured, hey, let's see what happened. So, how did we translate our wall of sticky notes into our quest building method? So, we decided to represent a quest as a graph of steps. Each step is a scene or a major event in the greater plot of a quest. Initially, only start steps are available to the

player. But as the player progresses through a quest, meaning as the player completes the steps, meaning as the player experiences the scenes defined by the nodes of that graph, different parts of the story open up before them or close. And once the player reaches one of the end steps, meaning experiences one of the end scenes, the quest will end. Now, I'll show you a very simple example of how that actually would work. So, the player starts the quest by talking to a villager and being asked for help. Now after that the start part of that quest is finished completed done. However two options uh open before the player in the step A in our scene A the player has the ability to go guns blazing into the field and kill everything or can uh instead try to approach this swarm queen and maybe work out some sort of a solution. Now what is important here is that these two additional steps are possibilities that the player gets and also as you can see there are no

lines between them. That means there is no relation between these two steps. Meaning the players is absolutely allowed to first talk with a swarm queen and then go into a field kill stuff or first go guns blazing or and then decide to talk to with a swarm queen or can actually ignore any of these branches altogether. However, if the player decides to be aggressive and kill the all the insects, then the option of slaying the swarm queen opens up before them. And now, as you can see, there is a relation between talking with the swarm queen and slaying the swarm queen. That red line represents that if the player experiences the scene in step B, the step C becomes impossible. It is removed from the plot. It is no longer accessible. that. But what is important, there's no line in the other direction. So the player is still able to talk with a swarm queen and then be a douche and kill her. But regardless of what they decide, slaying her or talking with her, the

option to end the quest opens up before them. So by traveling through this quest graph, the player has a multiple way to multiple ways to progress through the quest and in turn multiple personal narratives are possible. And all of these possibilities are created just by defining the cause and effect relationships between scenes. So the way this would work in practice is that the writer would imagine this web of possible events where each event unlocks other possible events in consequence creating our probability space. The quest graph. The designer would have the same graph in their head. However, the nodes of that graph would have a very different context, a more rules focused context. But because the initial step would be the same, meaning both the writer and the designer would start out with the graph and build on top of it, there would be less translation needed between the roles and the narrative. So now we have the graph, our grand story structure, but how does the player progress it? So each step is understood

as a scene and that scene must have a major verb which defines what action the player needs to perform in order to progress. And sometimes we also define a target of that action. So the player can obtain an item, kill a monster, talk to an NPC. And in our system, we supported a finite amount of these verbs. I'll give you two very simple examples of how that would work in progress uh in practice. So the simple scene, the player after searching through rubble finally finds and picks up Amulu. plus one for anyone who knows what amalo the ender is. So the major po major verb in this scene is pick up meaning the player takes and puts in their inventory and the object of that of that scene the target of that action is the amulet of yandor. So in game logic this would translate to obtain put in inventory and the game object is amulet of yandor meaning once the player obtains puts in their

inventory the amulet of yandor the quest will progress. Second very simple example in the arena the player defeats all six opponents. So the main verb here is defeat which translates into our game logic to kill. And our six opponents because we are in arena are gladiators and there's six of them. So once the player kills the six gladiator the quest will progress. So to summarize all this, tests in Horizon Zero Dawn are built as a graph of steps, possible plot points which are linked together by cause and effect and defined by actions needed to be performed by the player. So while using our methods, we managed to succeed in some areas and not so much in others. And I would like to tell you about the most interesting cases. So let's talk about the good stuff first. So first of all the graph structure did indeed assure that we could create

naturally and without any hacks or workarounds nonlinear quest meaning everyone in the team involved in building quest was thinking nonlinearly and it was our main mode of operation. Secondly having this limited set of verbs which defined actions required to progress the quest made it indeed simple to create our common types of quests. However, because we supported a wide enough variety of these verbs, we didn't hinder our ability to create more sophisticated ones. Another very interesting con success that we got which was actually quite unexpected was our player jobs. So, we noticed that certain simple patterns which use specific verbs recur quite frequently. And because our system was relatively strict, we managed to automate creation of quests based off such patterns. And in the end, this ended up our our player job system. So

we allow the player to generate a quest for themselves during game play for certain particular uh purposes, for example, bartering with a merchant or crafting an item. So the player can choose a recipe, press a button, and that will generate a quest which will guide the player through obtaining all the necessary items and then crafting the item. However, from the perspective of a player, a generated quest and a handcrafted quest are not uh possible to distinguish. And the most interesting problem that we faced that I really would like to talk about is the time travel problem. So when you read a book, when you watch a movie, when you read a comic book, once a scene occurs, it occur occurred, right? When you uh when a event happens, it happened. It cannot unhapp it, it cannot unoccur. It's there in the timeline forever. It's there written on these pages forever. However, during gameplay, that's not always the case.

Sometimes for the sake of clarity and for the sake of not confusing the player and sometimes for the sake of streamlining the gameplay, we allow for the story to roll back. We allow the story to go to the previous state. A good example of that happening in Horizon were our bandit camps. So bandit camps were very simple quests. The player needs to find a bandit camp. The player needs to enter the bandit camp and the player needs to perform certain activities activities in that bandit camp which is usually slaughtering of innocent bandits. Um, and the thing is that because we had this open world and paradigm in our heads and wanted to give player freedom, once you enter the bandit camp, it's absolutely possible to leave it. But the story already progressed according to the plot, according to a quest log, you have entered the bandit camp, kill all the bandits and leaving made it actually kind of confusing for the player what's next to to to happen. So we needed to move the story back one step when the player left. So that from the

perspective of the player, they need still to reach that bandit camp and do whatever they need to do. However, because our system was so deeply rooted in a storyw writing metaphor that wasn't supported. However, we realize that uh this is an issue and we are currently working on uh fixing it in a non-hacky, nonh horrible way. We managed to work around the issue in the end, but uh we still are looking at a very appropriate solution. So, to close this up, uh the system that we created and our method served our purposes quite well. a team that never created a quest-based game before managed to create almost 150 quests of various complexity and I've and as I've been told some of them actually well were quite well received and also we had these unexpected successes of being able to generate these player job create these player jobs which is one of the coolest quality of life feature that we have but the system is not perfect we still need to improve it so we still

need to fix our time travel problem and the in the end the list of the verbs that we had didn't sufficiently meet our needs. Some were made redundant, some were some of them were overly specific. Uh but we'll just need to revise them and everything will be fine. So that's it. That's pretty much how we [Applause] Thank you very much. You have three minutes if you want to do three minutes. Yeah. If anybody has any questions, I'm cool to answer something. Two minutes. So, two questions, I guess. Uh, hello. So, have you run into any problems with the complet uh completionists? Because uh in this web of uh possible actions in your quests, there's always one way to, you know, get

the most benefit of and people sometimes will feel like I'm not playing the game 100% if I don't go through all the possible steps I can I can do uh certain quests. Do you have any Well, the idea was to actually not make it not even possible to like play the quest in all possible ways in one single sitting. But, uh, for completionist sakes, um, there were like key points in every quest like the one of endings or something like that and these counted to the completion ratio of the whole game. So, although we did have nonlinearity, we also had these choke points sometimes for these specific purposes. Uh yeah, another question. Yeah. Um just uh something quite interesting that you mentioned. You mentioned um a single player action um you know causing uh and having a causal reaction on multiple threads in a way and in this complex graph um how much interplay is there between the different

threads in your graph and how do you manage that complexity cuz that can easily exponentially you know explode. Okay, so uh the question was how do we manage actually the complexity that the graph complexity grows exponentially with every node added but specifically with the interplay of if there is much interplay between the threads in the quests if that makes sense. Yeah essentially if if I understand correctly if there's inter interplay between certain parts of a quest how do we manage the complexity of that? Well, we have we have very good tools. Uh so essentially we create a specific editor that will allows uh the designer to see the state of a quest exactly which nodes are blocked, which are available, which are completed during playthrough of a quest. So by playing a couple of times and seeing how everything lights up and uh lights down, it's al possible to figure out uh what what is not going okay, no, what's not right. Plus, we had some debugging tools specific for these purposes, but in the end, nobody created

such complicated quests that they were impossible to figure out what's wrong with them. Okay. But there wasn't that much interplay between quests and and that was between quests, not so much. Okay. Okay. Cool. Thanks. Okay. Thank you. Yeah. Uh if anybody has more questions, I'll be in a wrap-up room, but further away in the corridor. Thank you.