An Open World Branching Narrative System - Devlog #4

13 Sep 2022Developer post

Source: Steam Community (opens in a new tab)

In my Scrolls-like first person open world RPG All Hail Temos, one of the most important systems is the Narrative System, which handles conversations between the player and NPCs, or NPCs and NPCs, or NPCs speaking out loud in exclamations, and is also in charge of managing the quests and a good deal of the world logic.

There are a lot of ways to approach this, and one popular way is to use the type of branching dialogue system that Skyrim or Fallout uses, in conjuncture with day-night job schedule system and a task based quest system. This is a popular method, and is used in a lot of RPG games with different kinds of setups. Some are more dynamic, and some are more statically scripted.

One of my primary concerns was that I want to be able to make the narrative content inside All Hail Temos (AHT) to be absolutely gigantic as the game development progresses, so that years and years of writing can all live together, and still maintain it’s logic and cohesion, and be able to be worked on and developed. And I also needed it to not be too onerous to make additions or understand what is going on.

Just describing a summary all the different design points I wanted inside this system would be a full blog post in itself, and I’m looking forward to writing about it, but first I should give examples of how the system actually works, and how I build it.

Interactive Fiction - Ink Lang.

Here’s a list of talks about the Ink language developed by studio Inkle:

Ink is the language I decided to base my system on, because of their design goals of trying to keep writing the dialogue as close to writing a novel as possible, which is the most writer-friendly, and their very clever methods of using very simple data to control complex data in the massive chaos that a branching story creates.

The basic tenants of Ink’s data usage that interested me are:

All data stored is just a named integer: ex: “times angered” = 0, 1, 2, 3…
All data can be treated as either a “counter” or a “state”. A counter is just the above, a named value that goes up and down: angry = 6
A state is a list of ordered named counters under a label, that can only be 0 or 1, and when a state is active (equal to 1), all previous counters in the ordered lists are set to 1. ex: lifespan: born, alive, dead. If I set the state to “alive”, then born and alive are both 1, and dead is 0. This can never go backwards, only forwards.

Example state group “lifespan” with 3 states, only flows one way.

That’s it. Those are the core data rules. Counters are named numbers. States are a list of names that are either 0/1 and can’t go backwards, and all previous items are set to 1.

This is simple and brilliant, as it is a toolbox that can do almost anything, but has the one important constraint that states only go 1 way, and anything in the order of the state items are always true (1) if a further along item is true.

But, Ink was created for writing interactive fiction, not a 3D open world. They have begun to expand what they use it for, and Heaven’s Vault has a 3D style movement interface, but it is ultimately reading very much more like a choose your own adventure book than something like Skyrim or Fallout: New Vegas, which have a lot more flexibility in where you are, and who you are talking to, and a very dynamic context.

My Narrative System - NAR

NAR is what I’m calling the All Hail Temos narrative system, as it is good for the ending of text files (.nar), and it’s short and descriptive and doesn’t appear to be used by anyone else according to Google. I started trying to adapt what Ink was for an open world game, where there are often many different narrative threads or quests going on at any given time, and the player can pick and choose what they want to do now.

There’s a lot more to this freedom, and some of it is very similar to how Ink provides flexibility, but other aspects of it are quite different. For one, Ink is designed primarily to deliver a narrative and any other gameplay has to be tuned to work with this. I think Ink could be used for this kind of open world RPG game, but it is not purpose suited.

Here are the basic types of interactions that I want to allow with NAR:

