Importable function declarations / function libraries

[Naros]

Description

There are often use cases where it makes little sense to try and model specific behavior using a series of graph nodes but rather to model the behavior by calling into a low-level function that performs the low-level action for you. A great example might be when you need to interact with loading some text or JSON data using the FileAccess API.

Implementation ideas

It's not uncommon in the industry that some other abstraction layer handles specific low-level activities and that the visual tooling merely delegates the operation to that layer. For example, taking the contents of a control and writing it to a file on disk, while simple, can quickly become a complex task depending on the data and format involved. For this reason, even commercial engines elect to handle this outside of the visual tools.

Presently, a user in Godot can make this work by creating a scene node and attaching a GDScript file that implements the file-based operations, interacting with Godot's FileAccess object. Once done, this node can be dragged onto the graph canvas to drop a SceneNode node. When dragging from the node's output pin, any function defined on the script will be shown in the action menu, allowing the user to invoke those functions from the Orchestration.

However, creating this scene node seems superfluous and could be avoided. We could introduce an OrchestrationFunctionLibrary class that can be extended by any Godot scripting language, i.e. GDScript or C#. The Orchestrator plug-in would track all types derived from this class, allowing the user to select which derived implementations are imported into the Orchestration.

Once an OrchestationFunctionLibrary is imported, all functions defined within the library would be immediately callable from within the Orchestration, as if those functions were part of the base type. So, in short, rather than dragging from the scene node example above to access the defined function, the user could simply right-click the graph, and it would be accessible.

[Naros]

This also has an added benefit: it allows Orchestrator to deliver OOTB functionality using function libraries. We had initially thought about doing this primarily using particular types of Orchestrations representing a function library, a collection of functions defined using visual graph nodes. But there is likely a reason to consider supporting script-based function libraries, too.