• General Chat
  • Is there a simple way to code in C++ (at least in the near future)?

I'm asking for help from this community that I sense as friendly and I see myself as taking part of. Please, lend a hand.

I've been studying Godot for weeks hoping that now I had left Unity behind. The only reason for the switch is C++. But it seems that no matter how I try to put it, I'm always bumping into this problem with Godot: I just can't code in C++.

There are 2 ways to code in C++ in Godot, alright, that everybody mentions: custom modules and GDNative. I've read tutorials on both and I noticed a problem for me personally and TBH I've seen for other users out there, too, but I'm speaking for myself now: You have to write lots of code in both approaches, binding and whatnot, code unrelated to the actual interest: game play. And from what I've read, the workflow is alike for both: you put your code inside a library and then in GDScript you call functions from inside that library. There is such a large gap between these approaches and ideally adding C++ scripts in the editor, that it makes coding in Godot C++ scripts prohibitive due to lack of what Godot strives for most: simplicity.

I'm not an experienced C++ programmer but I know as much as to code game logic and I want to use it and when I heard about Godot supporting C++ and I stepped from Unity to Godot, I expected to have the flow I had in Unity or at least the C++ flow offered by Unreal which BTW blends C++ with the editor seamlessly. The reason I haven't settled for Unreal was the over-complexity of the architecture. Unity was out of the question.

So I'm asking you is coding C++ going to be as straightforward not as with GDScript but at least as it is in Unreal? In the near future I mean. Can a module be made to allow this? Is this feasible? Does it require funding?

I want to stick with Godot but C++ is a strong reason to not let me, especially now that I found an open project that allows you to use C++ scripts in Unity (almost) as simply as C# scripts.

I think GDNative is a way.....in the future I'm sure this will be better and better ( support for C++ through GDNative )....I mean, Godot 3.0 is mainly all about huge rendering 3D stuff improvements.....then stabilize performance and then other scripting possibility......Godot 3.0 is an important milestone in the history of Godot engine...this is a cut-off the fuse cord with a Godot 2.0 versions. I'm with Godot engine one year but..I saw....so many new things in Godot..it's incredible.....amazing incredible!!....this is strong free-creativity soul of Godot engine...and I'm happy to be there. I'm satisfied with GDscript so much.....it's more or less easy to write for novice or artist and at the same time sufficient for advanced users.....but I see your discomfort with none so easy C++ scripting in Godot.....so the future will show :) All the best, Bishop.

P.S ...GDscript is module too and ( "..,is not part of the base engine" )...how it is written in Godot docs - docs.godotengine.org/en/latest/development/cpp/custom_modules_in_cpp.html

Thank you Bishop, I appreciate. You're always willing, and considerate. I like Godot very much and I mean it. But I can only do so much. From all the options I'm faced with, I would totally dedicate my next time to make a C++ module like GDScript, if I were able to. But it's way beyond my possibilities :disappointed:

C++ is pretty hard to master. Of course a beginner can always write little things who can be compiled, but nothing prevents him to write buggy code who bites the user later.

GDScript is enough for most scripts. When Juan and Ariel created this, they cared about artists and various non-programmers. That's fine because the main causes of performance issues are in the engine himself or in the project design. In theses cases, C++ can't solve this.

If the script is too slow GDNative looks like the least cumbersome solution, because only the scripts are compiled so it's faster to do trial and errors (comparing to modules).But yes, setting the GDNative environment is a pain, like every programming project, but you do this once. I hope that in the future, a plugin would integrate text highlighting, compiler commands and so on, to use with a GDNative binding. The most annoying, in my opinion, is the amount of various files a GDNative binding add to a clean Godot project. Such a plugin should centralize and automatize the settings. This seems possible for who have some knowledge about the editor source code.

GDScript is a lightweight language and yes it's easy to use with nodes: call their methods and fiddle with their properties. Yes it's good enough for interactions between engine components. And it's still in development, it has glitches. OTOH though, game itself, i.e. the actual universe with its complex phenomena, characters, logic, etc. and their inter-dependency is better "sculpted" in C++. That's not to say you couldn't do all that in languages like GDScript or C#.

I don't know about you or other folks but my satisfaction doesn't come from just seeing my game finished already. It comes from the technique of making it. Imagine you go on a trip in a country by car. Now imagine instead you'd take the train. See my point?

More specific: I left Unity because C# felt short of features. There wasn't a time that I wouldn't need one feature or another that C# just didn't have. I needed pointers or at least &-type references. Then I needed macros, operator overloading. I don't even mention pure functions, const functions, free functions... it all boils down to power and freedom at your fingertips.

And let's not forget that C++ is the standard language in game industry, with 85% of jobs listings requiring C++ knowledge.

About actually using C++ in Godot:

setting the GDNative environment [...] you do this once.

I'll cling on to this statement and go back to read the C++ docs again. But still, workflow is what's unclear to me: I want to have (C++) scripts at least for every scene (if not for every node), for encapsulation reasons, right? Doesn't this mean I'd have to write glue code all over again for every script I'm making? Cause this is really daunting. It implies too much unwanted code. Can't this extra code be automatically generated and be hidden from the user (like in the Unity project I mentioned)? This way the user wouldn't have to mess with the insides but would just write actual functional code.

