Which is more likely to be implemented past 4.1: F# API or Visual Scripting (2.0 Electric Boogaloo?)

[UltimaTerra]

The title says it all, I am sure this gets into the weeds of the Godot Core. I considered asking this question in the godot discord since I use that platform more often, but I think this is a better venue.

As far as I can tell, this repo is the former part of Visual Scripting used by Godot prior to removal in 4.0: https://github.com/godotengine/godot-visual-script

I have a sort of vision and proof of concept of visual scripting, but personally been delving more into functional programming with NET with F#. I am asking for curiosity, but the general thought of my question is this.

• If Mono/.NET were to be further supported, would an F# API like the C# API be viable to implement for enthusiasts compared to a Visual Scripting one?
• With the recent Unity controversy, does C# support match up to feature parity of other engines or frameworks? (I am thinking Unity primarily, but also XNA and others that use C#)
• If a bit ambitious, if both were somehow 'equally likely' in the future, would it use GDExtension and does GDExtension support multiple bindings?

I am new to Godot by about a year, been mostly experimenting with it. I did however fork both the repo linked above and the Godot repo. I would be lying if I said I could just raise my hands and say "Fine, I will do it myself!" but any insight would be appreciated. I personally look forward to diving more into the source code in the coming years, so I might ask more questions about the source code. (Which I hope isn't too hard to wrap my head around!)

[theraot]

You are asking to predict the future.

I can tell you about what I know of the current state, and what can be done right now. But I can't answer which path is more likely.

---

While Godot's API was not designed with F# in mind, in general F# can consume C# APIs, thus I'd expect that a proof of concept of F# integration can de bone rather quickly. In fact, I believe it is possible to convert the generated C# project to a F# project and go from there (i.e. you can hack it, and some did for old versions of Godot). I do not know if there is enough interest to maintain it as separate plugin.

---

The C# API does not have parity with Unity or XNA, because Godot does have parity with Unity or XNA, they are different and will remain different. Are there any specific features you are looking for? Godot probably has its own way to do it. And if not, we might look into that.

C# support is mostly on par with GDScript… In fact, GDScript is built as an internal plugin, over the same interfaces that any other language can plug in. Thus, your question is not really about Godot's C# support is on par with Unity or XNA, but if Godot's API itself is. And that applies to any of languages you can use with it (officially or not), from Python to Rust, from C++ to C#, and, of course, GDScript… as they all consume the same API.

Of course GDScript has better integration due to being designed for it. For example, we cannot add NodePath or StringName literals into C#.

---

Godot requires .NET 6, but you can switch to .NET 7, and use C# 11 features. We are missing support for - if I recall correctly - web and iOS exports, which I believe will be addressed soon (for what I read they were waiting on .NET 8, which is now in public pre-release, so I expect that future versions of Godot will require .NET 8).

And, yes, the C# language integration in the built-in editor is sub-par (you don't get proper intellisense, for example), for which do the same people did with Unity: use an external editor.

---

For the foreseeable future Godot will continue to have separate builds for .NET. However, yes, ideally GDExtension would be used to add C# to Godot some time in the future.

And about Visual Scripting, there have been community attempts to retrofit or reinvent it for Godot 4. However, I believe there is not an unified vision for what it should be, so people are not rallying behind any particular project. And yes, it could also be done via GDExtension, although I'll point out that the repository you link is a module (it requires to build Godot with it to work).

---

If you have organized your idea/vision of visual scripting for Godot, consider if you want other eyes on it, you can always share it and get feedback from the community. It might be turn into a popular plugin, perhaps something on the asset library, or even something merged into Godot depending how things go. But, of course, that would take time, and more probably more people contributing.

What I'd wish for is that the people who have been trying to make this happen join forces.

[UltimaTerra]

Sorry for being a bit slow/late with this reply.

Thank you for the honesty and conjecture, I really appreciate the good faith and response!
To be more clear with my intent, I will probably be providing a mockup of a visual scripting as a proof of concept as it combines my more immediate skills with design. That will be a while, but I expect I can post that here and reiterate the idea further?

And no, there is no particular feature of Unity/XNA or FNA or whatever else, I was just curious, although in hindsight I admit the question was too broad and kind of just ignorant, but hey you live and learn.
Also, I was reading the documentation on GDExtension but to be frank, I didn't quite get it. It is a dynamically linked library to any language, right? Right now, the official ones are C++ and Rust, but personally investing alot of learning and time into Nim. Same with F#. Admitedly, I like 'readable' languages. GDScript will work fine for me the next coming years.

Once again, thank you and feel free to ask if you want further clarification!

[theraot]

@UltimaTerra You can continue to post here. You might also open up a new discussion to share your mockups and such. I suppose the proof of concept could be hosted aside and linked.

There are aspect in which Godot falls behind compared to the expectation people might bring from other engines, some of these are supplemented by addons. One such example is that Godot lacks a terrain solution.

To be honest, I do not understand how GDExtension works either. Yes, it would link a library dynamically, which could - in theory - be created in any language, however the official support is for C++ only. Rust is a community effort. There also was a community project for Nim using GDNative/Godot 3, but I'm unaware of one for GDExtension/Godot 4. As far as I can tell, F# has a better starting point taking advantage of the effort put forth to support C#.