Characters

Characters are one of the main resource types of Arrow.

They are consisted of a name, a color label, and unlimited number of very useful dynamic tags.

Characters come with following notable super powers:

• They can be referenced by nodes (and are by the official ones). This means we can locate every resource that somehow relates to a character, including Dialog and Monolog nodes.

• Their even more exciting power is in their tags. These are collections of key:value data that can be both managed initially (from the Inspector panel) and dynamically at runtime. Tags can also be exposed in many textual nodes including Content and Interaction nodes, in form of {character_name.tag_key}.

To create a Character or edit its data such as tags, switch to the respective tab in the Inspector panel.

You may need to use arrow buttons on the top-right corner of the panel to move the tab into view.

Tags

Tags are designed to be simple in implementation but highly flexible and dynamic. They are key:value (all String) collections of data that every character owns.

Tags are not independent resources. They do not have a UID and exist only as key:value entities under a character's tag collection/dictionary.

Although globally accessible, unlike Variables that are designed to be initialized, have a static known type, and always exist, tags has only one value type (Str) and more importantly are managed dynamically at runtime (even if pre-set or initialized). In other words, tags can get undefined. This means that you should be careful when you remove a tag, specially if they are supposed to be exposed somewhere in a node with textual content.

Powers & Uses

• Dynamic event management using Tag-Pass and Tag-Edit nodes

  Tags can be used as dynamically set flags or criteria for event-management.

  One very common scenario in game narrative design is when you want an event to be played conditionally. For such cases you could always use variables; but when the number of criteria is considerably large, defining and managing many variables may be cumbersome. It is easier to define and manage such events with character tags; added, removed, or manipulated using Tag-Edit and checked via Tag-Pass nodes.

  For more information and examples, check documentation on the mentioned nodes.

• Data encapsulation and parsing

  In earlier Arrow versions we only had Variables to keep game data and expose them as text. It would mean that to manage many related data you had to create many variables. The process and result wasn't necessarily neat and beautiful.

  We can now create a character (or non-character data objects by overusing them) and manage data there with key: value tags. These tags can be exposed in textual nodes (where supported) using mustache placeholders resembling {character_name.tag_key}.

  Common use for this feature is to assign data such as name, alias, age, superpower, vehicle, etc. to characters and use them anywhere those values are needed. Then we will only need to update a tag's value to have them all updated, if any edit is required, even in runtime.

  We can manipulate tags with Tag-Edit nodes.

  Tags only support String (text) keys and values, for other data types Variables offer more advantages.

  Trick!
  Currently we support parsing {variable}s inside tag values as well; yet such use is not recommended, not tracked by editor, and has no standard or conventional runtime behavior.

• Usage tracking, referencing and citation

  Characters panel of inspector has a locate functionality that tracks all nodes using a character or a tag (mustache placeholder) belonging to that character in their content.

  These are sorted by the time a reference is made.

  This feature comes with some creative uses:

  • Locating

    Imagine you want to locate nodes that are about a character named Hero, but you do not want to exactly expose any special tag (even {Hero.name}) in them. You can create a tag for Hero with the _ key (or any other convention you prefer), and no text (i.e. blank string) value, then use it in that node's exposure-supporting fields. For example put {Hero._} with blank value at the end of a Content node. If the node supports exposure, no text will be there (remember blank value), but it would be tracked by the character inspector's locate function.

    That tag can be queried using global text search for Hero._ (from status bar) as well.

  • Categorizing

    Alternatively you can use value-less (blank) tags with any arbitrary keys to categorize textual nodes. For example you can create blank tags such as {Hero._love_affair}, {Hero._nightmares}, {Hero._battles} to categorize different Content, Dialog, Interaction, etc. These tags won't print any text to player, but can be located and even better queried using global text search (from status bar.)

    Another general way to categorize and locate nodes is to put category badges (with any preferred format such as [battle-scene]) in their node notes and query them using the global text search.

    See also Project Organization

Ethics!

With great [dynamic] power comes great responsibility

Undefined tags (including tags with no or invalid key e.g. {Hero.}) can be exposed in many nodes, so be referenced and located by the inspector. But unless created/defined at runtime or later in the inspector, they will be printed as the placeholder text they are, not as values (because there is no real value).

This is the artist/dev's responsibility to make sure that exposed tags do exist in memory, whenever they are needed.

One generally good practice is to use placeholders, only for pre-set tags (initialized in the editor) and never unset or remove them in runtime.

On the other hand, dynamically created (and removed) tags can be used for event management as described above.