Having the information about child nodes on the Dialogue Nodes

[SEEMANTA_DEBDAS]

Like what SvenBTB asked, I think the Dialogue Nodes should have information about their respective child nodes rather than having the Dialogue store that information in a dictionary. Can you elaborate on how deleting nodes would be an issue if we had the child info on the nodes rather than on Dialogue?

Also, I was following KiwiCoder’s tutorial on creating a Behaviour Tree Editor. In that, I think he used scriptable objects to store the data of individual nodes. Would that help linking one node to another, rather than using stringIDs?

Thank you

[Brian_Trotter]

Each node is, in fact, a ScriptableObject, but we’re storing those ScriptableObjects within the greater DialogueNode scriptableObject.

Can you elaborate on what information you think a parent node would need about the child node that it can’t already access by retrieving the node from the NodeLookup? I may be able to make a more informed redesign this way.

[SEEMANTA_DEBDAS]

Hi Brian,

When I asked the question, each node was a pure C# class. I just realized that in a later lecture, they changed that to Scriptable Object.

As for the lookup table, I was confused as to why the Dialogue.cs has the nodesLookup variable and GetAllChildren method. The Dialogue class should have the responsibility for that. Maybe I’m just overthinking it.

My idea was that DialogueNode should be a scriptable object and it should have a list of DialogueNodes which represent its children. Isn’t that better than storing it as a list of string UIDs?

[Brian_Trotter]

There are two reasons for the way we have the architecture now:

• Dictionary access is FAST. This matters a lot in the DialogueEditor.
• Just like nodes can have more than one child, Nodes can have more than one parent…