How To Use Multiple Dialogue Databases

Table of Contents

The Dialogue System is designed to work with a single dialogue database or multiple dialogue databases. Multiple databases require more management on your part to keep track of and to load in and out of memory as appropriate, but they can be useful to split up your content either for organization or to reduce the amount of content loaded into memory at any given time.

Deciding Between Single Or Multiple Databases

Here are some guidelines for deciding between using a single database or multiple databases:

  • A dialogue database with 1000 average-length conversations uses about 15 MB of memory, or the equivalent of a handful of texture files.
  • If you're making a desktop game, 15 MB shouldn't be a concern. In this case, the only reason to use multiple databases is for your organizational benefit.
  • If you're building for low-end mobile devices, 15 MB might be too much, but ultimately it depends on your specs and requirements.
  • You may want to use multiple databases if:
    • A single database is larger than the memory budget you're willing to dedicate, or
    • Your database has so many different assets that you need to split it up for organizational reasons.

Whether you use a single database or multiple, remember that you can use forward slashes in conversation titles to group your conversations. For example, you could title your conversations:

  • Companions/Robot Butler/At Your Service
  • Companions/Robot Butler/Malfunction
  • Desert/Scavenger
  • Desert/Scorpion Herder
  • Jungle/Shaman, etc.

This will group them into submenus "Companions", "Desert", and "Jungle" in the Dialogue Editor, making it much easier to select conversations. The "Companions" submenu will have a sub-submenu for "Robot Butler".

Tips for Multiple Databases

If you decide to use multiple databases, put all of your global data in a global database, and assign this as the Dialogue Manager's Initial Database. This should include everything that needs to be in a saved game or accessible regardless of location, such as:

  • The Player actor and all actors that can cross locations, such as companions who follow the player around
  • Quests
  • Global variables
  • Conversations that can play regardless of where the player is, such as companion chatter

In your other databases, use Sync From DB to sync in the global data content. (See Syncing Assets From Another Database.) This way you can reference global data in any database in the Dialogue Editor.

When to Use the Unique ID Tool

You may or may not need to use the Unique ID Tool. Every dialogue database asset loaded into memory needs a unique ID for that asset type – for example, every actor should have a unique actor ID. If you use Sync From DB, then new assets will be assigned IDs that are different from the global assets' IDs, so you don't need to worry about unique IDs.

However, it's entirely possible that your Desert database could contain IDs that overlap with IDs in your Jungle database. This might be fine, though. As long as you don't load Desert and Jungle at the same time, there won't be any ID conflicts in memory.

Dialogue Managers

Use one Dialogue Manager, typically added to your main menu scene. You can put other Dialogue Managers in your location scenes so you can test them without having to come in from the main scene. But keep in mind that in normal gameplay the Dialogue Manager from the main scene will typically carry through and destroy the "test" Dialogue Manager in your location scene.

To load extra databases into memory at runtime, use the Extra Databases component. For example, add an Extra Databases component to an empty GameObject in your Desert scene. Set the Add Trigger to On Start, and assign the Desert database. Set the Remove Trigger to On Destroy, and assign the Desert database.

<< Dialogue Database