Text Boxes - Part 2
It took a couple days, but I have text boxes working (if wildly unfinished) in Echodream. They’re deceptively complicated – I almost went back on my original plan of using the menu system, but I didn’t. Again, the menus are really just polymorphic state managers, so they’re well-suited for dialogue tree traversal.
I realized that I knew what I wanted the editor panel to look like, and I knew how to implement the dialogue tree with the menu system, but I was stuck trying to figure out how to go from one to the other. I really can’t think of an especially elegant way to store the data, stemming from the number of edge cases that text boxes have. (The player might have to choose a response, in which case there might be branching; an event might trigger when you reach the end, but an event might also trigger based on user input in the middle of the dialogue tree; etc.) Ultimately, I condensed the text blocks into six pieces of data:
The flags are mostly to make the editor interface more usable (otherwise, you could just check whether the corresponding strings are empty). Each instance contains data for a node in the dialogue tree (as well as the “choice” in the parent block to select the node). Most nodes contain a text block, but a leaf could simply trigger an event and close the text box. I actually had to backpedal here, but initially nodes could either be text blocks or event triggers, but not both. That’s not a restriction I’d want to live with (it’s possible you’d want an event to trigger in the middle of dialogue), so I had to figure out a way to handle both:
AddChild() adds an "interaction" to a node that traverses the dialogue tree and triggers an event if there is a key provided
AddEvent adds an "interaction" that triggers an event and closes the text block (often events trigger at the end of dialogue, like Pokemon trainer battles)
Again, it’s not the most elegant or intuitive system ever, but it handles all the cases I want in a few hundred lines of code, and it’s readable (to me, anyway, and I’m the one that has to work with it). Most importantly, the data can be written from an inspector panel:
It might not be readily apparent from the screenshot, but everything is working as intended here
It might not be readily apparent from the screenshot, but everything is working as intended here
It’s far from a commercial level of polish, but you can pretty easily build and edit dialogue trees through here if you know how it works (and at the moment, I’m its only user). This finally forced me to come up with a solution to a mistake I made in the editor.
​
The way I implemented the Inspector window, the panels could only be static. Unlike ImGui, my GUI system has static window layouts (they aren’t rebuilt every frame). Editor windows have dynamic layouts through their Update functions (you can change window layouts; they’re just not recalculated every frame). Inspector panels, however, were just built once – there was no Update code associated with them.
​
I really didn’t want to be stuck with a static layout for the dialogue tree editor panel. At the very least, I wanted that dialogue box to resize with the window. So, I added an action list to the inspector (I didn’t call it that, but technically I believe that’s what it is):
Inspector window's Update() function now includes an action list for dynamic inspector panels
It might be sort of an ad hoc solution, but anything else would involve major engine refactoring, and I don’t want to do that in the middle of a game project. It might not be that bad anyway – the client now has the option to provide an update function with their inspector panel code:
Text Box behavior tree node adding an action to the Inspector window's action list using a lambda function
As long as I manage the action list properly (always make sure it’s cleared before it causes a crash), this might be a valid long-term solution.