I’m attempting to build a dialogue system at the moment that would be able to handle dialogue events as well as branches. At the moment the dialogue is quite linear and I would like to know if this is the right approach.
In the screen shot there are 5 dialogue events happening in this interaction. Everytime the player confirms it goes to the next event. However, certain events are queued until the goal is complete; in this case, the fight event occuring in Element 2. Once it is complete the interaction index goes up by 1 and resumes back into the dialogue.
Ideally I would like to have a Yes/No option in the first event. There would be two different branches based on the answer. My question is, should I go with adding in another list for dialogue trees? It would work but it could get kind of messy because it might be hard to reference once we get deep into the tree.
public enum EventType{
None,
Dialogue,
Fight,
Reward,
}
public class npcScript : MonoBehaviour
{
[Serializable]
public class Interact{
public EventType eventType;
[TextArea(5,5)]
public string text;
public List<scriptObject> items;
[B]public Interact List<scriptObject> dialogueBranch < --- Should I add this for dialogue trees?[/B]
}
public int interactIndex = 0;
}
I created a Dialogue tree in my own game, and using a List is definitely the wrong type of data structure for this kind of thing. You want to make some kind of Node Tree, and preferably a better UI to be able to edit it with. Something like this.
I actually saw this on youtube but stopped watching because of this comment:
Good tutorial, a bit fast, but nice work.
Sadly a lot of the information here is already outdated in newer versions of unity. Such is the struggle of using an experimental api I guess. You can still get this working but you might have to include some different libraries that might not have been specified in the video.
I did run into a few bugs with the Unity node editor while trying to program it (since it was experimental), but the purpose of it was just to display my data structure in a way that was easy for me to understand and edit (which it did). Even if it’s experimental and buggy, in my opinion it’s still worth using since the bugs it had (which mostly visual) wouldn’t even be in the front-end product, for my eyes only basically.
I pretty much did the same thing as @RadRedPanda by following the same tutorial and using the experimental graph view editor to make my own node based dialogue trees:
Though early into making this I realised it didn’t actually need to be restricted to just dialogue, and have plans to create nodes to interact with all manner of game level mechanics.
I also wasn’t very fond of the approach by the above tutorial. I elected to make all my nodes scriptable objects so I could take advantage of Odin Inspector by displaying the objects via an Inspector Element. Adding/Removing nodes is effectively creating and deleting scriptable objects on the fly.
It’s quite the architectural challenge, but well worth it I think for the versatility and ease of design it gives you.
Yes a node editor is the only practical way to visualize branching dialogue. Even if the final result and player experience looks simple, a network of choices is not to be underestimated.
A node editor is not an easy undertaking and understandably avoided, the data structure for branching dialogue even more so. Ready made 3rd party solutions exist, it is just a matter of finding them and seeing if they fit your criteria.
These 3rd party solutions can even be found outside of unity’s asset ecosystem, as long as they have a way of importing their data into unity for use.
Just for some context of time investment, I too went through this rite of passage of making my own dialogue node editor, but without xNode. It took 2 months to make it to a working state, and I would have continued improving it, but I’ve had to pause development for now.
@Laperen : lucky bastard! Years ago, I was tasked with my first Unity node editor in the morning for the afternoon. To stay on topic: dont forget to tell the OP to cull his nodes windows, it’s common sens but he will likely not think of it before he has a hundred nodes in his network if he is not used to it.
That’s quite an insane time frame, I am rather curious about the circumstances of that situation. My attempt was more for a hobby, hence why my time frame was far more forgiving. Even so I have been forced to re-evaluate the value of my dialogue tool being limited to unity-only use, hence the pause in development.
