***WARNING***
I originally created this tutorial as a guide to getting Dialogue Designer exports into C3 projects. I did this as I was using the program in my own game (Bilkins' Folly). However, after working on my project for three years, and implementing close to 70,000 words of dialogue using DD, my advice to anyone thinking about using this tool is TO FIND SOMETHING ELSE!!!
Unfortunately, working with larger dialogue trees in DD creates multiple issues that won't be noticeable at first. The program has a tendency to corrupt links between nodes which only appear in the export builds (I believe this is a result of duplicating nodes rather than creating new ones) and running the program in the background can lead to it spawning in nodes and corrupting others. It's truly the stuff of nightmares when you need to go into an old dialogue file to change 1 line only to discover that the program has just corrupted 30% of the the nodes and requires each one be relinked. Additionally, if you have a lot of nodes, the whole program slows down to an unworkable degree (using a Ryzen 7 5800X). If you have a character that has a lot of dialogue... well, good luck...
This is compounded by the fact that the developer - radmatt - has seemingly abandoned the project and won't reply to support requests.
So again, my suggestion is DO NOT USE DIALOGUE DESIGNER!
There are other tools out there that can be used to create branching dialogue. I would strongly suggest you pick something else instead. If I had to do it over again, I'd probably look at something like Twine. I'm active in the Construct Discord if anyone wants to reach out and discuss this further, my handle is LukeW
*** END WARNING ***
This project will take an exported JSON from Dialogue Designer (DD) and parse it into Construct 3.
Note that this project file was designed for my game specifically, so it's very much tailored to an adventure game style of dialogue. However, I got frustrated by the lack of example support for DD and thought to upload my own for anyone else struggling. If you don't have an understanding of how JSON files are structured then I'd suggest reading up on them first. I also spent a fair amount of time reading through the excellent tutorials that Laura has posted on the Construct 3 tutorials website, and would highly recommend reading through them if you plan to make a dialogue-heavy game.
If you find a bug in this project, or think something can be done better, then I'd love to see it posted on the C3 forum or commented here.
*Note* DD files have to be exported before they can be loaded.
Also, I've noticed a bug with DD. Sometimes it won't set the START node to be the first node in the array when exporting. In that case, you will either have to manually move it to the first entry, or change the event sheet so that it scans for the START node and starts from there.
For the sake of readability, I’ve run the exported JSON file through a JSON beautifier – I use this one: jsonformatter.curiousconcept.com
Alternatively, you can use the beautifier that's built into the Construct editor. Just copy the text into your JSON file and then press right mouse -> beautify.
To allow for better ordering, the structure of my JSON file is broken down into game location and character arrays. So the hierarchy follows:
location -> characterID -> nodes
Note that DD only creates the nodes array, so the parent arrays have been created manually, and the exported DD JSON needs to be inserted into the characterID array (You will have to delete the square brackets from the exported JSON and also add a comma at the end of the nodes array unless it's the last entry in that characterID path).
The 'slide_camera' boolean variable is not mentioned in the DD manual. However, it's useful to be able to have a boolean check in the nodes. Currently, I'm using that to test whether the talking character has a standard talking animation or not.
Regarding longer text lines, I'm using "|" as a token to split them up and playing them in order. This saves the user having to write an individual node every time a line changes, and can instead write long passages in one node.
With the condition branches and setting variables in dialogue, I currently only have it set up for boolean. Will update this project later on when I get round to adding string and number checks.
The questComplete object can store a string and change the dialogue variable. When storing the string, add the entire line, including locations, as this may want to be called from a different game location.
^ I swear it's not usually this messy!
The execute code blocks are useful for controlling animations. Using tokenAt() with spaces, you can set different commands that get carried out.
For example, 'animate NPCanneMcGuff drinking' - will identify 3 elements. First, 'animate' tells us that we want to change a character's animation, then the second field selects that object from the npc's family, and finally the last entry tells the game what animation to play.
After using the animate block, you can add 'waitForAnimation NPCanneMcGuff' and the dialogue won't proceed until Anne finishes her current animation. Alternatively, a wait block will also work. Just note that if slide_camera is not checked on the next message, that character will stay in the last set animation (useful if you want different types of talking, such as percy talking to the camera).
With dialogue choices, you may need to add a scroll function if you plan to have a lot of answers for the player to select from. That is outside the current scope of this project.