This plugin is an old school dialog system based on topic. It is inspired in its look and feel from the dialog system of Morrowind. It also includes a basic quest system, with a simple quest journal.

The two are linked together because of the way quest progression is tied to dialog topics and dialog topics can be tied to quest condition. However, the dialog system is totally standalone and does not need the quest to work as intended.

Its underlying philosophy is to be replicated on a dedicated server environment and keep as much information as possible on the server side.

I will fix bug and update the project whenever its parent project is updated.

Demo project contains a very basic setup of the capabilities of the dialog and quest system. There are three Cube actor that all share the same meta dialog bundle. However, on each of these actors, the relationship level toward the player is different. One will straight refuse to talk to the player. Another one will have the standard dialog options. The third one will also display one special dialog line that is available because of the high relation.

Dialogs and quests are defined the dirty way within the GameMode. Dialogs and quests are not destined to be written this way but are instead supposed to be loaded from a database.

Upon player spawn, a new quest will automatically be given to the player, asking him to go through 3 different areas of the world map, in a particular order. These areas are limited by the red boxes. Player is expected to follow direction from the quest journal to go on the highest, lowest and middle altitude box in order to complete the quest.

A Quest giver NPC is located on the right and will provide player with a new quest, in which he must go talk to another quest giver NPC and then come back to the first one.

The dialog system is based on a topic list that an actor can discuss with the player.

The dialog system is centered around the idea of discussion topics. These topics are keyword that will trigger a discussion to convey information from the actor to the player. Dynamic links appear in the dialog text to brought up new topics, but can also be brought up using a global list of possible topics.

Topic can be anything discussable between an actor and the player, for instance information about the surrounding city, direction, information about another character, the weather, a quest...

A dialog bundle is a collection of several topics that are meant to be shared by various similar actors. For instance, it would be possible for all actors within the same village to discuss the same topics related to the village itself.

This would mean that a dialog bundle regarding this village could for example contains : Market, Bakery, Services, Town guards, Blacksmith...

Some other bundle could contains topics related to a particular actor belonging to a job, such as a Baker could talk about : Bread, wheat, muffin, high price of flour...

Some bundle can also be specific to a single character. For instance a quest giver will have its own bundle, not destined to be shared with other actors, containing topics related to his quest.

The meta dialog bundle is simply a bundle of dialog bundle. This is the part that get assigned to an actor. Its purpose if to give a set of topic that is modular and could contain different bundle such as, to refer to previous example : Village location bundle, Baker dialog bundle.

Another near NPC could have as a meta bundle : Village location bundle and a quest bundle.

Actor that implement dialog must hve a way to compute a relation value relative to the player. This relation value is displayed on the top right corner of the dialog window. Having different relation with Actor can lead to different outcome regarding dialog. For instance, an actor that hates the player may refuse to talk to him at all. On the other end of the spectrum, specific dialog topics may only be brought up if the actor is close enough to the player. This concept is linked both to the meta bundle, where a minimum relation can be required to talk to the actor at all, and on the topic level, where the topic can only be activated/displayed when a certain relation condition is met. Quests may also be a condition to trigger dialog topic and will be covered on the Quest part.

There are 2 main interfaces and 2 actor component related to the dialog system. Each go as a pair and we will only consider the actor component, but the key idea is that an actor having the component should also implement the interface. Another interface (IDialogDisplayInterface) is only related to displaying the UI.

This is an actor component and interface that should be implemented by the game mode to handle dialog mastering. The interface is just a getter for the DialogMainComponent

The DialogMainComponent contains lookup tables and data for all the dialog topic, bundle and meta bundle. It also contains a set of helper functions to fetch needed data. As this part is intended to be only defined on the GameMode, it is build to exist only on the server side.

During the GameMode initialization, you are expected to fill up the data table regarding the dialog. This was designed to load dialog data from a database upon server launch, but loading from a local data table should also be possible.

This actor component/Interface pair is meant to be added to actors that can trigger a dialog. The interface require to redefine a minimal amount of functions, related to relationship of actor toward the player and a simple getter for the component.

See DialogActor in the demo project for a use example.

This component contains the dialog data and the lookup tables concerning one particular actor. This component will be replicated with the actor, embedding all its dialog data.

This interface is meant to handle several signals from the game to reflect on the dialog window. It can be implemented in blueprint and is destined to the player controller.

The quest system is a basic list of tasks, that must be completed in order to progress. It is closely related to the dialog system, and contains a quest journal for tracking purpose. This quest system is independent of the dialog system, and can be used in a standalone fashion.

The proposed quest system is a simple progress tracking method. It relies on interaction with actors to progress from one step to the next. This also mean that there is currently no way to handle "kill X/Y actors", but would rather focus on discussing with an actor, or clicking/colliding with an actor to progress one step further in the quest.

A quest is a set of different steps that must be performed and validated in order to progress along the quest. It is identified by a unique ID, contains a title and can repeatable (eg. bringing an enemy ear will yield a certain amount of money).

A quest step is a sub part of a quest, it is the smallest possible doable element of a quest. For instance it can be, fetch an object, turn on the light, go somewhere, talk to someone... It contains a reference to its parent quest ID, a title and a description (for journal logging purpose) and a boolean flag to define if it is the final step of the current quest.

Quest steps and quest data are available on the player side containing also data to track the progress. For a given quest a progress id will be kept by the player and the previously done steps will also be stored.

It is possible to create a quest that need another quest to be performed before. It can be easily put in place by adding a condition related to the previous quest last step.

As with the dialog data, the quest information structure contains both an interface and a component.

The QuestBearer Interface and Component set represent the data needed for a player to store and progress through quests. It contains functions that can be called either from client side or server side to allow the player to progress through a given quest or to add quest data to its knowledge.

Most of the function are already defined and only the functions returning the QuestBearerComponent need to be overriden.

Quest allowing progress from the client side need to be coupled with a validating actor implementing QuestGiverInterface in order to validate that the progress is possible.

The quest giver interface is meant to be added to each actor capable of making the player advance in a quest or give new quest. This is the case for NPC that can advance the quest through dialog, but is also the case for Actor validating quest upon interaction.