Approaches: An NPC approaches the player, and starts the conversation.
Barks: An NPC says something to themselves or another NPC within earshot of the player. 2+ NPC might have a short conversation.
Replies: An NPC doesn’t have any conversations available, but can reply with a short response, which might be general or tuned to the context of an active situation.
Prompts: This is the primary method for starting a conversation, which a player can ask an NPC about a subject, get directions, get or progress a quest, or any other intros into a conversation. Prompts can link to Dialogues, or have a short question and answer directly.
Dialogues: When a player selects a Prompt and it is longer than question and answer, they are redirected into a Dialogue section. These can branch, go into depth, or redirect to other dialogues. In NAR, I call these “dialogues”, but I prefer to refer to them as conversations as they may have more than the player and 1 NPC. Any available NPCs could join in on the conversation, and they can trigger events in the game, which makes all dialogues a type of simple interactive cut scene.
Stages: This is where in the world an NPC is at the moment, and can have different Stage Stations they move between, such as doing a patrol, or working on a blacksmithing anvil, or standing at a sales counter. The NAR system handles the placement and activity of all NPCs that aren’t in combat or following the player as a companion.
Stage States: Every stage can have multiple states, such as a store having day and night states, such that in the day it has a sales person in it, and the door is open and chairs are available for sitting, and at night the door is closed and there isn’t a sales person and the tables are put on top of the tables. States can also be used for events, such as monsters attacking a town, then NPCs would be in different locations, doing different things (ex: defending the walls), or it could represent a change in the narrative, such as a store having had a fire, and now the inside is burned and the furniture is gone.

These are the core elements of the NAR system, so instead of having NPCs on dynamic schedules where at 8AM they go to work and 5PM they go home and eat and 10PM they go to sleep, I do essentially the same thing but with stages that use counters and states inspired by Ink.

An Example

Let’s see an example of some NAR Prompt data to see some of the elements in action, I’ll crop it to 2 prompts to give the idea without getting too long:

== ENTARA_WORK_FARM == { AtStageState(protect_farm_intro, protect_farm_met) } #p:1 - (entara_work_farm) * (entara_work_farm1) !{protect_farm_intro} [Your Farm?][House] You: Nice to meet you, is this your farm? -> ENTARA_WORK_FARM_INIT_OPEN #line:5001 ~ Advance(protect_farm_intro) * (entara_work_farm2) !{protect_farm_intro} [Looking for work][Work] You: I'm looking for work, do you need anything done? -> ENTARA_WORK_FARM_INIT_WORK #line:5002 ~ Advance(protect_farm_intro)

To start with there is a == TOPIC_HEADER == which has a {condition} and a #tag. This tells me if we can use any of these prompts, based on whether all the conditions are true. The tag in this case gives me the default priority for all these topics, #p1, which is high priority. All prompts that meet the conditions are given to the player, and just sorted in order. If there is 1, or 3, or 30, the player will see them all.

I try to give 3-4 choices for any given topic, but there might be multiple topics active, such as asking for directions, which are lower priority. In practice, the list won’t get that long, but I don’t limit it, I just prioritize which are first based on priority and what you have been talking about or doing recently.

Once a topic has been selected, it will run it’s course and can’t be cancelled until you finish it, so I keep them fairly short, but once completed you will never see it again. The conversation element happened and is done. It’s recorded in your Journal so you can be reminded of it, but I don’t leave it as a grayed out option which is popular in some games. You can bring up your Journal at any time, and it will help you read relevant conversations in the past.

There is a bunch of markup here in the prompts, similar to Ink, but I also have this [Short Text][Icon] option for optional radial wheels for gamepad players, and I also always show the first link with “You:”, the player, so you don’t have to guess what you will say if you select this prompt, you can see it. Mouse and KB players will get a list of choices, which may get abbreviated, but also see the full option.

Both of these lines redirect to the same sub-topic (Prompt -> Dialogue) ENTARA_WORK_FARM_INIT_WORK.

There are also #line:5002 type tags which are used for playing audio files and translation into other languages, and a command line with ~ Advance(protect_farm_intro) that advances a state so we know we have started this line of conversation.

States and Conversations

Here’s an example of the states related to the above prompts:

states: protect_farm: protect_farm_intro, protect_farm_met, protect_farm_know, protect_farm_find_exploit, protect_farm_success, protect_farm_fail

The overall state name is “protect_farm” and it has 6 state values in it, which are all set to 0 when a new game is created. With one of the above topics selected, we advance the state to protect_farm_intro, which sets that to 1 (true) and the rest remain 0 (false). Once this is set, it can never be unset. We can trust that this state will always be true for any narrative test we want to do. If I were to advance to “protect_farm_fail” , then all the states with be 1 (true), and could never be changed.

