Provide way to export Orchestrations to other formats

[MojoMouse]

Description

Currently (as far as I can tell) there is no feature for converting an orchestration into text-based code. This leads to a concern that if a developer's usage of orchestrator becomes very large and for whatever reason they decide to stop using it, or would like to break down a particular orchestration into modules, that change would be preventively expensive.

Knowing this, it is difficult to justify bringing in a product which could potentially cause an expensive problem down the road.

Implementation ideas

One way this could be done is to allow the user to right click on a root execution node and have a context menu item to export as script. Since the plugin is already turning graphs into some sort of executable format, I assume it is not totally impossible to make this conversion.

[Naros]

it is difficult to justify bringing in a product which could potentially cause an expensive problem down the road.

Hi @MojoMouse, thanks for the feedback.

While we certainly understand your concern, we don't believe this to be a problem. If you opted to use any other plug-in in your game, or decided to write your implementation of some architecture and later decided to take a different path or wanted to replace such plug-in with something else, you'd be faced with precisely the same task.

Orchestrator's code is entirely open-source, so it's entirely feasible for anyone to write an exporter for C# or GDScript. It's equally possible for contributors to send a pull request to provide this feature for everyone's benefit.

One way this could be done is to allow the user to right click on a root execution node and have a context menu item to export as script. Since the plugin is already turning graphs into some sort of executable format, I assume it is not totally impossible to make this conversion.

It's certainly not impossible, but it's also not a high priority for us now.

[hyuri]

This would be awesome.

Perhaps even better if Orchestrator natively "compiled" the node tree to GDScript, and had a 1:1 compatibility with GDScript, so we could easily go back and forth (import/export) between Orchestrator and GDScript or can simply "inspect" the under-the-hood code, depending on needs.

[Naros]

Hi @hyuri, thanks for the feedback.

If we were to transpile to GDScript, compatibility is unchanged. Both Orchestrator and GDScript are based on the same Godot Scripting API today. Where there are limitations or differences between GDScript and Orchestrator at the moment is primarily around how to expose a text-based language feature in a way that makes sense visually. A great example of this would be something like @onready annotations.

The one concern I have with transpilation is the overhead. In particular, I know some plug-ins do this already, but what I am afraid is they are not taking into account reference overhead. I wouldn't be surprised if these plug-ins simply for each instance of their "script", they spawn a new GDScript script object. If that's what they do, that's really, really bad in terms of breaking the ideology between a "Script" and a "ScriptInstance". It also means you end up with higher game overhead as you have the same underlying script code created & loaded N times.

With Orchestrator and GDScript being natively based on the Scripting API like they are, this isn't a concern. The visual script is parsed once, a single instance of the script is loaded, and for each node instance the script is attached, there is only a ScriptInstance to manage the thin layer of per-node state in these cases. This keeps the overhead significantly lower and fast.