Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node based editor #16

Open
squk opened this issue Dec 2, 2023 · 1 comment
Open

Node based editor #16

squk opened this issue Dec 2, 2023 · 1 comment
Labels
Feature request Proposal for a new feature

Comments

@squk
Copy link

squk commented Dec 2, 2023

An editor similar to https://github.com/nagidev/DialogueNodes would be really handy. I'm not sure if the nodes should be processed into a .gdrama file, or just the same AST used in .gdrama.import files.

@moraguma moraguma added the Feature request Proposal for a new feature label Dec 3, 2023
@moraguma moraguma changed the title [Feature Request] Node based editor Node based editor Dec 3, 2023
@moraguma
Copy link
Owner

moraguma commented Dec 3, 2023

Mmm, I like that idea. I have some thoughts

First, in regards to implementation, the AST generated when a .gdrama file is imported can be very simply represented with a graph. As such, the easiest and most intuitive way to implement a node-based editor should be to allow users to directly work with the building blocks that are already being used in that AST. That would mean blocks for BEAT, DIRECTION, CHOICE and END

Furthermore, we would also need to consider how to represent custom calls in a node-based editor, like the branch call present in the DramaReader or the scamper call present in the project's demo - note that calls such as these can be used as a condition in CHOICE calls or as part of the specification of a DIRECTION. The way I see it, they can be written inside the text portion of nodes, meaning the user would still need to use a fair bit of GDrama-specific notation, or they can be made transparent by allowing DIRECTION nodes to contain a list of dialogues and calls, just like they are specified in the AST. I think the second solution makes more sense for this kind of editor but it might make it a bit overloaded with information

Regardless, I don't think this is a feature worth investing a lot of time into right now. The first reason for this is that GDrama is still very new, so a couple of things might still change significantly in the future. The second is that it would mean a bigger hassle for maintainability that I don't think is worth dealing with considering the project is still pretty small. I think it might be cool to revisit this idea if there's more demand for it though :)

Thanks and sorry for the huge text! I'm gonna keep this up in case people wanna give their perspective

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request Proposal for a new feature
Projects
None yet
Development

No branches or pull requests

2 participants