In this section, you'll learn how to provide the player choices and move them around your script non-linearly using labels / jumps.


Before you can move the player, you have to create places the player can be moved to. Placing labels into your script is just like placing bookmarks into a book.

  • You place them anywhere that you want to be able to jump to quickly.
  • You can place as many as you want in as many places as you want.
  • You can read right over them - they aren't part of the story.
  • To label a section of text put a colon (:) followed by the name of the label on a line before any other text
Here is some text under a label

When creating labels, there are a few rules that must be followed.

  • All labels must be completely unique. Imagine if you told someone to turn to the pink bookmark, and there were two pink bookmarks in the book. How would they know where to go?
  • Label identifiers can ONLY support letters, numbers, and underscores. No other characters allowed.


Once you have a label in place, you can send players to it with a jump. Create a jump by typing an arrow -> (hyphen and right carrot), a space, and the identifier of the label you want to navigate to. Only add the identifier to the jump. That means no color, such as in a label

Off we go to Neverland
-> neverland

This line is skipped

We're here in Neverland
  • A jump or label can be by themselves (extra lines around them)
Off we go to Neverland

-> neverland

This line is skipped


We're here in Neverland

The game reads your script top to bottom. As soon as it progress hits your jump, it will immediately and invisibly navigate the player to a label with the matching identifier in your script.


Choices are the primary way we create interactivity in Tales stories. There are three components:

  • Spoken Line Prompt
  • Choice Option A
  • Choice Option B

Note: There must always be exactly two choices per choice point. We will support more in the future.

Spoken Line Prompt

This is identical to a spoken dialogue line except that it's rendered with a blue stroke on the outside as a question to the player.

Choice Options

Options are horizontally made up of:

  1. * This defines the line as a choice option.
  2. (Emotion) Works the same way as in a spoken line.
  3. Dialogue. Works the same way as in a spoken line.
  4. A jump (Made up of a -> and identifier).

You may notice that the choice options are nearly the same as spoken lines, only horizontally laid out instead of vertically. The only missing component is the Actor, who, in the case of choices, is always assumed to be the Voice Actor.

Something tells me these aren't blood cultists. 
* (Smug) Obviously. -> cultists_obviously 
* (Confused) So who are they? -> cultists_they

Action Options

