Does anyone know if there is a way that multiple people can be working on implementing quests into a game? We are currently using Git with Bitbucket for source control in Unity. Here is what we noticed.
If two people try adding a new conversation or a new quest and they both commit, there will be a merge conflict where you have to chose one or the other. However what we have found is that if a bunch of quests are added to the database prior and are left empty then multiple people can work on each individual quest. However if there are overlapping character dialogue then each person needs to be wary that they are not working in the same dialogue tree.
Is this currently the only approach to multiple people working on quests without conflicts?
Multiple People Working on Quests
Multiple People Working on Quests
Hi,
Since a dialogue database is a single ScriptableObject asset file, there's no official support for simultaneous editing. Here are a couple of safer options:
1. Use a multi-user editor such as articy:draft. It's pricey, though, especially the multi-user edition.
2. Use multiple dialogue databases:
Create a root database to hold all your common info -- actors, global variables, etc.
Create additional databases. Make sure only one person at a time edits a database. Use the Sync from DB feature to automatically copy common info from the root database to your additional databases.
Before you use the databases in-game, ensure unique IDs for all assets that will be loaded at the same time. For example, you don't want two quests with the same ID number in memory. You can use the Unique ID Tool or the Dialogue Editor's Merge feature. Or you can allocate a range of IDs for each database and make sure the designers set the ID field to numbers in that range. For example, database A could use IDs 100-199, database B could use IDs 200-299, etc.
You can then either merge the databases into one, or load them individually using DialogueManager.AddDatabase().
In very large games, you might have a common database to store global data and a separate database for each zone (planet, island, village, etc.). This way, you can load the common database and the database for the player's current zone. In a sci-fi game, if the player is on Mars, there's no need to keep Venus-specific NPCs, quests, and conversations in memory. In this case, it's also okay for the IDs in Mars and Venus to overlap, since they won't be in memory at the same time. But they should be unique from the IDs in the common database.
In practice, it's not worth the hassle of loading and unloading databases just to save memory. Tortured Hearts has over 500,000 words of dialogue and hundreds of quests, and they keep it all in memory for simplicity. But if it helps support multi-user editing, that would be a good argument to use multiple databases.
Since a dialogue database is a single ScriptableObject asset file, there's no official support for simultaneous editing. Here are a couple of safer options:
1. Use a multi-user editor such as articy:draft. It's pricey, though, especially the multi-user edition.
2. Use multiple dialogue databases:
Create a root database to hold all your common info -- actors, global variables, etc.
Create additional databases. Make sure only one person at a time edits a database. Use the Sync from DB feature to automatically copy common info from the root database to your additional databases.
Before you use the databases in-game, ensure unique IDs for all assets that will be loaded at the same time. For example, you don't want two quests with the same ID number in memory. You can use the Unique ID Tool or the Dialogue Editor's Merge feature. Or you can allocate a range of IDs for each database and make sure the designers set the ID field to numbers in that range. For example, database A could use IDs 100-199, database B could use IDs 200-299, etc.
You can then either merge the databases into one, or load them individually using DialogueManager.AddDatabase().
In very large games, you might have a common database to store global data and a separate database for each zone (planet, island, village, etc.). This way, you can load the common database and the database for the player's current zone. In a sci-fi game, if the player is on Mars, there's no need to keep Venus-specific NPCs, quests, and conversations in memory. In this case, it's also okay for the IDs in Mars and Venus to overlap, since they won't be in memory at the same time. But they should be unique from the IDs in the common database.
In practice, it's not worth the hassle of loading and unloading databases just to save memory. Tortured Hearts has over 500,000 words of dialogue and hundreds of quests, and they keep it all in memory for simplicity. But if it helps support multi-user editing, that would be a good argument to use multiple databases.