0 votes

I'm most comfortable using C++, so it's a major factor in deciding whether or not to use Godot: Will I ever be able to directly code behavior in C++? And I don't mean plugins and libraries I can call from GDScript, no. I mean the ability to do it directly like you would now in GDScript & C#. The way it feels now is I'm calling C++ from inside a Python script and that is generally not the experience I prefer.

Now to be clear, I'm not saying this is bad or that Godot should do this and that. I'm just merely asking for the sake of making a better informed decision: Will I be ever able to, practically and naturally, without going through the twists and turns currently required, code my entire game in C++?

Thank you.

asked May 2 in Engine by NoahADavon (15 points)

1 Answer

+2 votes
Best answer

This is a topic that was answered a lot: https://godotengine.org/qa/search?q=scripting+in+c%2B%2B
So I'm going to repeat most of what was said in the past:

The closest to C++ "scripting" is to use GDNative with the C++ bindings, or modify the engine directly by making a module.


If you think about creating a cpp file from Godot, edit it in the Godot editor and have it magically compile and run solely after having downloaded the Godot executable, I'm not aware of that coming anytime soon.

  • C++ needs a compiler for every platform you target. I don't know if Godot can even ship with that included, and such tools are often 4 times the size of Godot alone.

  • C++ needs a build system, as using compilers directly is quite a chore in projects with more than a few files in it. That's again another dependency.

  • C++ is a generic language while GDScript is dedicated. There is boilerplate required for Godot and C++ to interact as scripts.

  • C++ is incredibly hard to parse. Integrating a C++ editor inside the editor is a large amount of work and the fastest path would be to integrate a language server, which in turn asks for another big thing to include to the editor.

  • The Godot source code has never been thought to be used as a library. That is, you can't just include sprite.h and extend it like that. Instead, Godot uses function pointers and it has been used in the GDNative C API, chosen for ABI stability, which is not direct C++.

  • Godot project scripts can be used as plugins, not just games. That means the assemblies produced by C++ compilation would have to be compatible with anyone's Godot installation and OS, or in turn force users to compile from source.

So again, for now GDNative with C++ bindings is the closest it gets. There is a significant amount of setup to make it work still, but assuming you choose one build system and stick with it forever, it can be fairly automated or copy/pasted across projects (it's a do-once-and-forget task). Yet, forcing a build system and a bunch of dependencies on everyone just for the sake of having the same experience as GDScript is quite tough.

The de facto setup for C++ is:

  • Install a C++ compiler
  • Install Python
  • Install SCons
  • Clone Godot C++ headers
  • Generate C++ bindings
  • Setup your C++ project using SCons
  • Add .gdignore to prevent Godot from importing .obj files
  • Add gdnlib resource to reference your C++ assembly
  • Add gdns resource per C++ script you want to have
  • Optionally, setup an IDE. QTCreator and VSCode are quite common for cross-platform development.
  • Now you can start "scripting" in C++

    As described here https://docs.godotengine.org/en/3.2/tutorials/plugins/gdnative/gdnative-cpp-example.html
    Note that this is "de facto" because you could set this up differently with other build systems or even other binding types. This is just a common one.

Any improvement to this is volontary. I don't think it will happen over night, as we are running low in the amount of GDNative maintainers having enough free time to work on this.

answered May 2 by Zylann (26,139 points)
edited May 2 by Zylann
Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.