When to use c++ ?

kishy_nivaskishy_nivas Posts: 7Member
edited July 2017 in Programming

are there any examples,where critical parts are coded in c++ ? or full game in c++ ? Thanks


Tags :


  • kishy_nivaskishy_nivas Posts: 7Member

    or is GDscript alone is enough for making most games ?

  • CalinouCalinou Posts: 144Admin Godot Developer
    edited July 2017 Answer ✓

    or is GDscript alone is enough for making most games ?

    It is enough for making most games indeed. While GDScript is slow in comparison to C++ or even C#, it is plenty fast for most tasks that don't involve number crunching or stuff like that. (Also, GDScript is faster in release-mode exports since no debugging checks are made.)

    Godot 3.0 will introduce GDNative, making it possible to bind lots of other languages to Godot (provided someone wrote a binding for it, or you are willing to do so). Godot 3.0 will also add support for C# using Mono.

  • whooshfrostedwhooshfrosted Posts: 30Member
    edited July 2017 Answer ✓

    This fellow teaches Godot at a game dev school in Germany, and has some interesting things to say about this subject:


    Another thing to keep in mind is that like most engines Godot offers more than one language and the decision which language to use for which part of the code plays an important role in creating readable code. In Godot's case there are three main languages to choose from: 1. C++ for backend code 2. GDscript for imperative game code 3. The editor interface for declarative game code.

    Your priority should always be: use 3 whenever possible, use 1 when 3 isn't enough and your code can be written in a non-game-specific way and use 2 only as a last resort.

    You mentioned gravity, movement and animations as examples. If your game object has gravity you should express exactly that in your code. "My object has gravity" is a declarative expression, since it doesn't describe how something is done, it just says what the outcome should be, so you can closely express the sentence by using a physics body node in your scene. The same applies to animations which you can program by adding an animation player node.

    The interesting question is what to do when the built-in nodes can't be configured to behave the way you want them to. I understand that the first idea will be to just add a script to the player, but when you think about it it's not the player you want to modify, you just want to modify the physics object your player is using. Also as I said if you are going for clean code you should try to implement as much as possible in C++ rather than GDscript. Anything that can be reused (and a modified physics object sounds like a likely candidate) should be written in C++ since code reuse implies that it's either a different person reusing the code or it's been a long time since the code was written, so you need language features that allow you to make the interface more expressive, like visibility modifiers or namespaces.

    GDscript does not have these features because game code should be written as short and (non-programmer-)readable as possible, it should almost be like a paragraph that you could find in a game design document written by a game designer. The idea is that this language should be used for anything that can change when the game design changes, so it's optimized for fast prototyping. If a game designer decides that some core functionality changes it shouldn't take a long refactoring session to try how the new design feels.

    I know that in reality this is a bit much to ask. Writing code in C++ requires a rebuild of the engine (and learning C++ of course) which seems like a lot of work. I am convinced that it pays off in the long run (since you are constantly expanding the options of the engine speeding up following projects - and you are making it easier to debug the projects) but I sympathise with those that don't want to use C++. Nevertheless you should still separate high-level code from lower-level code.

    I would like to use C++ myself as I'm finding I'm bumping into some minor limitations of GDScript, but I will wait and see how GDNative turns out. My concerns with using C++ are compilation speed, ease of debugging and having to own the operating system my game code is compiled on.

  • SomnivoreSomnivore Posts: 96Member

    Scripting languages exist to create your game logic easily, like input to character movement, when to play a sound, what sprite to show at a given moment, and other high level stuff such as that; you'd use C++ if you need to create engine logic, like physics processing, or if you needed the functionality to play a particular type of audio file, or dictating how the engine would render a sprite to the screen.

    The reason for having two languages like this is that C++ is a beast, and not only do game designers/artists have a hard time taming it, but even seasoned programmers may be tired of having to wrestle with it; scripting languages make it easier to implement game logic, even though it is less efficient than C++, which is why it's recommended for use with non-critical code. The engine takes care of most of the heavy lifting already so you probably don't need to use C++ if you don't want to, but if there's something about your game that requires a lot of processing power (like random world generation as an example), you'd want to consider using C++ lest your game's performance suffer.

    I see where the guy discouraging the usage of GDScript is coming from; for example, in UE4, there is also a clear distinction between using C++ and visual scripting, and they encourage you to create certain generic features via C++ which you then hook-up on a case-by-case basis via visual scripting. It makes sense since you can then use that particular code later on in another project, as the code becomes infused within the engine itself; you have your own very personal version of that engine with features specific to the games you make (or maybe you'll contribute those added features to the main engine.) Thus, scripting is reserved truly for one-off logic, and even then you can probably think up some generic solution to whatever problem you're facing which can then be applied via the editor through changing of its exposed variables. Perhaps this would be the ideal approach, except again it leaves game designers and artists too reliant on programmers to create functionality (and without a paddle if one is not present); it also leads to spending extra time ensuring a part of your code can be reused easily, when in reality you may never use that code again, or use it so sparingly that the time spent factoring and refactoring was for naught. There is another parallel: UE4 also asserts that an entire game can be created using only visual script, and they have proven that it is possible, with IIRC only a ~10% performance loss compared to pure C++. Again, this is primarily to appease non-programmers, as it makes it much easier for them to create games.

    I think the inclusion of C# will be a nice compromise on that front; it's not too difficult for game designers/artists to learn (I was able to pick it up, anyway), it's reasonably convenient to create game logic in, and it comes with all the features you'd need for code maintenance and extensibility like access modifiers and namespaces.

  • memermemer Posts: 39Member

    From what I've noticed recently you are basically required to use C++ if you want to use a custom network protocol, instead of put_var / RPCs.

Sign In or Register to comment.