Table of Contents

Processor Types

In the dialogue system, there a 3 distinct processor types, namely:

  1. The Dialogue Processor
  2. The Dialogue Pre Processor
  3. The Dialogue Post Processor

The Dialogue Processor

The dialogue processor is responsible for the processing of a specific node. This type of processor always has an equivalent node.

The Dialogue Pre/Post Processor

The processors are called before or after the the dialogue processor above depending on their type. They do not have an equivalent node.

Pre processors are used to edit data before is it passed to the relevant processor. Post processors are used generally for logging such as a text log for all conversation nodes. They are used to separate concerns from the actual processor than simply does its relevant processing task rather than worrying about pre/post process logic.

Creating A Pre/Post Processor

Pre/Post Processors need to inherit from DialoguePreProcessor<T> or DialoguePostProcessor<T> respectively, where T is type of data that will be pre/post processed.

Tip

T is called for all derived types. As such, global pre/post processors can be made by setting T to DialogueNodeData

Pre/post processors have a priority value which determines the order in which they are executed; lowest is executed first.

To use a pre/post processor implement to appropriate protected abstract void PreProcess(T nodeData, DialogueDirector director); or protected abstract void PostProcess(T nodeData, DialogueDirector director);.

public class MyPreProcessor : DialoguePreProcessor<ConversationNodeData>
{
    public override int Priority => 5;
    protected override void PreProcess(ConversationNodeData nodeData, DialogueDirector director)
    {
        Debug.Log("Hello world from pre processor for the conversation node with text: " + nodeData.text);
    }
}

Singleton Processors

Processors that do not hold per-dialogue mutable state may be marked with the [Singleton] attribute to avoid manually adding an instance to a director's hierarchy.

A single shared instance is created once per domain reload and reused by all directors: MonoBehaviour processors are added as a component to a dedicated GameObject in the scene; non-MonoBehaviour processors are instantiated directly.

All 3 processor types may be registered as a singleton processor.

Warning

Because the instance is shared across all directors and dialogues simultaneously, any mutable per-dialogue data must be threaded through DialogueNodeData rather than stored on the processor itself.

Note

While the runtime provisioner is technically a dialogue processor in how it operates, it is considered a pre-processor since calls to it are dispatched from a utility pre-processor. As such, runtime provisioners may also be used as singleton processors provided the invariants above are met

Edit this page