There will be an art to ordering states such that it always makes sense which order they are in, as the flow of logic can only go 1 way. Should fail be last, or success? It will depend on if something could fail, but then be fixed and ultimately succeed. In this case, you can succeed, but ultimately somehow fail, or it could just stay at success and never advance to fail because the option isnt available or wasn’t selected.

Starting with 1 prompt, a trimmed example of branching dialogue.

Here is the conversation that continues, in part:

-- ENTARA_WORK_FARM_INIT_OPEN -- - (entara_farm_open) - + Hygara (pleased): Yes it is. Well, I rent it. You were just at the mansion of my land lord, did he ask you to come here? #line:5021 ~ Set(offer_work_2) ~ Advance(keep_farmer_met) * (entara_farm_looking_around) !{offered_work} [Fighter][Combat] You: I'm just looking around. He asked me if I had a job and I told him I was already employed, so he told me to leave. #line:5022 Hygara: Where do you work? #line:5023 > (entara_farm_intro_myself) [Fighter][Combat] You: I am a new recruit to the Lord Mayor's service. #line:5024 > (entara_farm_intro_myself2) [Explorer][Explorer] You: I'm an explorer. #line:5025 Hygara: Do you always walk around the backwoods when you arrive somewhere new? #line:5026 >> (entara_farm_intro_myself2a) [Like Exploring][Explorer] You: That's what I like to do. #line:5027 Hygara: I suppose I like farming about the same. #line:5028

This structure is basically the same as the prompt, but it starts with the NPCs talking, and in this case Hygara only has 1 line before you have more prompts.

Then it has sub-prompts, which indent inward, making it easy for me to write immediate replies without having to jump all over the place, and pretty easy to see which prompts go with with conversation section, and allows sub-sub-sub prompts inside a single sub-topic section.

As my design goals stated, I wanted to be able to have a very scalable system where a lot of dialogue and options could be written quickly. While there are a lot of little markup and formatting that need to be follow (really just indenting and the symbols), it reads similar to a screenplay, but with options.

How does this affect gameplay?

The most important part is how this affects gameplay, as always.

This system will allow a lot of different narratives to be written, and simplifies the hardest part of branching narratives, which is making sure all the branches don’t get into a locked state where you can’t progress the story.

Because the state data can only flow in 1 direction, and all the previous states are always true when a further state is true, and remaining states are false, it is very simple to make tests and get answers that reflect the “state of the world”.

This also allows multiple ways to get to a state. I am only tracking what state something is in, not how it got there. So there may be many ways to set a state. In that case I would have counters or other states where I track how those went, and testing groups of conditions allows me to tell how you got to any situation so I can write custom responses to your actions.

This structure should lead to less bugs in the narrative and quests, as the Inkle folks have found, and the simplified writing will make it easier to write more content, as the standard node-based dialogue systems become very unwieldy as they grow. Text is the natural medium for writing, and the NAR system, following Ink, stays with text and remains similar to a screenplay, so more dialogue can be written, with different branching narratives.

The negatives of branching narrative for game development is more work. Every branch means another set of writing to do, and as branches increase, so does the amount of writing. But with this system, and by being methodical in how I write with it, I can write quickly and provide more choices for players than I would be able to do in a standard node-based narrative model that most games of this type use.

Comparison: How node-based dialogue is often displayed and written

Because NAR also integrates the NPC schedules, and special events and scripted scenes together means it can be more cohesive and all of these things are normal elements of writing in NAR, and not special events that can only be afforded to be added rarely. I can easily create another Stage State where a store has been damaged, and items are missing, and the NPCs around the store talk about the incident when appropriate.

Conclusion

Open World branching narratives are always ambitious endeavors, but thanks to the pioneers at Inkle creating Ink and giving excellent talks about how it works, and how to write with it, I was able to create something which I think will make a good open world narrative system. I’m very much appreciative of how open they were and continue to be about this information and how much thought and refinement they put into it.

When All Hail Temos reaches 1.0 I will also release the full spec for the language and a C# API, and I hope my work will help someone else in the future!

If you’d like to find out more about All Hail Temos, please Wishlist the game, so you know when it’s coming out, or Follow to see more updates like this.