Repository: dialogic-godot/dialogic

Issue #45: Unhardcode everything and split behaviors into digestible scene structure
Created: 2021-02-01T16:35:23Z
Currently, Dialogic interface is hard-coded and difficult to expand with extra systems any developer would like to have (for example, my attempts to implement an Ace Attorney cross-examination system are hell right now.)

example of current hard-coded nature
My proposal is to expand and unhardcode the system in such a way that it's split into several digestible scenes, all of which can be replaced and overriden by developers while Dialogic still provides out-of-the-box default versions of the behaviors. This way, beginners will have an immediately working interface - what Dialogic is very good at right now - and also provide an alternative for advanced users who want to use the backend of Dialogic while handling the frontend themselves.

example of a dynamic and nice version
In simple terms, the parser node is the big focus of this issue report. A very good principle to hold for this is as such:

example how a parser node only acts as an intermediary for anything connected to it to interpret the data
This approach will also solidify Dialogic's position in the Godot plugin scene and might even make it the #1 go-to plugin for dialogue interfaces 🤔

Duplicate issue #692: Separation of the built-in UI and dialogue system, allowing the user to implement their own dialogue box UI.
Created: 2021-12-26T23:55:44Z
Is your feature request related to a problem? Please describe.
Dialogic is an awesome, well-rounded plugin with many features. Unfortunately, due to the structure of the project, to use some of these features you are required to use all of them. In my case, I find that the timeline editor is incredibly simple to use and allows you to lay out complex branching paths of dialogue quickly. I'd like to be able to use this feature with my own custom-implemented dialogue frontend, instead of the built-in. Of course, the ingame UI that comes with dialogic is already fairly customizable and flexible to the user's needs with custom themes, but in my case there are just some things I'd like to be able to do that I can't without drastically altering code scene structure within the plugin.
Describe the solution you'd like
This is a hard problem and something I'd like to discuss more with the people developing this plugin. Right now, the DialogNode is coupled with many behaviors from its child Control nodes (such as TextBubble, FX, Portraits, etc...), which makes isolating the logic from the UI impossible without modifying source code. I propose separating DialogNode into:

A base, "headless" DialogNode class with logic implemented for loading, processing, and transitioning between events.
An interface for things like showing text, portraits, displaying (and responding to) choices, etc.
A default implementation of said interface in the form of the current default Dialogic UI.

On the user's end, this might look as simple as using the base class as an "iterator" over a timeline, which returns the current event info per iteration, then yields for user input (or not, if that behavior is not desired).
Describe alternatives you've considered
The easiest alternative would be to simply alter the source code and design the UI to my liking. But this has the obvious downside of being very difficult to keep updated with the main branch.
Additional context
I would be happy to help implement something like this, but I first would like to get a better handle on the source code and discuss a course of action, if this is something @coppolaemilio is interested in for the project.

Closing comment (2021-12-27T05:32:11Z): Related to #45