With 2024 now upon us, we are pleased to announce the availability of the first Orchestrator development build, 2.0.dev1. Over the last three months, the team has been working diligently on the next major iteration to Orchestrator, a visual-scripting system for the Godot game engine. This major version is packed with tons of new features, improved visual and accessibility options, better Godot Editor integration, and is easier to use within any Godot project.
Let's take a moment and go over some of the major highlights in this build:
Transition to GDExtension
One of the first major changes with Orchestrator 2 is that it is no longer based on GDScript, but rather is rewritten entirely in C++ using GDExtension. The GDExtension framework is the successor to Godot's GDNative framework, which allows developers to write C++ plug-ins and add-ons that are directly coupled to Godot's lower-level engine APIs. This provides significantly better integration with certain engine aspects and more importantly the Editor. It also allows for better management of certain data structures when working with complex logic and orchestrations at runtime.
With GDExtension, the plug-in is compiled to native code and shipped as a shared library that will be installed into your addons\orchestrator directory of a Godot project. These shared libraries will be opened automatically by the editor when the editor starts. Additionally, when a game is exported, these shared libraries will be copied next to your executable and .pck asset file. Without the shared library(ies), the editor will be unable to load Orchestration resources and exported games will be unable to run those.
Orchestrator provides three flavors of binaries, one for MacOS, Linux, and Windows.
True Godot Scripting Experience
In Orchestrator 1, the plug-in was written in GDScript, but as such an Orchestration could not be attached to scene nodes. This made the integration of Orchestrations into any scene a bit cumbersome and not user-friendly. With Orchestrator 2, we felt that it was a top priority to close this gap and really bring adding an Orchestration to a scene much the same way you would when using C# or GDScript.
The choice to use GDExtension was very much coupled with this need to integrate seamlessly with the Godot project's scene tree. Therefore, Orchestrator 2 implements the ScriptExtension and ScriptLanguageExtension contracts provided by the Godot engine. These contracts enable Orchestrator to act like C# or GDScript, meaning that creating an Orchestration is just like any other script. It can be attached to a scene node, edited and manipulated, including integration with exported properties via the Inspector.
Orchestrations: The Blueprint of Godot
One of the major limitations we saw with Orchestrator 1 was that the depth and functional capabilities simply wasn't at the level we wanted. If you look at other commercial game engines, they all typically have their own Visual Scripting framework and these frameworks typically integrate deeply into the engine. Whether they allow you high-level abstractions to perform common actions or expose low-level APIs to create complex business logic, the idea remained the same that these frameworks were deeply tied to the engine and exposed a wide breath of functionality to the user.
With Orchestrator 2, we wanted to make a shift in this area, we wanted to provide a true, visual scripting experience. We spent a great deal of time looking at alternatives across the industry and came up with a concept that we felt best represented common themes and the best practices from various sources. Rather than an Orchestration representing a single flow of code as in Orchestrator 1, Orchestrations are now more akin to a full script you might see in an Unreal Blueprint or a Unity Script. They include different port types that represent control flow and data flow, allowing for any level of complex graph designs.
Orchestrations are now what we believe are full code units, which can include multiple event graphs, multiple user-defined functions, and custom variables. We also intend to extend this in future builds to expose functions and higher-level abstractions to create custom nodes and libraries that can be used across multiple Orchestrations, opening the door to code re-use across different behaviors.
Enhanced Godot Editor Integration
While Orchestrator 1 had some level of Godot Editor integration, it was quite limited. We wanted to improve upon this by allowing for seamless drag-and-drop functionality across the entire Editor window, including integration with the Scene Tree, Inspector, and Filesystem docks. You can safely drag a scene node onto the Orchestration graph canvas to create a reference to that scene node for use, drag properties from the Inspector to create a Get or Set node to mutate those properties, or drop resources from the Filesystem dock to preload resources that you may need as part of your game logic.
By fully integrating into the Editor's framework, Orchestrator feels like a real part of the Godot Editor experience. It provides an intuitive, user-friendly experience and works well with all other standard Godot Editor modules.
Visual and Accessibility Enhancements
Orchestrator 2 also takes a deliberate and conscience choice on the overall user experience. All node's visual fidelity has been improved, user accessibility controls have been added to deal with managing colors and other aspects for those with colorblindness or who simply want to use a Contrast-based color scheme 🙂. Orchestrator 2 integrates with the Godot Editor's Project Settings UI, exposing a plethora of customization choices.
Other Information
The plug-in is open-source and licensed under the Apache License, Version 2.0. All releases of the plug-in are available here, and the source is made available on GitHub.
● Bugs → Open an issue on GitHub.