Godot: Break out gdscript module

[rosshadden]

The sort of scripting language isolation that you have in Godot's architecture is quite unique, and _very_ exciting! I have a suggestion to capitalize on it and make it even better. I don't think it's a huge change, but I am definitely interested in hearing your thoughts. I absolutely love a lot of parts about Godot, such as the amazing interoperability between making C++ modules, and using them in Godot and gdscript. I honestly believe that with a bit of work, this could be yet another part that hardcore users fall in love with.

I think it would be a great idea to break out modules/gdscript into a separate repo, and any other possible parts of supporting gdscript in this repo. Especially with the work on supporting C#, this would make a clear separation between language bindings and the core engine and editor.

I know you guys don't want to support a bunch of languages, and I don't blame you! I think doing this would facilitate the community to work on their own bindings if they want them, which you should not be bogged down by supporting in any way. For example, all the people complaining about supporting "X language" (JS, Rust, C#, etc.) could actually even more feasibly add support themselves, or start up a community effort. The less work you guys have to do, the better.

Admittedly I was one of those people complaining, as I would like to use a language with an established ecosystem that extends far outside of gamedev, such as JavaScript with all the packages on npm. My current understanding is that if I work really hard at it I can make this happen already, but I think breaking out gdscript would make the path even more clear.

[RebelliousX]

Sounds good, but I have something different in mind. What about if Godot can load and run functions from external libraries (.dll in Windows, or .so for linux/android, dunno what is it called for MacOS).

It would be great that the game developer won't need to recompile Godot to get his work done. Plus, anyone can attain full control and speed by using C++. And you can even make libraries using virtually any language you want, not limited to C++/C#, but also VB.NET for example. or any other.

It would need telling Godot about the library file and its export functions and arguments. and a way to call those functions from gdscript.

[karroffel]

@RebelliousX today's you lucky day. @bojidar-bg and I are working on exactly that!

The idea is to use dynamic libraries for scripting. For that we're having a C API that wraps all the exported classes that are usable in GDScript (ClassDB to be exact) in C functions.

It's already working but still needs some work. We're aiming for 3.0 to get this upstream.

Problem with DOs is that most languages only (if at all) support C linkage, C++ name mangling is quite a mess. So in theory it would be possible to simply plug in a .so/.dll/.dynlib and have another language integration. Problem today is that the scripting API relies on C++ template, if there's a way to expose the scripting to C then plug-in-scripting languages would be totally possible.

I don't know how much work that would be to change the system to support that and there's usually more to than just the scripting binding (like a custom resource loader, not a big deal but still an issue).

To have such a system in place would be super nice, but again, requires the current template system to vanish.

[vnen]

Separating the GDScript module to its own repository is not a prerequisite to any of that. Community can join efforts to bind another language nevertheless.

Second, it'll make more difficult to maintain Godot and GDScript itself. Git submodules are always a pain to work with (not easy to update, they require initialization after first clone and are not present in GH tarball).

Finally, GDScript does not work on its own and is fully dependent on Godot, so there's no reason to keep it in a separate repository.

[karroffel]

@vnen is right, GDScript is dedicated to Godot from ground up, even though Godot is decoupled from GDScript. Because it might be possible to have plug-in-languages in the future doesn't mean that GDScript shouldn't stay a core part of Godot.

So a 👍 for the more accessibly community driven language bindings, 👎 for seperating GDScript.

[rosshadden]

Fair enough! I really like the direction you're talking about taking, and it sounds like you have even made some progress. We could rename this issue to make it about using dynamic languages, or we can just close it. Either way, is there anything I can do to help out? I'll start popping into the dev irc channel.

[RebelliousX]

@karroffel Great! I can't wait to see your and @bojidar-bg 's work in 3.0 :)

As for C++ name mangling, the only good thing about it AFAIK is that to be used for functions overloading. You can enforce some rules about using dynamic library, like some specifications that must be followed so that it can be used. For example, all exported functions must follow C linkage extern "C" specifier (functions' names demangled). Or that a certain functions in the dynamic library must exist that do specific job, for example to return a list/set of function pointers and their names and argument types to be used by Godot. I don't know if that will work though, just an idea. I don't know how dumpbin.exe for Windows or nm for linux read symbols from dynamic libraries, But that is why I prefer enforcing some specifications though, since by using C#, one can export classes or partial classes in DLLs to be used by host application, which would be a total mess.

p.s: if the paragraph above is incoherent, then I blame lack of sleep.

[vnen]

BTW, there's a quite long discussion about dynamic modules already: #3936 (relevant comment about providing a C API: https://github.com/godotengine/godot/issues/3936#issuecomment-226252150).

[akien-mga]

I think this discussion can be closed, GDScript won't leave the main repo for the reasons stated above by @vnen :)