[#act] is a type of Style code only used in choices, which prevents options from being spoken by the Voice Actor and entered into the history. For example, if Bob chooses to (Jump out of the way.) when a car is driving toward him, we don't want Bob to actually say , "Jump out of the way!"

Drusilla smiles at you, then jogs ahead with the torch. 
* [#act] (Neutral) (Chase Drusilla.) -> answering_cornelia 
* [#act] (Neutral) (Refuse to play her game.) -> answering_behind

Special rules

  • #act options should be stylistically wrapped in parentheses. This lets the player know they are choosing to do something rather than say something.
  • Even though #act options are never spoken, they still require an emotion. Always add (Neutral) prior to the option.
  • You cannot add a Reward inside an #act option. See more about Rewards in the Rewards section of this guide.
  • It is possible to have one option be an #act option, and the other option to be a spoken option.
  • You should use spoken options rather than #act options whenever possible.
  • The first line in the content following an #act option must have a Narrator explanation of what the player chose.
What are you going to do about it, huh? 
* [#act] (Neutral) (Punch him.) -> huh_punch 
* [#act] (Neutral) (Ignore him) -> huh_ignore 


You punch Mike squarely in the jaw. 

-> huh_knit 


You choose to ignore him. 

-> huh_knit

Naming Convention

  • In the example below, notice that both the :dress_great section and the :dress_else section both end with a -> dress_knit jump, and therefore both culminate in the :dress_knit section.
  • This is the fundamental structure of simple choices - branch out, then knit back together.
  • Notice that the identifier used starts with the end of the prompt (dress) + underscore + last word of the Choice Option (great and else).
What do you think of this dress? 
* (Happy) It looks great! -> dress_great 
* (Confused) Maybe try something else? -> dress_else 


You think so? Great! I'll wear it, then. 

-> dress_knit 

: dress_else 

You don't look so great yourself, you know. 

-> dress_knit 


Let's just get moving so we're not late.


  • A Variable is something you give to the player to reference later. It could be narratively abstract, like whether or not a character listened to their mom's advice, or narratively physical, like coins. Both are handled in the same way by your script.
  • Variables are made up of hard brackets [], an operator "+", "-", "=", and an identifier placed inside brackets.
  • All variable activity (adding, subtracting, checking, etc.) is hidden from the player unless specified as a Reward. (See section Rewards later in this guide.)

All variables must be unique to the episode.

Basic Operators

Grants are declared with an opening operator, a named variable, and an optional quantity

  • [+ ALICE] Increment inventory value ALICE by 1
  • [+ ALICE 5] Increment inventory value ALICE by 5
  • [- ALICE] Decrement inventory value ALICE by 1
  • [- ALICE 5] Decrement inventory value ALICE by 5
  • [= ALICE 10] Set inventory value ALICE to 10, regardless what it was before

Quantity can be a variable instead of constant number:

  • [+ ALICE BOB] Adds the current value in the variable BOB to the variable ALICE
  • [- ALICE BOB] Subtracts the current value in the variable BOB to the variable ALICE
  • [= ALICE BOB] Sets the variable ALICE to the current value of the variable BOB

  • These are equivalents, the first is a shortcut you should use:

    [+ Coin]
    [+ Coin 1]

Soft-Capped Subtraction

  • Variables are assumed to start from zero and cannot go negative.
  • If the player hit [= fish 5] followed by [- fish 10], the player would have 0 fish with no warnings nor error.
[= money 3]

[- money 3]

Aw crap, I dropped my three-dollar bill!

[- money 58087]

At least it can't get any worse. I STILL have no money!

Embedding in Dialogue

  • You should have the variable grants happen in-between dialogue:
[+ pizza 7]

Aw man, all I found were seven slices of pizza. Where's the eighth one?

[+ pizza]

Woohoo! There it is! I now have all eight slices!

Reward (Visualized Variable)

  • Variable Grants are invisible to the player but we can add some simple syntax to make certain ones visible.
  • These rewards should feel either reactionary or exciting to the player, such as when a character responds in a certain way or when the player comes upon a treasure, clue, or key.

There are two ways to present a Reward:

  • Doober: A small announcement of a variable award directly attached to a chat bubble.
  • Result: A large, standalone announcement of a variable award.


Doobers have 2 parts: Title Text and accompanying Icon

  • Add : and Title to convert a Variable to a Doober: [+ VARIABLE : Title]
  • Emphasize the key word in the reward text by placing a carrot ^ before the word. [+ INFLUENCE : You gained ^Influence!]

  • Prop Icons: If a variable is named the same as a Prop that has an associated image (in this case Coin), an icon will appear with the description. [+ STRENGTH 1 : You gained ^strength!]

  • Actor Relationships: If a variable is named the same as an Actor that has different ranks of relationship (emoji scale), an Actor Portrait will appear with the description. [+ ANNA : ^Anna appreciated that!]
Attaching Doober to Dialogue
  • Doobers should be visually attached to dialogue so player sees what the reward is associated with
  • Place the variable after the Speaker and before Emotion
    `[+ JACK : Jack likes this]`
    I like how you think!

    Only one code section involved with variables can be attached per line.

Attaching Doober to Choice
  • The Doober needs to appear right after the *
  • This example below will show a doober attached to the choice the player makes:
How do you plead?
* [+ Humility : Increased your ^Humility] Guilty -> plead_guilty
* [+ Bravado : Increased your ^Bravado] Innocent -> plead_innocent

Attaching Doober to Action

  • Variables cannot be attached to a choice option using [#act].
  • If you need to attach a Doober to an [#act] choice, place it on the Narrator text that directly follows the choice rather than on the choice itself:
Let's go!
* [#act] (Neutral) (Follow her.) -> go_her
* [+ AARON : ^Aaron thinks that's sweet.] I think I'll stay with Aaron. -> go_aaron


[+ JENNY : ^Jenny thinks that's awesome!] 
You follow Jenny, leaving Aaron behind.




  • Results are used for for large moment, especially when they represent the culmination of multiple actions for the player.
  • They have an Icon, Title, and an expandable Description box with room for many words.
  • The Icon and Title follow the same rules as for Doobers.
  • Results are never attached to dialogue. They are the cumulation of many decisions narratively.
  • To create a standard Result Reward, create a Narrator line, then add Doober syntax, a [#result] style tag on the same line, and type your result text:
    [+ COOP : Cooperation gained!] [#result]
    Donovan will cooperate with your investigation!

On rare occasions, you may want to use a Result with no description:

[+ COOP : Cooperation gained!] [#result]

Persistent Display in HUD

You can make any variable appear in the HUD, allowing the player to see their numerical inventory at the top of the screen. This allows the player to have a concrete objective to follow over the course of the story.

There are 2 ways of doing this:

  • Scored Variables
  • Tracked Variables

Scored Variables

Scored Variables will appear in the HUD and will also be displayed on the end screen so the player will how well they did compared to how well others did.

First, you'll want to declare these special variables in the Header of your file by having a line that looks like this:

| Score  | FELIX 200 250, TREASURE 0 4

This means the player had the opportunity to increase Felix from 200 to 250 in the Episode. In addition, they could have received anywhere from 0 to 4 Treasure.

Next, add these variables to the HUD using the (Reveal VARIABLE) as a standalone line at the moment you want the variable added to the HUD.

  • You only need to reveal EACH variable once per episode.
  • If you want the player to see the variable from the beginning, add the Reveal(s) at the very beginning of the script.
  • If you don't want to spoil an incoming variable before it appears in the story, add the Reveal directly before the first grant of that variable.

For the first time since taking the mysterious serum, you feel stronger.

Dynamically Tracked Variables

You may decide to track a variable over the course of an Episode but not display it on the end.

  • This is narratively used if you want to create a mini-game that leads to a larger pay-off.

Imagine in the middle of an Episode an earthquake happens and you have to search for survivors:

  • (Track SURVIVORS) adds the inventory SURVIVORS to the list of tracked inventories to start the mini-game.
  • [+ SURVIVORS : You found a ^Survivor!] use this command every time they find a Survivor. The HUD will count up.
  • [+ REPUTATION : Townsfolk Reputation Increased!] [#result] is called when you have found X Survivors.
  • (Untrack SURVIVORS) removes SURVIVORS from tracking and the HUD once the player is past that portion of the narrative.

Here are additional commands that will turn a Tracked Variable into a Scored Variable:

  • (Track SURVIVORS Hidden) same as above but it starts off Obscured
  • (Reveal SURVIVORS) un-obscures the tracking inventory SURVIVORS
  • (Range SURVIVORS 0 3) sets the range for the tracking variable (displayed on the end page)

Variable Memory

  • You can selectively carry over certain variable values between Episodes in the same Season.
  • This also opens up the possibility of skipping to a later chapter without requiring a full play through of the previous (e.g. Mass Effect)
  • Step one is to define the variables you want to carry over and their default values:
[= TRUST 5] 

[= INFO 5]
  • Then add an Import function right after [=<< PREVIOUS_EPISODE]. PREVIOUS EPISODE is the Name of the story you're importing from
  • In the example below, this is the top of Episode 3 and we want to carry over TRUST and INFO from Inside Episode 2
[= TRUST 5] 

[= INFO 5]

[=<< INSIDE_S01_E02]

Other variables in INSIDE_S01_E02 are not imported because they have not been declared in this Episode yet.

Multi-Episode Imports

  • You can import variables from multiple Episodes. Keep in mind the order matters for which value wins if there is a conflict.
  • This example below imports a decision from Episode 1 (did you save Clementine?) before importing the 2 variables that are typically carried over from Episode to Episode.

[=<< INSIDE_S01_E01]

[= TRUST 5] 

[= INFO 5]

[=<< INSIDE_S01_E02]


  • A chapter can be replayed at the end using the normal replay mechanism.
  • On starting a story that has already been completed, its data is deleted starting the player off fresh.
  • Since the values are copied into a story on import, this has no effect on any stories that have already imported this story data.
  • It also has no effect on other stories earlier in the chain as their data will remain until wiped via a replay or other mechanism.

A special "Replay Season" option will delete all Episodes in a particular Season and then replay the first Episode. If stories from other Episodes have imported data from chapters within this book, they will not be affected.


  • To combat buyers remorse and friction between micro-transactions and replay, micro-transactions are stored separately from normal story inventory and choice path and are not wiped during a replay or book replay.

Premium choices require a flag name so that they can survive alterations during a republish. When the player arrives on a premium choice that they have already purchased it will be already unlocked and available (but not mandatory to select).

Relationship boost purchased at the end of a chapter is recorded separately and has no effect on the chapter replay, however when the chapter completes, they are re-applied without requiring a purchase.



Once a player has been given variables, you can check against them to determine what the story does next. This is called a Condition.

Basic Condition

  • The simplest condition is [? variablename], which means, "If the player has at least one variablename, execute what follows."
  • This statement will check if the player has at least 1 Coin:
    [? Coin]


  • This is how you can check if they have 2 or more Coin:
    [? Coin 2]


  • Operators give you a way of comparing your variable to another value.
  • The example above is actually using a hidden operator >=
  • It's really a shortcut of the example below:
    [? Coin >= 2]
Valid Operators

Here's a full list of the operators you can use:

  • =, == Equal to (exactly)
  • <>, ~= Not Equal to (anything but)
  • > Greater than (not including)
  • < data-preserve-html-node="true" Less than (not including)
  • >=, => Greater than or equal to (at least)
  • <=, data-preserve-html-node="true" =< data-preserve-html-node="true" Less than or equal to (at most)

Much like algebra, there are often more than one way to get to the same result. Here's some examples using Coin as our variable:

  • [? coin] means "if the player has at least 1 coin, then..."
  • [? coin 5] means "if the player has at least 5 coin, then..."
  • [? coin >= 5] means the same thing.
  • [? coin = 0] means "if the player currently does not have even 1 coin, then..."
  • [? coin > 5] means "if the player has more than 5 coin, then..."
  • [? coin < 5] means "if the player has fewer than 5 coin, then..."
  • [? coin <> 5] means "if the player does not have 5 coin, then..."
  • [? coin <= 5] means "if the player has fewer than or equal to 5 coin, then..."

Inverted Condition

  • You may decide to check the other side of a Condition.
  • For instance you already know you can check if the player has any Coins using either of these:

    [? Coin < 1]
    [? Coin = 0]
  • But there's a shortcut!

  • ALl you have to do is place a ~ right after the ?.
    [?~ Coin]

In fact, all of these are all equivalent:

[?! Coin]
[?! Coin 1]
[?! Coin >= 1]
[? Coin < 1]
[? Coin = 0]

Gates (Conditions in Choices)

A gate is a condition placed on a choice option that restricts access to player who don't possess the requirement. You can only place a gate on one option. Placing a check on both options could create a scenario in which the player meets neither and cannot proceed.

Note: Always place the gate on the first option (for consistent style).

Requirement Gate

  • A Requirement Gate will display the option, but restrict access for anyone who does not meet the requirement.
  • A Requirement Gate does not deduct from player inventory.
  • There are two types of Requirement Checks:
    • Numerical and binary.

Use a numerical check gate when you want the player to see a numerical value on the gate. This is useful for variables that are counted, such as:

  • Money
  • Oranges
  • HP
I'm going to fall!
* [? STRENGTH >= 5] (Surprised) I'll catch you! -> catch_bill
* (Nervous) Good luck! -> drop_bill

In the above example, the option I'll catch you! will appear regardless of the player's current STRENGTH value, but will only become selectable if that value is 5 or higher. If the player does not meet the condition, they will be forced to choose Good luck! Instead.

Note: You can use any operator in the condition except for = by itself, which is exclusive to binary gates.


Use a binary check gate when you don't want to show the player a number value. This is mostly useful for "yes or no" checks that you would normally not count, such as:

  • Did the player save her village?
  • Does the player know the password?
  • Does the player have a one-of-a-kind artifact?

To remove the number from display, use the = operator by itself in the condition. Usually, the value will be 1.

What's the password?
* [? HAS_PASSWORD = 1] [#act] (Neutral) (Say the password.) -> get_in
* (Nervous) Uh, open sesame? -> get_out


A Cost Gate works similarly to a Requirement Check, but deducts the value of the condition rather than merely making sure the player has it. Cost gate syntax follows the same rules as other conditions, but adds a minus sign - to the right of the question mark.

That'll be fifty bucks for the jewel
* [?- MONEY 50] Done and done. -> buy_jewel
* Whoa, too rich for my blood. -> drop_bill

The syntax [?- Coin 5] is equivalent to [? Coin 5] [- Coin 5]


Premium gates are a special version of cost gates that always use a special variable called $gem (the premium currency of Tales). Because we want players to always have access to choices they've paid for during replays, we also need to mark these options with a unique identifier similar to a label: [:unique_identifier].

You joining us in the limo tonight or what?
* [:joined_limo] [?- $gem 25] (Happy) Count me in! -> what_in
* (Sad) Sorry, I can't. -> what_cant

In-Line Conditions (Conditional Text Display)

If a check is placed on a line of dialogue, that line of dialogue will only trigger if the condition is met. Below is an example where the PLAYER has been collecting Chickens for FARMER:

'Ere's those lost chickens you asked for, sir!

[? chicken > 3]
You've brought too many. At least one of these isn't mine!

[? chicken < 3]
Don't come back until you have all of them. You don't get partial credit, here.

[? chicken = 3]
My babies! My beautiful feathered babies!

Note: FARMER will only have 1 response here. If the Condition is false, the following dialogue line will not display.

Let's try another example with a variable that is more abstract. Assume that the player either gained talked_mom while talking to his mother, or didn't.

But Mom said--

[? talked_mom]
I KNOW what she said, okay?

[? talked_mom]
Then you know we can't go there!

[?~ talked_mom]
Mom said something?

[?~ talked_mom]
Yes! She said we can't go there!

Well, I'm going anyway.

If the player talked to his mother (talked_mom), the player would see the following:

  • KELLY: But Mom said--
  • MIKE: I KNOW what she said, okay?
  • KELLY: Then you know we can't go there!
  • MIKE: Well, I'm going anyway.

If the player did not talk to his mother, the player would see the following:

  • KELLY: But Mom said--
  • MIKE: Mom said something?
  • KELLY: Yes! She said we can't go there!
  • MIKE: Well, I'm going anyway.

Conditional Navigation

Sometimes you need to do multiple lines or entire choice branches behind a condition. Adding a condition to each line of dialogue in this situation would be an unmanageable hassle. While choices depend on player input, you can also navigate the player automatically based on their previous decisions. This style of navigation is not shown to the player.

A conditional navigation point is set up similarly to a choice, but unlike choices, conditional navigation:

  • Is not attached to a prompt (otherwise it would be a choice)
  • Has no spoken line components (such as Actors, emotions, and dialogue).
  • Can have more than two options.
  • Must conclude with a unconditional option.
  • Options are assessed in order, from top to bottom. The first time a condition is met, its corresponding jump is activated.
* [? gold >= 5] -> honeymoon_suite
* [? gold >= 1] -> regular_room
* [? manager_favor] -> small_closet
* ->

Looks like I'm out on the street tonight. Hope it doesn't rain.

In the above example, Tony is trying to get a room for the night:

  • If he has five or more of the variable gold, he jumps to a label called honeymoon_suite.
  • If he failed the first condition, the computer checks if he meets the next one. Any value of gold will jump him to regular_room.
  • If he has no gold, the computer check if he has any value of a different variable, manager_favor. If so, he jumps to small_closet.
  • If he failed all conditions, he automatically falls through to the content directly beneath the conditional navigation point and says, Looks like I'm out on the street tonight. Hope it doesn't rain.

Note that if Tony had 5 gold and manager_favor, he would navigate to honeymoon_suite and not small_closet. That's because conditions are assessed in order, top to bottom.

Remember, you can use any type of condition to check against for purposes of navigation:

* [? red_stone = 0] -> red_section
* [? blue_stone > 3] -> blue_section
* [? yellow_stone] -> yellow_section
* [? green_stone >= 1] -> green_section
* [? black_stone] -> black_section
* ->

We simplified our current Choice UI to have only 2 options. To get around this limitation, you can using Conditional Navigation right before a Choice Option to get more than 2 options:

* [? sword] -> stab_option
* ->

Let's do this thing.
* [#act] (Neutral) (Raise your fists.) -> fist_fight 
* [#act] (Neutral) (Run away.) -> run_fight 


Let's do this thing.
* [#act] (Neutral) (Raise your sword.) -> sword_fight 
* [#act] (Neutral) (Run away.) -> run_fight

In the example above, the player never sees a sword gate if they never found the sword. This sort of trick can be useful when:

  • You don't want to spoil potential other options for the player.
  • You want it to feel like both options are valid.
  • Normal gated options imply that the better option is behind the gate.

Variable Comparisons

For scenarios that require determining which variable is bigger, a slightly more advanced combination of the techniques outlined above may be used.

Comparing "Opposite" Variables

This technique only works when you're tracking two opposing sides of a single spectrum, such as "morality" (where one end may be "good" and the other "evil") or "health" (where one end may "healthy" and the other "injured"). The goal is to see which end the player hit more often, and give them an appropriate consequence.

In these cases, we don't track the ends ("good" and "evil"), we only track the spectrum ("morality").

To start, we give "morality" a value over 0. This let's the player go down in the spectrum, something that would be impossible if we started at zero. (Remember: variables cannot go below zero. If you subtract 500 from a variable at 1, the player still has zero, not -499). [+ morality 100]

Now, any time the player does something evil, we subtract a numerical value. For this case, let's say 1 for sort of evil, 5 for evil, and 10 for very evil. [- morality 10]

Any time the player does something good, we add to the variable. To make it symmetrical, 1 for sort of good, 5 for good, and 10 for very good. [+ morality 10]

When it comes time to decide if the player is more evil or more good, we simply look at if morality is above, below, or equal to its starting point (in this case, that's 100) using Conditional Navigation.

Let's see here…

* [? morality = 100] -> go_limbo
* [? morality > 100 -> go_heaven
* ->

To hell with you!


You are neither good nor evil. To limbo!


What a good boy! To heaven you go!

Note: In the above example, not meeting the other conditions sent the player to hell, since if morality wasn't exactly 100 and wasn't above 100, then we know it must be below 100. And in this example, that means evil.

Comparing "Unconnected" Variables

If you want to compare variables that don't exist on the same spectrum (i.e. compare the player's inventory of apples and oranges), things get a bit more complicated than other methods in this guide. For purposes of keeping this guide simple, you'll want to just copy and paste this syntax into your script and replace the components with your own variables:


* [? FRUITCOMPARE > 1] -> more_apples
* [? FRUITCOMPARE = 1] -> same_fruit
* -> more_oranges

In the above example, we're comparing the player's APPLE inventory and ORANGE inventory.

  • FRUITCOMPARE is a new variable identifier that is being created for the first time here exclusively for the purposes of this equation. Name it anything you want (remembering the rules of unique identifiers).
  • APPLE is a variable that the player collected throughout the story.
  • ORANGE is a variable that the player collected throughout the story.
  • If the player has more APPLE than ORANGE, they are navigated to the more_apples label.
  • If the player has the same number of APPLE and ORANGE, they are navigated to the same_fruit label.
  • If the player has more ORANGE than APPLE , they are navigated to the more_oranges label.

Story Conclusion

Story concluding screens will show up to 3 different sections:

  1. Story Ending
  2. Key Decisions
  3. Scored Variables


  • Each player can receive an different ending that summarizes what happened.
  • You should always define at least 1 ending, that way the computer will know when the story is completed.

Initializing the Endings

At the Header, place the following text:

| Ends   | END01    | Title | ImagePath |        | Ending Description
| Ends   | END02    | Title | ImagePath |        | Ending Description
| Ends   | END03    | Title | ImagePath |        | Ending Description
  • Identifier: END01, END02 are unique identifiers. They can be renamed from our example but these should stay short.
  • Title: 37 characters max.
  • Ending Description: 235 characters max.
  • ImagePath: Leave blank for now, we'll fill that out for you.

Ending the story

  • Simply place the unique id for the ending (End END01) when you want the story to go to the ending screen.
  • If the Ending has no ImagePath, it will display the Story Cover instead

Key Decisions

Many choices in an episode are merely for roleplay and to change a few lines of dialogue here and there. Others alter the story drastically, either narratively or through intensive branching. In these instances, we can add a line of code to mark the decision as key, allowing us to display it to the player at a later time, and compare their choice against the community's.

Paths Header

  • Each key decision question needs to have a unique id (e.g. D01)
  • Each answer needs to have a unique id that starts with the question followed by a space then a unique id for the answer.
  • The answer ids only need to be unique across their own question, not to the whole header (you can have D01 Y and D02 Y)
    | Paths | D01               | What did you do to Marcus?
    |       | D01 killed_marcus | You killed Marcus
    |       | D01 spared_marcus | You spared Marcus

Decision Points

Mark decisions by adding (Decide D## Identifier) to its own line within the label of the choice you want to track, where the identifier is unique to the decision and ## is the number of the choice (usually 01 or 02).

You hold the blade against your enemy's throat. 

Please! Mercy! 
* [#act] (Neutral) (Draw it across his neck.) -> please_neck 
* [#act] (Neutral) (Show mercy.) -> please_mercy 


(Decide D01 killed_marcus) 

NARRATOR  You draw the blade across his neck, killing him instantly.

-> please_knit 


(Decide D01 spared_marcus) 

You lower your blade. 

-> please_knit

Goal Tracking

This section shows the major goals that you have laid out for the player. It helps provide them feedback on whether they played well and gives players an opportunity to replay the Episode if they aren't happy with the results.

In order for a score to appear at the end, it must be in the tracking list and have a range set either by the | Score | header field or the (Range) direction. The player's final value will be compared with the low and high values in the range and displayed as bar showing how the player places. If the difference between low and high is 10 or less, visible divisions will show along the bar allowing the player to count.