Suggestion To Implement Node-based Editor

[123tris]

Why?

TL;DR

• Low-entry for users who aren't familiar with coding
• Better overview of branching dialogue
• Can allow for a more cohesive UX*

Many games that contain a more complicated dialogue system use some kind of node-editor to visualize and editor dialogue.

Articy craft is a good example of a professional tool designed exactly for that. Used by Ubisoft, CD Projekt Red, EA, and many other professional studios.

This is how Articy Craft visualizes a dialogue. By using a node-editor and icons it makes it very intuitive for a user to create and edit dialogues.

A simpler version of this could look something like this:

*= The reason why this can allow for better UX is that you can allow the user to edit other data by selecting items/buttons inside of the node. An example would be the avatar. You could have a small edit button, double-tap, etc. to open up a window to change that character's data.

How?

It's completely up to the team on how to go about implementing something like this but I would like to pitch in my two cents on this. It's important to avoid dependencies and keep editor code completely separate. So I think ideally you would want to generate API code (Lua,Ink,etc.) using the node-editor. The editor could even be a separate application by all means whilst generating scripts. Really depends on how exactly you want things to work in tandem.

[Tylertron1998]

Here are my two cents on this:

Forgoing the difficultly of implementation; I think the main problem at hand here is one of design. Here are some issues that come to mind:

• How do we handle specific SDK code, that's available in one language sdk, but not another? E.g. in the lua library, if there are helper functions related to lua only, how do we handle that, say if you want to change your compile target to C++? Do we only allow these in a lua build? That would break portability; if you write out a massive visual system which is build for compilation to lua, then decide that you need the extra speed of C++. Do we not allow specific library code to be used at all? If so; how do we mark certain methods as "unusable". Do we just disallow any language specific library code, and treat visual scripting as a first class language; giving it it's own SDK which can be pollyfilled/implemented in the compile target language?

• Debugging. This is a big one; while I understand visual scripting is mainly aimed towards those who do not have any experience with traditional programming, and debugging would likely be too advanced a concept for them; IMO debugging support is needed. Do we have the debugger run on the compile target language, and have comments explaining what code is generated from what node? We'd need a pretty comprehensive guide for that, imo. Do we try and make our own debugger? If so, how do we go about that? Hook into the compile targets' native debugger and try and act as a "middle man"? Do we write our own node-based intepreter and debug that instead, for debug builds only?

• Errors. How do we handle that? Do we parse stack traces from the compile target and have some sort of "source map" system that related compile-target method calls and invocations to the node representation? What about language specific errors; e.g. a type error or common throw expression? And what about errors that aren't generated by us; e.g. an IndexOutOfBoundsException would make no sense to someone who is trying to use node based scripting - and there isn't a clear cut way to "translate" that between the node based 'syntax' and the scripting based syntax.

• Language specific features. How do we handle something that is possible in one language; but not in another? I.e. asynchronous programming. What if we support a language that doesn't have the concept of async? Do we not expose a node-based concept too? Do we only expose it if the compile target supports it? If so; portability is again an issue.

I think a visual scripting/node based system would be amazing. I'd love to see this as a first class citizen - there are many benefits to this and it'd really help us target a wider audience - however I feel these issues are things that do need to be resolved and chewed over, I'd love to see some discussion and ideas for any resolution!

Thank you for the suggestion!

[RubyNova]

The way I'd visualise this working is basically Ink script generation. Since Ink will always be available as a core feature and is how were handling all our dialogue support, we could also extend this to "C# components by default", so to speak, though I think if we want to support custom components that would be later down the line.

I feel this addresses point 1 since it'd be exclusive to an engine feature.

As for debugging I feel this is affected by my opinion on custom components. If we choose to not support custom components, at least at the start, then there isn't really anything to debug as an end-user.

This, by extension, means any errors that happen would need to be output to a log file that can be sent to us to fix things internally.

As for language specific features, things like asynchronous programming would exist within the context of user-defined custom components. They could debug that themselves and I can't imagine us providing anything along these lines OOTB.

I think if we limit the scope quite heavily, its doable. It just depends if people would still want it in a limited state.