Reconsideration of VisualScript Removal and Proposal for Separate Version

[SharkStudiosSK]

Describe the project you are working on

I'm drafting a proposal to bring VisualScript back as a stand-alone Godot engine module or version. The project intends to give developers that like visual scripting an alternate scripting technique that enables them to construct game logic without writing code. In addition to offering a feature that was previously accessible in Godot 3.x, the objective is to satisfy the various needs of the Godot development community.

Describe the problem or limitation you are having in your project

The issue is that developers who depend on VisualScript no longer have a preferred scripting technique because it was eliminated from Godot 4.0. This restriction impacts the following developers:

• Choose visual scripting over programming that is based on text.
• Need to quickly develop game concepts without knowing how to write code
• need a visual scripting technique and are teaching others about game development techniques. These developers now have fewer options due to VisualScript's withdrawal, which makes it harder for them to work effectively.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Reintroducing VisualScript as a stand-alone module or Godot engine version is the suggested functionality. With this improvement, developers will have access to a visual scripting technique that enables them to:

• Make game logic without knowing how to write code.
• Quickly develop game concepts
• Teach others the principles of game development by employing a visual scripting technique. By offering an alternate scripting technique, meeting the many demands of the Godot development community, and facilitating developers' productivity, the functionality will aid in resolving the issue.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The idea is to develop a distinct Godot engine module or version that incorporates the VisualScript framework. This is a high-level summary of how it will operate:

• Developers will be able to enable or disable the VisualScript module as needed because it will be designed as a plug-in.
• The VisualScript editor, which offers a graphical user interface for developing game logic, will be included of the module.
• The Godot engine will be integrated with the VisualScript system, enabling developers to utilize it in combination with other scripting languages (such as C++ and GDScript).
• The module will have its own development cycle and community contributions, and it will be maintained concurrently with the core engine.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, a few lines of code won't get around this feature. The implementation of VisualScript necessitates a substantial amount of infrastructure and code due to its complexity. Although GDScript and C++ can be used to develop a basic visual scripting system, they would not offer the same degree of capability and usability as the original VisualScript system. A feature that is simple to use and available to a variety of developers, including those who are new to game development or prefer visual scripting, is another objective of this proposal.

Is there a reason why this should be core and not an add-on in the asset library?

Although VisualScript can be added to the asset library as an add-on, there are a number of reasons why it ought to be regarded as a fundamental component:

• Integration: Since VisualScript and the Godot engine are closely related, integrating it as a fundamental feature would guarantee smooth operation and prevent any compatibility problems.
• Performance: One of VisualScript's primary features is performance optimization, which makes sure the script operates well and doesn't affect the engine's overall performance.
• Maintenance: By designating VisualScript as a core feature, the Godot development team would be in charge of keeping it up to date and stable.
• Community: By making VisualScript a fundamental component, the Godot development team would show their dedication to offering a complete and welcoming game development environment that meets the many demands of the community.

[arkology]

Addon already exists. Chech https://github.com/CraterCrash/godot-orchestrator .

[jokosablenk]

see also #8873

[KoBeWi]

From addons there is also https://github.com/endlessm/godot-block-coding, but it's more a learning tool than VisualScript replacement.

Maintenance: By designating VisualScript as a core feature, the Godot development team would be in charge of keeping it up to date and stable.

That's not how it works. When something is "official", it still needs an active maintainer, otherwise it won't get updates and fixes and will fall behind other features. See GridMap for example.

[AThousandShips]

One of VisualScript's primary features is performance optimization

VisualScript doesn't offer any performance advantages over GDScript unless it's implemented without going through GDScript, and even then there's no reason to assume it would have a performance advantage

Making it an integrated part of the engine wouldn't significantly affect performance, especially as any add-on can be built in c++, but other than making the editor interface usable there's not really any issues with performance when using VisualScript as it would just be translated into GDScript, and that translation would be easy and fast even if implemented in a GDScript based plugin

[Meorge]

bring VisualScript back as a stand-alone Godot engine module or version

As far as I understand, the Godot maintainers have been wanting to get away from having multiple versions of the engine (with and without C# support), so that there's less confusion about which version of the editor someone should download. Because of that, if VisualScript were to be added back, I definitely think it'd make more sense as a module. We already have VisualShaders and regular Shaders all within one Godot version, so there's precedent in that regard.

This restriction impacts the following developers:

• Need to quickly develop game concepts without knowing how to write code

This developers will still need to know how to "write" code - just in this case, they're "writing" it by dragging wires between nodes or stacking blocks together, instead of typing out things on their keyboard. The need to understand the game logic and convey it to the computer is still there.

This is a high-level summary of how it will operate:

• The module will have its own development cycle and community contributions, and it will be maintained concurrently with the core engine.

This is much easier said than done. We'd need to find someone who would be willing to maintain it, and community members willing to contribute.

---

Overall, I think it makes the most sense here to use one of the several available visual scripting plugins for Godot instead of trying to make it into a core engine feature. Different people find that different kinds of visual scripting work well for them (node-based vs block-based, etc), and plugins allow them to use the one that clicks best.

The biggest, "best" argument I've heard for a built-in visual scripting solution is that it would be well-maintained and documented because it would be a core part of Godot, but that conclusion doesn't really follow from the premise. It certainly means that there'd be pressure on Godot maintainers and contributors to keep it up to date, but that doesn't necessarily translate to it actually being maintained well.