I have a struct like this
public struct Dialogues
{
public string _dialogueIndex;
public int _numOfLines;
public bool _endDialogue;
public int _gotoChoice0;
public int _gotoChoice1;
}
but I not every Dialogues would need a _gotoChoice0 if the bool _endDialogue is true. This means its unnecessary bloat to memory and inspector space.
Is there a way to create something that will give me the same data but have the flexibility to extend or reduce fields based on conditions?
Why not just have different dialogue data objects, of which your UI is designed to handle depending on what it gets given?
Admittedly I’m struggling to understand what you’re exactly trying to do with your dialogue struct here. What are the _gotoChoice int’s used for? What is the _dialogueIndex string used for? Index implies it should be a number.
I’m not sure what you mean by this? My UI system is decoupled from the dialogue system. They only communicate to display data.
Here’s an example. Two different choices led to different dialogues.
_dialogueIndex is just a name for myself to refer to. The index is the Dialogues[ ] index.
_numOfLines is the number of lines before a choice comes up.
_endDialogue → true means no choice is provided. End the convo.
_gotoChoice0/_gotoChoice1 → if _endDialogue is false then goto will goto the dialogue index.
Maybe there’s a simpler way to achieve what is shown above?
My own dialogue UI is also decoupled from anything as well. I use a pub/sub (Event Broker) pattern to send off data to it. But it has multiple methods for different kinds of data, and depending on which it receives, if the data differed from the type it previously received, it will alter its state a little and display whatever is needed.
To me dialogue is a flow of logic, which I represent with scriptable objects. There are two kinds, a standard dialogue object, and a dialogue choice object.
The standard object - at it’s core - it just some text and a reference to the next dialogue object (this can be either standard dialogue or a choice, as they inherit from the same base class), all encapsulated in a class that gets sent to the dialogue UI. When the UI receives this, it shows on screen, and waits for the player to hit confirm, and moves onto the next object.
The dialogue choice object is similar, with some text, but also a list of choices that comprise of the choice text and the next corresponding dialogue object. When the UI receives this, it expands to give more room for the options, and then shows all the options. When the player selects an option, the UI proceeds to the dialogue object corresponding to that choice.
I don’t have any flag for when dialogue should end too. Just when it reaches an object with no further referenced objects (the end of the logic), it closes the dialogue UI.
Of course all of this is probably more complicated than what you may have going on (without knowing the full extent of your dialogue system). Though at the end of your day, adding some form of state to your dialogue UI and sending different information to them might be the best place to start.
Yes that’s what I’m referring to. If the next line is also a line, there is no need for reference. I just need a reference for the last line that requires a choice. And the choices would have references too.
What you suggested is similar to a node system. A flow of logic. For this basic system I just need a reference for the last line. Marked by _endDialogue.Equals(false).
What you suggest is this? So each line has a ref to the next type. Do you just drag and drop ref yourself?
What I’m asking is if this is possible. Where I don’t care about the next ref except the last line in this dialogue group.
After explaining this, I think the answer is clear.
Like you said, maybe what I need is to create a ref in the struct, if the ref is empty, then end dialogue else use the info in the ref to do something depending on type.
Well I’m glad my rambling could help in some way!
You’re correct that I was describing a node system, which is indeed what I’ve done with my project. In fact I’ve used Unity’s experimental graph view to give myself an actual node editor window. Though I did this because I wanted/needed a robust and flexible dialogue system that could also blend in other behaviours (so it’s more just an overarching logic system rather than tied to dialogue specifically).