Hi Tony,
We are getting a lot out of the dialogue system. However, currently we have to make sure that only one person on the team is working on conversations at a time so we don't end up overriding each other's work. I vaguely recall seeing a post about setting up multiple databases to allow for multiple people to edit dialogue, but for the life of me I can't find it.
Is the best practice for having multiple editors to have one "core" database then have each user make a duplicate of the "core" database then merge the individual databases back into the core database when they are ready to commit?
Best Practices for Dialogue System Version Control
-
- Posts: 14
- Joined: Mon Nov 27, 2023 8:28 pm
Re: Best Practices for Dialogue System Version Control
Hi,
Here's the link: Working With Multiple Databases
The general process is:
Here's the link: Working With Multiple Databases
The general process is:
- Create a "core" database with data that all of your writers will share -- typically the actors, quests, and variables in your game. Assign it to the Dialogue Manager GameObject's Initial Database field.
- For each writer, create a separate database.
- For each of the Dialogue Editor sections whose data will come from the core database, select Menu > Sync From DB and specify the core database.
- On the Dialogue Editor's Database tab, set the Base ID to high numbers such as 1000 for the first writer, 2000 for the second writer, etc. When the writer creates a new conversation (or whatever type of data), it will start its internal ID values at the Base ID and increment from there. This helps prevent internal ID conflicts among the databases.
- Add an Extra Databases component to the Dialogue Manager. Assign the writers' databases to it. At runtime, the Dialogue System will merge the Initial Database and all the extra databases into one big in-memory database that it will use during play.
-
- Posts: 14
- Joined: Mon Nov 27, 2023 8:28 pm
Re: Best Practices for Dialogue System Version Control
Hi Tony,
Thanks this is a better solution than I had in mind.
I do have some questions with the "Unique ID Tool." It would be inconvenient for me to run that throughout the project as I have LUA code in conversations that retrieves conversation attributes from other conversations. I believe that requires me to use the convo's unique ID to reference.
For example, before a battle I have a "reward offered" convo attribute that gets set via LUA code.
Then when the player returns from battle, the character gives them the reward and uses the GetConversationField with the initial convo's ID to tell them how much money they are being rewarded.
Therefore when I run the Unique ID Tool, I think a lot of my connections would break.
Would the best solution to this be to just set the base ID's of the separate databases to be very far apart from eachother and to not use the UniqueID Tool? From what I can tell the ID's are produced sequentially from the base, so if I set the base ID's to be 10,000 apart, one of us would have to make over 10,000 convos in order to risk overlap correct?
Thanks this is a better solution than I had in mind.
I do have some questions with the "Unique ID Tool." It would be inconvenient for me to run that throughout the project as I have LUA code in conversations that retrieves conversation attributes from other conversations. I believe that requires me to use the convo's unique ID to reference.
For example, before a battle I have a "reward offered" convo attribute that gets set via LUA code.
Then when the player returns from battle, the character gives them the reward and uses the GetConversationField with the initial convo's ID to tell them how much money they are being rewarded.
Therefore when I run the Unique ID Tool, I think a lot of my connections would break.
Would the best solution to this be to just set the base ID's of the separate databases to be very far apart from eachother and to not use the UniqueID Tool? From what I can tell the ID's are produced sequentially from the base, so if I set the base ID's to be 10,000 apart, one of us would have to make over 10,000 convos in order to risk overlap correct?
Re: Best Practices for Dialogue System Version Control
Hi,
Yes, that's the best approach. Set your Base IDs in multiples of 10,000. Then you should never need to use the Unique ID Tool.
Yes, that's the best approach. Set your Base IDs in multiples of 10,000. Then you should never need to use the Unique ID Tool.
-
- Posts: 14
- Joined: Mon Nov 27, 2023 8:28 pm