vs_proposal.md

Proposal for Changes to Visual Scripting System

AIMS OF THE PROPOSAL

• Moving towards modularity
• Simplification and accessility for customization of the scripting system
• Reloadable and Debuggable chunks
• Cleaner and robust utilities while scripting

Primary Idea: Adding reusable Sub-Graphs/Scriptables to the Scripting System

Description

Terms(I have used):

• Graph: The entire Visual Scripting System.
• Scriptables/Sub-Graphs: Nodes that can be user programmed inside the Visual Scripting system
• Sub-Scripts: These are a sub type of Scriptables, that are used as blocks of reusable Visual Script, saved as resources and loaded as per need.
• Context: Each Scriptable will have Contexts will be a template for it's behaviour to reduce the amount of custom code per Scriptable.

The idea is to have reusable module inside visual script to allow users to have more control over the abstractions and allow them to share code without concern. (As seen by my current Visual Scripting Modules library it's quite desirable but it forces someone to know GDScript and some amount of programming skills to be able to make them).

DESIGN IDEAS (Images and code snippets)

The similar design idea of the scripts is to have multiple types of Scriptable Nodes which act as simple nodes but can be entered(double-clicked) to allow for showing a simpler view rather than having to use tabs and side panels to change there parameters. Similarly this can be used for a more complete Graph implementation as well, such as for creating proper scripting interface which can be switched into on need. And allow for keeping track of history, using the undo stack of the Editor. Without losing track of original Visual Script. Like stacked editor views.

For the implementation the idea is to use Modular Contexts which will allow us to build different types of Scriptables with maximum reuse and minimal extra maintainence compared to having custom implementations for each of the Scriptable objects. Such as have GUIContexts, that decide how the Editor should look while editing the specific Scriptable Node. Similarly there would be other Contexts for deciding the domain of various necessities of the Graph. Such as the Nodes to be used, types of connections, etc.

Contexts would allow creating completely custom visual interfaces for interacting with Visual Scriptables, and would be paired with ContextData Objects which would hold the data of all the Scriptable objects and saved with VisualScript in case of normal Scriptables and/or as separate resources for Sub-Scripts.

And as a final bonus because of using Modular Contexts it will become easy to allow for custom settings for each kind(as a set) of the Scriptables as user editable settings, similar to how Blender handles it.

Even though this proposal focuses on Sub-Scripts in general there are benefits of such a design and keeping such an interface in place. Such as...

Examples of What might benefit from such a design

Here's an Expression Scriptable that allows writing expressions in form of Trees.

OUT
|
N0 - N1 - N3
  \          \
    N2 - N4    N5
      \
        N6

Allowing for a much more visual way to compose expressions, especially for more complex expressions. With a visualization system to help understand them.

Inspired from the Math Expressions in Unreal Engine.

Other example is the sub-scripts which allow a module of Visual Scripting code to be bundled and saved for later reuse and loaded into the script or other sub-script.

KNOWN PROBLEMS

1- Visual Scripts act as per the context by design, and in general scene level context is volatile and thus not suitable for reusable scripts, I have had number of crashes because of missing nodes, or node type mismatch.

2- Modules or Sub-Scripts need to be saved, and thus need to be used as resources but just like scenes they may have dependencies, from project level context(e.g. drag n dropped resources).

3- Recursive Sub-Script usage, technically having Scriptables inside of scriptables is rather desirable but there can be instances of self-nesting, such as. NodeA uses NodeB & NodeB uses NodeA. Not only these are annoying but can lead to deadlocked code. It's debatable if self-nesting should be disallowed entirely.

4- Over exposure of GDScript API. Tools such as Threads which could be a cause for concern, as Visual Script is not entirely preemptive, and with Scriptables it may become harder to follow execution paths. Maybe cutting down on access to some features and having safer abstractions for them make sense.

5- (Optional) Resource save/load system could use some work.

Handling Context (Proposed Solution)

The contexts and linked resources/scene nodes tend to be the biggest problem for the sub-scripts and so one of the solutions is to not have Scene level context directly present in the Sub-Script but added in as an input from the main script, and similarly for complex resources. This would allow the sub-scripts to be context free and thus stay completely modular and easy to share.

Optional/Future Propositions

• Direct integration with the plugin system, to allow sharing Scriptables openly. Should be doable with proper dependency mapping.
• Hot reloading for Scripting System for hot swappable blocks, via the Debug mode integration similar to GDScript. It should be possible to freezing game state, and allow reloading visual script, same as GDScript.

Failed attempts

TO BE UPDATED!

I chatted with people. Describing this as collapse to function, expand to graph really made sense.