And another problem, perhaps more stringent (from what I can tell from -here-) is that the C++ lib you make is just a collection of methods and properties and the actual manipulation of these takes place in GDScript anyway.

Please, I want to try it but it's a total mishmash in my head. I need more help from you, Bishop or anybody else who knows about the process.

I have poor skills on programming, and honestly, I don't like doing this. But I admit that it gives a pleasant feeling of accomplishment when you get something to work.

I tested the Nim bindings, but from what I understood, all GDNative bindings have common files:

-The "godot headers", the Godot API in C code. Since the pure C is still the king of all languages, most languages can talk with a C library with reliability. That's made possible to script Godot with many different languages.

-The languages bindings. Godot headers are generally found in the same repository.

-The "natives scripts", created with two mouse clicks in the Godot editor.

-The "GDNativelibrary" resource, created easily in Godot too.

-A compilation script. You will run this file to compile your scripts. But you must respect the directory organization recommended (for example all your cpp script must stay in a "src" named folder). If you want to place your Cpp files elsewhere you need to understand this script in order to update the filepaths. (that's the annoying thing for me.) Edit: This script is provided by the binding.

-The library you will create by compiling your C++ scripts. It's a single binary file per platform.

-And of course your native scripts source code in cpp or whatever. The class must have the same name as the one specified in the native script. That's why Godot can found your code.

Depending of the languages bindings, some additionnal stuff may be required but this should be documented in the readme.

I tried to show that chain in a quick diagram. Sorry if the naming is not very accurate. (English isn't my native language). Binaries are in blue and text files are in green.

When you run your project, your compiled scripts (the library) are dynamically linked to Godot, and no GDScript is required. (but you can use GDScript to call your library if you want).

I don't know about you or other folks but my satisfaction doesn't come from just seeing my game finished already. It comes from the technique of making it. Imagine you go on a trip in a country by car. Now imagine instead you'd take the train. See my point?

I understand that. Games engines hides all the technical stuff to accelerate the creation process. But if you love to code you will be frustrated, even GDNative follow the path defined by the engine.

You can solve this by trying a little project without any game engines. The SFML C++ library might interest you. Or if you feel adventurous you can even try more low level libraries like Open GL, PortAudio, and dealing directly with the OS. With that you will become a master of game programming. I apologize if I wrote bad english.

Thank you very much NeoD for your time, effort, and knowledge! In the past I've also tried the "from scratch" approach, namely C++, OpenGL and GLFW. I didn't get to code much when I realized it wasn't taking me too far. So I ditched it in favor of an engine.

As for how low/high level I would go with Godot, I want to use the editor as much as possible and according to the intended Godot workflow, i.e. the GDScript way. I wouldn't change anything. Well, except for the language. But even if it deviates from that way, still the next choice closest to it is GDNative. So this is what I'll use.

With a little arrangement like for idiots that don't know anything about language binding (like me), that post of yours should be added to the official documentation.

5 days later

I'm fumbling with the process. I'll postpone C++ coding and I'll wait till somebody makes a start to finish tutorial (1) for Windows, as in MSVS 2017 (2).

Indeed that GDNative setting is really terrible. You can open an issue on the binding repository. Just explain how to reproduce the issue the developer is a kind guy.

meh... I don't feel that confident, to open an issue :# It would be like challenging their work.

25 days later

Hi everyone,

at the moment I’m diving into GDNative myself and while searching for the topic I stumbled on this threat. Since I already got the basics to work, I felt compelled sharing some resources with you.

In order to interface with the GDNative API , wich is written in C, you'll want to check out the “godot_cpp” repository in GodotNativeTools: https://github.com/GodotNativeTools/godot-cpp

The readme contains the basic steps needed to compile your own code. On windows the section about “Compiling” isn’t that helpful. I used the following commands in the VS Command Prompt for the tutorial:

> cd <workspace root>
> cl /Foinit.obj /c ./src/init.cpp /nologo -EHsc -D_DEBUG /MDd /I. /I.\cpp_bindings\include /I.\godot_headers /I.\src
> link /nologo /dll /out:.\bin\libtest.dll /implib:.\bin\libtest.lib init.obj ./lib/godot_cpp_bindings.lib /libpath:.\lib

* The compiler flags are adjusted for the godot_cpp debug build, which is the default.

Pretty much the same tutorial as in the readme of godot_cpp can be found on the FrogSquare Blog with some additional visual aids >here.

[Edit:] Just now I found an additional windows specific tutorial, linked in the godot reddit. Redit Post Tutorial by willnationsdev [/Edit]

Hopefully this helps you or others to make the first steps.

Just some side notes: If you don’t already compile the Godot executables yourself, chances are you don`t have scons installed. How to do that is shown in the Godot docs >here. In that same documentation you’ll learn how to find and use the Visual Studio Command Promt for compiling.

[first post in this forum]