How it works

ADS Dialog System is based on centralized conversation management. The system keeps dialogs, their state, and their flow in one management point, then makes them available to the whole project.

Centralized management

The system is managed by a Game Instance Subsystem. It is created with the game and remains available throughout the session. This allows your Blueprints and game logic to access conversations from one place, without placing a dialog manager in every level or on every Actor.

Conversations in dedicated assets

Each conversation is defined in its own asset. This asset contains the information needed for the dialog: its mode, lines, choices, and the elements that accompany its playback.

Your game can enable or disable these assets according to progression. When a conversation is available and triggered, the system simply reads the corresponding asset.

Each speaker must be represented by an Actor that has the AC_ADS_Dialog component. This component must be added, linked to the relevant Actor, and configured so the system can correctly identify the speaker during the conversation.

Playing a conversation

The system uses the mode selected in the asset: Classic for an exchange shown in the dialog interface, or Travel for a dialog that accompanies the player while they move.

It then presents lines in the planned order. Each line can adapt the experience: change the camera, use a particular bubble, display rich text, or trigger an event. Variables and functions also allow text to reflect current game information.

The player advances through the conversation manually or automatically, can skip it when allowed, and can make choices. Choices let the conversation follow the path defined by your content.

Return to your game

When a conversation ends, the system closes its presentation and lets your project apply the intended consequences: progression, a newly available conversation, a quest update, or any other gameplay change.