New way of making timelines outside of Dialogic.

[coppolaemilio]

So, the timeline editor is one of my favourite features, but I've chatted and read a lot of feedback on what the writers need when making text heavy games, and they all want to use a regular text editor.

Ink seems to be a pretty popular way of writing this kind of games, and the most common by far is just good ol' Ren'Py. Some even use google docs and copy-paste the text. Crazy, I know.

The rest of the people I spoke with were not using any kind of system and they were just writing it in the json/csv/script itself and not needing anything else.

I don't want to deprecate the timeline editor because I believe it is super nice to have, but instead of saving and loading that information into a json file that only a computer would want to read maybe we can come up with a way of storing that into a text file that is also human readable and editable.

I would love to keep the syntax as simple as possible without compromising the functionality of the events so I propose something like this:

[character join Max]
Max - Hello there! I'm Max and the only reason why I'm talking is because I have to fill out the screen with something
[audio play chill-music.ogg ]
[wait 2]
Max - Okay, bye!

A Text event could also be capable of parsing this kind of content, so if you want to write like this in the timeline editor you can do so. This will bring more flexibility in terms of how you write timelines specially for sections without a lot of special events.

At the moment this is a very early draft of the idea, but I wanted to write it out here so I can continue working on it and also getting feedback from anyone who might be interested.

[jcandres]

Yes please! I'm VERY interested in this. The timeline is nice but visually cluttered and clunky compared to editing plain text--in particular questions become super messy once you nest a couple of them, and removing events is so tiresome... and doesn't have undo/redo.

If you decide to implement this (please do!) I'd suggest keeping the lenguage as simple and natural as possible (closer to Renpy than Ink). The sample code you posted looks just perfect. In case you want some ideas:

• Character names marked by colon: "Max: Hello there!". This is very natural and you rarely see colon in dialogue, minimizing the need for escape codes.
• Whitespace and indentation similar to gdscript/python, specially questions and branching. Also, the "end branch" event feels a bit out of place in Godot.
• Stuff like audio files could be stored as variables instead of file paths, to keep everything nice and tidy across the entire project.
• IMO Markdown is faster to write than bbcode, perhaps also easier to parse?

[Jowan-Spooner]

I've also thought about this before. I think we should also open a seperate discussion about how to make the TimelineEditor and the Eventblocks less cluttered.

But about this: I wonder what would be the best way to implement this. And I'm not talking about syntax and stuff, I wonder if we would want to add the ability to convert a text file to a visual timeline (saved in the old dialogic json+dictionary style) and vice versa or if people would ONLY use their text files (and if in that case, the visual timeline should be saved in that way too). Because both ideas have their pros and cons.

I've thought about implementing it the conversion way. I thought it could be cool to have like a switch at the top of the timeline editor that would allow you to switch to a view, that would display the information as a text. When you save or switch back it would convert the input back to dialogic data (json+dictionary), so we wouldn't have to change the dialog node.

But of course, if we go for 2.0 we could decide to drastically change the style we save the timeline data in general.

[Jowan-Spooner]

@jcandres Not sure what version you are using. But 1.3 comes with Undo/Redo support for event actions like deleting. Agree on the rest tho

[ghost]

What about making this the main way of creating timelines?

I imagine the main drawback (for new users) of having to create a timeline through a regular text editor is the inability to know what events are available and how they are structured, so I'm proposing the following approach:

After clicking on an event button, you would get prompted about its parameters in a popup, which would then be used to add the corresponding line (or lines) to the timeline script.

The main aim of this approach is to avoid having to maintain two timeline creation systems in parallel, while still maintaining some of the user-friendliness of the current GUI.

Also, advanced users could use their preferred text editor, as the timeline would be stored as a plain text file.

[coppolaemilio]

What about making this the main way of creating timelines?

I wouldn't want to go back to something like that because it defeats the purpose of Dialogic itself. But that text being inside a text event alongside other events is something I could see happening to mix both worlds. But it has to be always optional. Something like this:

[jcandres]

A clean solution would be replacing the editor's output .json with a custom format, written in a simplified scripting similar to what's proposed here. You can edit those timeline files in a text editor, and still be able to edit them in the timeline editor.

I'm afraid mixing scripting inside the timeline events would be even worst, since it adds complexity to it (events all over the place, harder to debug) and is redundant (they are the same events, but look different) without solving the main problem (making timelines outside Dialogic.)

[bitbrain]

A very common tool is also Yarn Editor. Maybe introducing some sort of "plugin concept" into Dialogic could solve this problem. Dialogic itself could be kept clean and folks can just "plug in" what they need. Would https://github.com/coppolaemilio/dialogic/pull/644 solve that?

[alicerunsonfedora]

So glad I found this issue!

Ink seems to be a pretty popular way of writing this kind of games, and the most common by far is just good ol' Ren'Py. Some even use google docs and copy-paste the text. Crazy, I know.

Yeah, I'm actually doing that right now for a project. Pretty painful 😣

I have been considering making some form of an update to a Kotlin DSL package I made months ago to create the correct events and link them correctly, though I'm not sure how to go about doing it for the time being.

Maybe if we had something like that so that Dialogic remains clean while having an optional language that can compile the text into JSON that Dialogic will understand? Languages like Swift and Kotlin support making DSLs via function builders, so I think it could work out...

[alicerunsonfedora]

So, a small update to this. I just managed to make a small utility in Swift to convert markdown documents to really basic Dialogic JSON. There isn't anything like signal emissions or scene changes, but for what I need as a starter tool, it gets the job done.

You can take a look at it at https://github.com/Indexing-Your-Heart/head-over-heels/tree/root/utils https://github.com/Indexing-Your-Heart/marteau and see if there's anything in there that could help in making this alternate timeline script happen!

Edit: Updated link to new Swift package.

[Jowan-Spooner]

Update on this. This is implemented in the 2.0 branch, so we could in theory already close this issue. The question that remains is, if we will have a built-in dialogic text editor in godot.

[zaknafean]

Is it really on the table to ax the Dialogic UI as a whole?

[coppolaemilio]

We are not axing the UI! But now you can also edit timelines as plain text if you want to :)

[Jowan-Spooner]

Is it really on the table to ax the Dialogic UI as a whole?

No I was considering having a separte "text edit" mode inside of godot. As some people prefer to write text, this would allow us to implement auto-completion or syntax higlighting for them in a script-editor like fashion. But for now the timeline editor will be the focus of deveolopement and text editing will have to happen outside of godot.

[Jowan-Spooner]

I will close this. If further features are wanted/needed, separate requests can be opened.