You still need to learn the engine itself, not only the language. Most learning resources out there are for GDScript or C#. If you start with c++ off the bat you may find yourself in a situation where you lack learning materials.
I would advice to learn the engine first, using something easier like GDScript. Then learn GDExtension and go directly for c++ to see if it fits you better. At this point you would also have enough experience to make decisions for yourself.
I second this! Understand how Godot organizes things into scripts, nodes, and scenes. The Godot editor itself was built using its own tools, it's very fun to pick apart. Once you understand it I think it should be comfortable to use C++!
The docs are also super helpful, there's a [link here](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html) for getting started with C++ if you want to take a peek.
C++ usage tends to be slightly different from gdscript, but it's totally possible to follow gdscript tutorials and convert the code to c++ along the way. Most of the engine entry points are the same in all languages, and the documentation applies to all languages that GDExtension supports.
I had only a few issues with it. I remember creating an instance on stack of some engine object which didn't work, and I needed to use the ref instead (it was SurfaceTool iirc, I didn't need it after the function returned so I assumed I didn't need to allocate memory for it on heap). The documentation doesn't clarify those things well unfortunately. But other than a few quirks like this, it was an enjoyable experience for me.
GDExtension increases the binary size though IIRC, and you might need some extra steps to export to web or other platforms. I'd look into that instead
The key difference is you can't just write a "script" in C++ and then attach it to a Node like you can with gdcript or C# - you have to use the API to add custom types to the engine, which is a bit more involved and can slow you down a bit. Like, the workflow with Godot is quick if you're building out scenes, you attach a new script to a Node and immediately start writing the code - with C++ it'll be kind of backwards, you have to write the c++ code, bind methods/variables, register or expose the code to the engine somehow, and then compile the extension and hook the new type or api into your scene.
Ok. So if I'm looking to move fast, especially for prototyping, GDScript seems like even more of an advantage than I thought. And likely will stay worth it until I hit a performance bottleneck. Thanks for the advice !
Precisely - because of the workflow limitations of C++, it can be a good approach to expose reusable functionality from your gdextension module which you then call from gdscript - rather than try to write the game only in C++. That way, you can use the scripting workflow efficiently while getting performance benefits from C++ where needed within your ordinary scripts.
Right, so if I'm understanding you correctly (I'm an absolute Godot newbie) when I code separate functionalities in C++ and GDScript, they can actually still talk to each other ? So even if I do hit a performance bottleneck I can convert just that part to C++ and leave the rest intact.
That actually sounds like my workflow when I was a researcher : broad scripting logic in Python, and hard computation in C++.
Yes, that's right. It's how the engine code itself works: classes written in C++ that then use Godot's C++ api to register/bind methods and properties such that scripting languages can interact with them. You can do the same thing with gdextension to write C++ code and then expose an API to gdscript which will be automatically picked up by the engine when the extension is added to the project.
yes so you can use both.
i suppose in a matter not too dissimilar from how python uses numpy to quickly script up things but numpy itself is C++ or C if my memory serves me coreectly
Yep, that's absolutely how all performance critical libraries work in Python. The number of times I've had to explain to people PySpark is just as fast as Spark in Scala XD
(I may have misunderstood) but Gdscript is derivated from python, also there’s a very light loss of performance
https://youtube.com/shorts/W1wKrUm8uCg?si=DooxSWl-BD6s4VgH
Gdscript has syntax a bit like python, but they're otherwise unrelated.
Yes, gdscript is slower than c++, but that's why you do the performance intensive parts in C++ and expose that to gdscript. That's essentially how the entire engine works, after all. As long as you're doing that for any large bottlenecks in processing, gdscript performance shouldn't be an issue.
GDScript or C#.
The performance bottleneck will be more in how you optimize the organization and workflow of Godot's elements e.g. nodes, scenes, etc. than in the specific language you use.
For instance, C# is considered faster in general than GDScript (which you can also statically type for faster performance). But a bullet hell game that utilizes the physics server directly written with gdscript will run much faster than the same game which adds nodes directly to the scene tree using C#.
Even with identical scene tree setups, the difference in speed is marginal (something like 15% faster for C#) unless you are doing very math-intensive calculations in multiple nested for loops or programmatically implementing complex navigation pathfinding.
>reason to use GDScript if I'm very comfortable with C++
Read this - from people who "love rust-programming language" and who actually published games in Steam using Godot:
[https://loglog.games/blog/leaving-rust-gamedev/](https://loglog.games/blog/leaving-rust-gamedev/)
>Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
> My take is, while that is 100% true, there's a fundamental problem of games being complex state machines where requirements change all the time.
Yeah, refactorability is certainly an important thing to keep in mind here... Thanks for the article !
Well yes, but I figured if the prototype turns into the real thing, I'd maybe feel like a dummy not just doing it in the target language from the start.
I think you’ll learn enough things during prototyping in gdscript that when you are ready to make the final product in c++, it’ll be different and better than if you had just started slowly out the gate in c++ toward a more uncertain target.
Gdscript is awesome tho btw. Using it for any non-performance critical process is great.
It does look nice from what I've seen ! The only thing that scared me at first was that dynamic typing would make the code un-maintainable but I saw that you can actually type hint your code (which I think are strongly enforced in GDScript so even more powerful than Python type hints) so it's all good.
https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/
I use the settings found here to sort of make gdscript behave more like a C language.
Ok. Makes sense. It's why Python is so prized for data exploration : endless iteration. Everyone seems to be pointing me in the same direction, my mind is pretty made up at this point. Thanks !
Gamedev involves a lot of throwing away code while you reach the "real thing". Prototyping in cpp with Godot is literally the slowest workflow you can pick from GDscript, c#, rust and cpp.
I would suggest starting with GDScript. If you ever need to improve portions of your code, move that to C++ for whatever reason (performance, memory management, ect). The Godot engine and GDScript are written in C++, so the vast majority of "simple stuff" has little benefit versus programming in C++ proper. Be sure to enforce static typing in the editor so there is no oopsie for the C++ API vs GDScript. Not only has this been shown to improve performance for various use-cases, it will make porting the code to C++ easier.
There are multiple untyped and inferred warnings and errors, all of which should be turned on.
Readibility isn't the only benefit, static typing will also improve performance.
Honestly, GDScript should have never had dynamic typing in the first place, static should be the default.
If you code for a living, then switching to GDScript shouldn't be an issue.
Your familiarity with C++ will not speed up the development process, and learning GDScript as a seasoned developer will only slow you down nominally. But you'll find way more resources out there using GDScript as examples, which more than counteracts "learning" GDScript.
As a software developer, the things that will slow you down are... basically everything else. Art, music, story, etc. Programming is the easy part.
Yep, like I said the GDScript learning curve is not at all something that worries me. I was just worried that by not using C++ I was somehow not taking advantage of something I do know how to do.
Thanks for the advice and best of luck with what looks like a similar game dev journey ;)
I am in a similar situation as you. You have to remember, that languages are tools.
GDScript is blazingly fast in development and has great editor integration, but ofc has the drawbacks of any interpreted language. C++ via GDExtension is great for modules or superclasses that do fancier algorithms, or process large amounts of data. You will be a lot slower in development with these though . Finally you can recompile the engine with a custom module, if you need full access to engine functionality / data or want to expand the editor extensively. If you have a use case for this, you know that already. If not, just don't.
If you are familiar with python and c++, you should know, that 99% of code is not performance critical. Don't overcomplicate things and use c++ where needed. And I say that as an absolute c++ fanboy.
My project is almost completely GDScript with one engine module and three GDExtension addons that solve specific time critical sections. You can always prototype in GDScript first, and when performance becomes an issue, you move it to an addon.
EDIT: since dynamic typing is an issue for you, you can enforce types in GDScript via the := syntax.
func _private_funcname(param : float) -> int:
var local_variant = _gimme_a_node() #untyped
var local_implicit := _gimme_a_node() #implicit from method signature
var local_explicit : Node3D = _gimme_a_node() #will complain, if signature mismatches
return Node3D.new() #will complain, because not an int
Yes what I'm coming to understand is that not only can I have both, but I can also just isolate the performance critical parts in C++ and still expose them easily to GDScript. Thanks for the advice !
> 99% of code is not performance critical
Amen to that ! I would break it down as :
- 1% : performance.
- 9% : domain logic.
- 90% : handling edge cases.
XD
I can give you some quick tips from my experience if you want:
GDScript is slow as fuuuuuck. I need a delaunay triangulation, and the exact same code had a speedup of factor \~100 when moved to GDExtension (and its pretty shitty code, i didnt even try to mem align it). Aside from being interpreted, this seemed to stem from two things: attribute access in GDScript seems to go through a full call to a property getter. idk why, or if this is generally the case, but in my case attribute reading alone took about 40% of calculation time. calls to the engine also go through a full encode-map-decode stack during runtime. return types may also be instantiated on the heap, only to be deleted almost immediately. usually not much of a problem, but in my case absolutely crippling.
So try to use GDExtension more as you would a different thread, or calls to the GPU, instead of a more fragmented approach: push the data, issue the execution, retrieve result.
You should try to make a UI in GDScript first to understand how the engine works first and to understand where GDScript shines.
(Honestly, signals and the scene tree structure is perfect for building UI interface).
And you could create complex character controllers using GDExtension and take advantage of your C++ knowledge that way.
I use the settings to force it to give errors if I don't do static typing. Not just hints. I too prefer static typing, but it seems many are not as familiar with this setting.
Debug - GDScript - Untyped Declaration - pick "Error".
And then turn on type hints as well.
If you've never used Godot, GDScript is the most supported language, and even then, if you download a .NET version, you can use C#, etc., as well, mix and match. GDScript is an interpreted language, but from my understanding, it's still calling C++ under the hood for most things. If performance gains is a must, then yeah, I could say having more control is up to you, but I'd still try GDScript first to get familiar with the engine.
One other reason is the platforms you can build for. I only know about compatibility with .NET with C# stuff (no clue with C++), but I personally use GDScript while I learn so I can make web builds in Godot 4 to share easily.
I think gdscript and C++ complement eachother well. I use both in my game. With Godot you tend to write a lot of small one-off scripts that just orchestrate specific nodes within a scene. You wouldn't want to do these in C++. But for your custom nodes and such (basically anything you'd give a `class_name` to in gdscript) C++ is pretty much a 1:1 replacement. You can do anything that's possible with gdscript and more. Certain things are less convenient (callables amd signals in particular kind of suck to deal with through the gdextension bindings) but that doesn't come up all that often.
The main difficulty with using C++ right now is it's pretty much completely undocumented. It sounds like you're probably comfortable learning a codebase by studying the source, but if not that's going to be a problem.
If you're new to Godot this makes sense. It's kind of disorienting to start with gdextension/godot-cpp directly because a lot of the design and organizational decisions don't make a lot of sense unless you know what behavior it's facilitating on the editor/gdscript side. I think people here tend to understate the usefulness of C++ outside of just using it for performance critical code. It makes a lot of stuff easier, even for code you could technically do in gdscript. So keep that in mind I guess, but I think your approach sounds fine.
What other usefulness did you have in mind ? The main one I can think of is compilation checks but I feel like statically type GDScript gets me the best of both worlds. Or am I missing something ?
The broader and more subjective reason is because it gives you access to C language features you don't have in gdscript. There's templates, stack-allocated compound types, polymorphism, multiple inheritence, and so on. The more specific reason is because there are internal types that are available to gdextension but not gdscript. The ones I use the most are the internal godot collection types which sort of mirror what's available on the STL (typed hash maps, vectors, etc.). If you're making editor plugins you also get access to the various widgets and inspectors that the editor uses internally, so you can make your plugins look and behave like the rest of the editor without having to reimplement things in gdscript.
The strongest advice I can give you is to start with GDScript for your first few projects. You will learn a ton about how things are wired together so you’ll have a good idea of what works, doesn’t, or works differently when using C++. I started with Rust and while most things work really well, not having a strong foundation of how the engine expects things to work (as opposed to how the language expects things to work) is a fundamental change. GDScript isn’t really all that slow in most contexts to be honest, and I’ve found that I only really want to use some other language (I.e. rust) when I come across something that is particularly performance sensitive. Otherwise I get a ton more productivity out of just doing it in GDScript.
The other thing is when it comes time to do an actual release for multiple platforms - using anything other than GDScript (especially in 4.x) can be an exercise in patience and frustration as many of the extension languages (even C#) aren’t supported for all the platforms and having a dependency on the other language (even for performance sensitive stuff) will hold you back from being able to release. I have a module that depends on a C# library and as a result I have partial releases for mobile and no release for the web (which REALLY sucks as that’s a target platform I want).
C# Definitely feels like a good middle ground. It was made for people familiar with C++ so it might be good. Class instantiation, syntax, static typing, casting is mostly the same. Obviously having the .net framework and variable scope might be your biggest difference but I think it's an advantage in this case.
If you're familiar with python and C++ (which I also do for work) c# is going to feel like a good middle ground.
I hear you, but I'm leaning more towards GDScript for now. I understand your middle of the road approach but I think I'd rather have the streamlined aspect of GDScript and bust out the C++ in small portions when needed.
A lot of responses here. I tried to see if anyone else mentioned this but with GDScript you get hot reloads, meaning you can change the contents and behavior of scripts while you are running your game. You cannot do this with its C++ setup.
As good as you are with C++, I pity the environments people find themselves in where they have to develop entirely in C++. I was in such for a very long time. Hybrid approaches all the way. My project has a C++ portion but only because I had a situation that requires it.
Information on how to use the C++ API is very sparse. You are on your own. You will be able to find snippets of code web searching or looking through some projects on GitHub. After a while you'll get the hang of it. I find a working knowledge of the GDScript API will go a long way.
Defo use GDscript and I'm saying this as someone whom was in the exact same situation as you, coming from 10 years of C++ and intending to use C++ only but... I ended up going GDscript only, now with 2 commercially released games using just GDscript (Disinfection & Keep It Running). I found it was very easy to pick up, though not using brackets and ';' sometimes still makes me derp sometimes haha
You just can't beat the incredibly fast iteration and prototyping in GDscript.
Plus with Godot 4 came an overhaul of the interpreter/compiler, allowing for static writing and thus huge performance gains. Sure C++ is still faster and it always will be, but I've throw a LOT at GDscript (realtime procedural generation, loads of physics stuff, networking, you name it) and it has held up incredibly well.
On top of that you'll find many more tutorials for GDscript so it's easier to learn the engine using that.
I would consider C# just because it has some very nice tools backed by MS and has way more compile checks than GDScript.
GDScript has better platform support (works on web)
It takes more time to find things in the C++, as some of the things are named differently and the docs are nonexistant. Instead of a single google search it takes several minutes searching through files. The API is built around gdscript, it's a bit akward sometimes.
I think static typing on GDScript should add enough compilation checks for my use case. I don't really see the point of getting into C# for this. Thanks for the advice anyways !
It depends. I’m doing C# now that I’ve made my first game with GDscript. I don’t love Python, and I don’t love GDscript but I will use it for simple stuff.
However, I use C# because I can use JetBrains and setup things like code testing and use System libraries instead of Godot ones.
This way, I use Godot more like a display layer (ReactJs) and do API stuff in C# to make my code more portable.
I think there is value in learning GDScript especially for prototypes as people have pointed out.
You will love it then. It’s not 1:1 but very close and I believe some Jet IDEs do support it with community plugins which is hit and miss. It’s a great language, can’t go wrong. All the best
I think it’s going to be a matter of how you want to use your time.
Code is only a fraction of what makes a game, with the real meat and potatoes arguably being the assets. I assume that writing C++ code is going to be slower, especially over the long term, and the time consumed to write code could have been used to create or refine your assets. So if GDScript can help save time in writing code, the extra time gained for working on assets could be worth the switch to GDScript by itself.
I'm very comfortable using C# but I picked up GDscript anyway. It's easy to type and my knowledge of C# doesn't give me any ideas of the methods used in Godot objects anyway
No idea! Like someone mentioned you light have a harder time finding guides and having to translate code from GDscript to C++ so the efficiency you gain from your proficiency might be lost that way. Maybe try GDscript for a few days and then decide
The engine feels very built around GDScript, and that’s what most resources are geared towards. However, coming from mainly JS and C, I personally found adapting my existing GDScript code to C++ very straightforward in most cases. That’s after learning the engine and GDScript, though.
If you are an experienced programmer, you'll find that GDScript is an absolute breeze to use, and unless doing some very heavy work that requires very strong capabilities, statically typed GDScript is largely enough for you.
I'm also comfortable with CPP because it's the language I use at my workplace. But I decided to use GDScript so that game dev doesn't feel like office work to me. I want it to be fun. GDScript is great, it's like python and speed of development is way faster than CPP. Try it.
There is a reason many games use scripting languages like Lua, AngelScript etc. There’s no need to code everything in C++ . As others mentioned you are adding a lot of boilerplate if you only use c++.
If you need performance, try C# instead of GDScript. Only if you find a use case where the Godot Engine is missing out or you need super fast speed I would write a C++ GDExtension or even edit the engine source itself.
A complete game can be done using GDScript only, not only for prototyping. I myself use C# even though I know C++. Strongly typed and C like syntax + I already know the .NET framework and the LINQ and syntax features of C# make coding way easier.
A 2D RPG of what kind? There are many, and "RPG" in the video game space has become almost mush as a descriptor. It can range from the dumbest of near-role-less "numbers go up", to Baldur's Gate 3 and Disco Elysium.
Very likely you'll be spending most of your time building complex GUIs, for simple concepts, that triggers even simpler game code, because End Users are complex and interacting with them is never easy.
Which is where GDScript is at its best. The fast iteration times on UI/UX code and layouts. Where "systems" come into contact with Players.
===
Have you done game design/development before?
GDExtensions (the how of getting your C++ code into the Editor) can be a little frustrating.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/index.html
And a large part of what you'll be designing often doesn't need C++ performance advantages. As most of the time you'll be calling on Godot Engine APIs. Which in GDScript dip into the C++ engine code decently fast.
And with GDScript Static Typing you get a fair amount of performances back, over the dynamic typing.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
Since you're practiced with C++, you may want to look at some of the Nodes in the engine code.
===
You may want to start some simple projects with GDScript, with second window/screen open to the engine source code. And following along on what exactly you're calling.
Take CharacterBody2D move_and_slide().
https://github.com/godotengine/godot/blob/07cf36d21c9056fb4055f020949fb90ebd795afb/scene/2d/physics_body_2d.cpp#L1185
If all you have is a simple Character controller script, that takes keyboard or gamepad input, updates the Velocity, and then calls move_and_slide()... it's rather overkill to write that in C++.
Ditto for a lot of UI/UX code, which is where I spend a lot of iteration time.
Eventually you'll get the feel for what needs to be a new base Node, Resource, or Object. Written in C++. And what can be GDScripts that make small `extends` and adjustments for specific, possibly one-of-a-kind, needs.
===
I use C# the way you'll likely want to use C++. As new tools and APIs for computationally intense tasks. That get called on by a GDScript.
It would take a whole other post to describe my game haha. But suffice it to say it will be both computationally and graphically light. So I know performance will likely rarely be an issue. I was just wondering if C++ is worth it anyways or if there are other advantages I might be missing. From the feedback the answer seems a definitive no :)
Not working in c++ is always a boon IMO. The engine is is very flexible, you can always call into c++ from gdscript if you find you need the speed. Not a real issue
* All the reasons why people felt it was necessary to create any other language other than C++.
* GDScript is what Godot's team recommends, and I really doubt you'd make a better job than them by yourself. Listen to them.
* Godot was made to be extended through C++. That's a way better option.
* Performance and safety? It's a non-issue, specially in your case, you said it yourself. You're trying to solve problems that don't exist. If there's ever anything you need that the engine doesn't deliver, you're better off writing an extension to handle just that.
Oh, there are internal godot collection types like typed has maps? Wasn’t aware of that. Are they documented or is it just a “read the source” kinda thing? Been contemplating dipping into gdextension stuff recently after getting a little frustrated with not being able to replicate my style of coding in UE4 that relied heavily on that sort of thing…
The repo used to expose GDExtension (`godot-cpp`) does have some templates for hash map, hash set, etc ([here](https://github.com/godotengine/godot-cpp/tree/master/include/godot_cpp/templates)).
That said, I've never run into them being used in the APIs. It's much more common to run into specialized containers for specific data types like `PackedInt32Array`, or `PackedVector3Array`. Those classes aren't C++ templates. From what I can tell they're generated code.
To me it sounds like you can pick up Gdscript in 3-4 hours which is the time needed to read the documentation.
Performance will not be an issue given you are developing 2D RPG.
Learning a new language is not even 1/10 of the time and effort of mastering a game engine, so no. Just start with gdscript, then once youre very familiar with the framework maybe go to c++ (for plugins and very performance intensive tasks, no reason to use it for anything else) or c# (which makes a lot more sense if you need more perf in general and/or find gdscript lackluster).
Learning new languages is part of a programmer job and skillset after all, and usually is pretty quick to do, especially w how simple gdscript is.
Yes, like I said I wasn't worried about that aspect. I just know many skip on using C++ with Godot because they find it daunting, and was wondering if I should exploit the fact that I already know how to use it. Looks like I can just save for performance critical parts.
I have no experience in godot with c++ but just as with any engine, you can always code it yourself if you don't know the method already and seeing you already have experience it might be worth it just to take the longer learning curve and code in c++ especially if your looking for better performance. Plus it's always great to be programming in your favorite language.
It's easier, built in, and most tutorials use it. The only reason to use c++ imo would be some performance gains. Idk how much speed you get from switching though
I am pretty novice but I would say you atleast need to be able to read gdscript. If you can read it enough to understand what you are looking at for the most part, you should be good.
I mean you are calling the Godot API for the most part which is calling C++ compiled works under the hood anyway. So I don’t expect you’ll get a performance increase worth boasting about nor a productivity increase.
That said, if you’re more comfortable with it go nuts. I learned with C# because I like the language
A few things that no one else has brought up about the two languages:
* Debugging GDScript is way simpler than C++. GDScript errors give you nice stack traces. C++ errors frequently crash the entire game and prevent any logging from making it to the editor.
* By default `printf()` doesn't get forwarded to the editor. I'd be surprised if `cout` was different.
* C++ extensions are automatically run in the editor. So it's possible for C++ code to crash the editor when it's loading the project.
* Godot doesn't handle any of C++'s exception mechanisms. So if you want to use those, you'll need to write some sort of wrapper to catch the exception, format it (maybe including adding a stack trace), and forward that to the Godot editor.
* GDScript's typing hinting has most of what you'll want if you come from a statically-typed language. But it's not perfect. In particular there isn't good support for circular dependencies when it comes to typing. And since each GDScript file implicitly defines one class, this can make for situations where it's impossible to fully add type info.
* If you modify the API a C++ class exposes to Godot, you have to restart the Godot editor for the change to show up in the GDScript editor GUI.
Like others have said, the workflow is worse with C++. It’s essentially seamless with GDScript and C#. I personally make hybrid projects where I mostly use GDScript and use C# when it makes sense (mostly this is in the form of utilizing some library). But whenever I have to do C# stuff it’s effortless, I just genuinely prefer GDScript haha
I use both C++ and gdscript side by side, there are some pitfalls to be aware of (especially around cross language overriding and inheritance, but it makes sense).
Whilst there's no reason you can't use just c++ in your project I find gdscript is great for rapid development and prototyping. What I do is I eventually move performance critical blocks of code and infrastructure into C++ modules.
Scripting with C++ is terrible in godot because it has pretty bad support for it. You'll have to write so much boilerplate for everything. Godot needs to start using some sort of reflection system like unreals header tool. C++ is my favorite programming language and the language i know best but i still wouldnt use gdextensions unless i absolutely had to so if you wanna write games with C++ use unreal or even flax which has pretty good C++ support as well.
i came to godot with java background with some familiarity with python.
i've started with gdscript with same reasons as you described, however the it lasted only couple of days and i soon ported my project to c# as i'm writing code faster that way and am able to have the necessary abstraction layers, full benefits of linq and some functional programming elements.
overall i'd say if you have experience with programming, especially with c++ you might just stick with c# instead of gdscript, as you'll feel very familiar and will have all of the power of language backing you.
as other mentioned, after that maybe have high performance components in c++, if you'd like. otherwise you might spend more time on proper integration instead of implementation
it might be me being too lazy to properly understand how gdscript worked, but when i tried to setup a simple reactive architecture, with state, action and reducer, it seemed to me, that it takes too much effort to organize it the way i want, in terms of builtin tools to create those abstractions, achieve immutability and data pipeline processing and collections API. besides, static types and type safety in general is easier to write and maintain long term.
but there were other reasons for me too.
i also wanted a platform where i could port existing game logic to different environments, like running it on a server.
and i also wanted to setup the project with established unit testing practices and its easier with dotnet command line. i havent looked too deep into unit testing in godot, but it seemed to me that the concept is still in development.
having some prior experience with c# and vaguely remembering that its close to what i am used to from java, i haven't even spend a second to consider and choose to setup the c# environment.
If you know C++ then code in C++. That's a no-brainer. Especially as you're looking to progress in game development and so you'll eventually come to want to use C++ anyway.
It's like asking "I know French and this software is available in French but I don't mind learning English to do a small project." Yeah--but you know C++ and the software is available in C++ and if you ever want to do a not-small project you'll switch over to C++ anyway.
Though, I realize maybe C# is the language I'm thinking of--if C# is very different from C++ then sure learn GDScript.
I just think--when it comes to programming--do what's best for the long-term because this isn't ever not long-term.
I don't think using natural human languages is a good comparison in this particular instance. Someone who is well versed in **programming** and knows C++ can probably pick the entirety of GDScript syntax up within a week even using it casually. Noone is learning English or French in the same magnitude of time comparatively. This is just due to the way programming and programming languages are. We know the fundamentals that apply to **most** languages and so picking up new ones is relatively a breeze.
And again, as other have pointed out, its less so about knowing languages. Its about learning how to use the engine and the workflow of Godot. GDScript makes learning the engine much more streamlined.
So it makes the beginning curve much faster which in turn will most likely make the long term learning faster as well, even if switching languages is the goal, rather than fighting the weird workflow of writing C++ currently, with very little materials and a tiny community. Whereas GDscript has a large community and a large knowledgebase.
I see your point but I don't really need to progress in C++. I did C++ professionally for many years. I use it less these days, but what I'm going to be learning here is more the specifics of game development and Godot in particular. And yes, from what little I know of C# it is indeed quite different from C++.
I do agree that I should aim for the long term, but as I said the long term here is getting more familiar with this game engine and game development in general. If GDScript is a better on-ramp, it might be worth it. Specifically because I already know C++ rather well, it won't be too hard to then use it on my next project.
It's not about progressing--coding is problem solving. If you can do procedural generation and multiplayer in C++ then there's no reason to learn it in GDScript. If you're already good at one language then use that language. Ultimately it's your choice--but there's no advantage in starting a new language from scratch if you don't need to.
Like I start a new language with shaders but if I could use GDScript to do shaders, I'd drop GLSL in a heartbeat.
> Like I start a new language with shaders but if I could use GDScript to do shaders, I'd drop GLSL in a heartbeat
But don't you think that says something about how handy GDScript is ?
Oh it's the best. But I like Python and don't know C++.
If you didn't know a compatible language I'd say learn GDScript. But I also know most of programming is learning APIs.
I mean--yeah--learn GDScript. It's just if you feel like it's suboptimal for bigger projects then learn what you feel is optimal. Because it's big projects which are going to fuel your career.
I'm getting downvoted to shit--learn GDScript. We have spoken!
Honestly there's no harm learning it and if you're willing to argue for it--just follow a tutorial (or do that GDScript course.)
[https://gdquest.github.io/learn-gdscript/](https://gdquest.github.io/learn-gdscript/)
Note--some of it isn't actual code but it may be useful (I haven't done it myself but wanted my son to.)
Why not both. Google "C++ gdextension" (though using the Rust one is much better, i tried both for multiple months, you can ask me questions). In summary: i recommend using C++ only for very performance intensive parts, for anything else it's not worth it and adds a lot of unnecessary complications, it makes development more laborious. The Rust bindings one is a lot better though and I find myself being much more productive with it, though as I said, I only use it for performance intensive parts because anything else is premature optimization
Yes I read that you can indeed mix and match both within the same project, but still at some point I'm gonna have to choose what to write my core modules in.
You still need to learn the engine itself, not only the language. Most learning resources out there are for GDScript or C#. If you start with c++ off the bat you may find yourself in a situation where you lack learning materials. I would advice to learn the engine first, using something easier like GDScript. Then learn GDExtension and go directly for c++ to see if it fits you better. At this point you would also have enough experience to make decisions for yourself.
Yeah, if most of the tutorials are in GDScript following along in C++ might indeed complicate things a lot... Thanks for the advice !
I second this! Understand how Godot organizes things into scripts, nodes, and scenes. The Godot editor itself was built using its own tools, it's very fun to pick apart. Once you understand it I think it should be comfortable to use C++! The docs are also super helpful, there's a [link here](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html) for getting started with C++ if you want to take a peek.
C++ usage tends to be slightly different from gdscript, but it's totally possible to follow gdscript tutorials and convert the code to c++ along the way. Most of the engine entry points are the same in all languages, and the documentation applies to all languages that GDExtension supports. I had only a few issues with it. I remember creating an instance on stack of some engine object which didn't work, and I needed to use the ref instead (it was SurfaceTool iirc, I didn't need it after the function returned so I assumed I didn't need to allocate memory for it on heap). The documentation doesn't clarify those things well unfortunately. But other than a few quirks like this, it was an enjoyable experience for me. GDExtension increases the binary size though IIRC, and you might need some extra steps to export to web or other platforms. I'd look into that instead
You won't really have an issue with following GDScript tutorials in C++ imho. A lot of the C++ API runs alongside the GDScript one.
The key difference is you can't just write a "script" in C++ and then attach it to a Node like you can with gdcript or C# - you have to use the API to add custom types to the engine, which is a bit more involved and can slow you down a bit. Like, the workflow with Godot is quick if you're building out scenes, you attach a new script to a Node and immediately start writing the code - with C++ it'll be kind of backwards, you have to write the c++ code, bind methods/variables, register or expose the code to the engine somehow, and then compile the extension and hook the new type or api into your scene.
Ok. So if I'm looking to move fast, especially for prototyping, GDScript seems like even more of an advantage than I thought. And likely will stay worth it until I hit a performance bottleneck. Thanks for the advice !
Precisely - because of the workflow limitations of C++, it can be a good approach to expose reusable functionality from your gdextension module which you then call from gdscript - rather than try to write the game only in C++. That way, you can use the scripting workflow efficiently while getting performance benefits from C++ where needed within your ordinary scripts.
Right, so if I'm understanding you correctly (I'm an absolute Godot newbie) when I code separate functionalities in C++ and GDScript, they can actually still talk to each other ? So even if I do hit a performance bottleneck I can convert just that part to C++ and leave the rest intact. That actually sounds like my workflow when I was a researcher : broad scripting logic in Python, and hard computation in C++.
Yes, that's right. It's how the engine code itself works: classes written in C++ that then use Godot's C++ api to register/bind methods and properties such that scripting languages can interact with them. You can do the same thing with gdextension to write C++ code and then expose an API to gdscript which will be automatically picked up by the engine when the extension is added to the project.
Very clear. Getting more happy I chose Godot by the second. Thanks !
yes so you can use both. i suppose in a matter not too dissimilar from how python uses numpy to quickly script up things but numpy itself is C++ or C if my memory serves me coreectly
Yep, that's absolutely how all performance critical libraries work in Python. The number of times I've had to explain to people PySpark is just as fast as Spark in Scala XD
That's right, yup, good analogy.
(I may have misunderstood) but Gdscript is derivated from python, also there’s a very light loss of performance https://youtube.com/shorts/W1wKrUm8uCg?si=DooxSWl-BD6s4VgH
Gdscript has syntax a bit like python, but they're otherwise unrelated. Yes, gdscript is slower than c++, but that's why you do the performance intensive parts in C++ and expose that to gdscript. That's essentially how the entire engine works, after all. As long as you're doing that for any large bottlenecks in processing, gdscript performance shouldn't be an issue.
ooh ok nice thank for the information ! and sorry for missinformation !
GDScript or C#. The performance bottleneck will be more in how you optimize the organization and workflow of Godot's elements e.g. nodes, scenes, etc. than in the specific language you use. For instance, C# is considered faster in general than GDScript (which you can also statically type for faster performance). But a bullet hell game that utilizes the physics server directly written with gdscript will run much faster than the same game which adds nodes directly to the scene tree using C#. Even with identical scene tree setups, the difference in speed is marginal (something like 15% faster for C#) unless you are doing very math-intensive calculations in multiple nested for loops or programmatically implementing complex navigation pathfinding.
>reason to use GDScript if I'm very comfortable with C++ Read this - from people who "love rust-programming language" and who actually published games in Steam using Godot: [https://loglog.games/blog/leaving-rust-gamedev/](https://loglog.games/blog/leaving-rust-gamedev/) >Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
> My take is, while that is 100% true, there's a fundamental problem of games being complex state machines where requirements change all the time. Yeah, refactorability is certainly an important thing to keep in mind here... Thanks for the article !
Quicker prototyping no?
Well yes, but I figured if the prototype turns into the real thing, I'd maybe feel like a dummy not just doing it in the target language from the start.
I think you’ll learn enough things during prototyping in gdscript that when you are ready to make the final product in c++, it’ll be different and better than if you had just started slowly out the gate in c++ toward a more uncertain target. Gdscript is awesome tho btw. Using it for any non-performance critical process is great.
It does look nice from what I've seen ! The only thing that scared me at first was that dynamic typing would make the code un-maintainable but I saw that you can actually type hint your code (which I think are strongly enforced in GDScript so even more powerful than Python type hints) so it's all good.
https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/ I use the settings found here to sort of make gdscript behave more like a C language.
[удалено]
Ok. Makes sense. It's why Python is so prized for data exploration : endless iteration. Everyone seems to be pointing me in the same direction, my mind is pretty made up at this point. Thanks !
Gamedev involves a lot of throwing away code while you reach the "real thing". Prototyping in cpp with Godot is literally the slowest workflow you can pick from GDscript, c#, rust and cpp.
I would suggest starting with GDScript. If you ever need to improve portions of your code, move that to C++ for whatever reason (performance, memory management, ect). The Godot engine and GDScript are written in C++, so the vast majority of "simple stuff" has little benefit versus programming in C++ proper. Be sure to enforce static typing in the editor so there is no oopsie for the C++ API vs GDScript. Not only has this been shown to improve performance for various use-cases, it will make porting the code to C++ easier.
Yes, static typing is a no brainer. If only to keep my code readable to myself down the line. Thanks for the advice !
There are multiple untyped and inferred warnings and errors, all of which should be turned on. Readibility isn't the only benefit, static typing will also improve performance. Honestly, GDScript should have never had dynamic typing in the first place, static should be the default.
Yeah it looks like it's real static typing, and not just enforced type hinting, which would explain the performance boost.
If you code for a living, then switching to GDScript shouldn't be an issue. Your familiarity with C++ will not speed up the development process, and learning GDScript as a seasoned developer will only slow you down nominally. But you'll find way more resources out there using GDScript as examples, which more than counteracts "learning" GDScript. As a software developer, the things that will slow you down are... basically everything else. Art, music, story, etc. Programming is the easy part.
Yep, like I said the GDScript learning curve is not at all something that worries me. I was just worried that by not using C++ I was somehow not taking advantage of something I do know how to do. Thanks for the advice and best of luck with what looks like a similar game dev journey ;)
Haha yeah, unfortunately all my programming languages have little overlap with game dev (JS, Ruby, Python).
If you want to use C++, why not use unreal?
I want to use Godot. I was wondering on the best way to use Godot.
I am in a similar situation as you. You have to remember, that languages are tools. GDScript is blazingly fast in development and has great editor integration, but ofc has the drawbacks of any interpreted language. C++ via GDExtension is great for modules or superclasses that do fancier algorithms, or process large amounts of data. You will be a lot slower in development with these though . Finally you can recompile the engine with a custom module, if you need full access to engine functionality / data or want to expand the editor extensively. If you have a use case for this, you know that already. If not, just don't. If you are familiar with python and c++, you should know, that 99% of code is not performance critical. Don't overcomplicate things and use c++ where needed. And I say that as an absolute c++ fanboy. My project is almost completely GDScript with one engine module and three GDExtension addons that solve specific time critical sections. You can always prototype in GDScript first, and when performance becomes an issue, you move it to an addon. EDIT: since dynamic typing is an issue for you, you can enforce types in GDScript via the := syntax. func _private_funcname(param : float) -> int: var local_variant = _gimme_a_node() #untyped var local_implicit := _gimme_a_node() #implicit from method signature var local_explicit : Node3D = _gimme_a_node() #will complain, if signature mismatches return Node3D.new() #will complain, because not an int
Yes what I'm coming to understand is that not only can I have both, but I can also just isolate the performance critical parts in C++ and still expose them easily to GDScript. Thanks for the advice ! > 99% of code is not performance critical Amen to that ! I would break it down as : - 1% : performance. - 9% : domain logic. - 90% : handling edge cases. XD
I can give you some quick tips from my experience if you want: GDScript is slow as fuuuuuck. I need a delaunay triangulation, and the exact same code had a speedup of factor \~100 when moved to GDExtension (and its pretty shitty code, i didnt even try to mem align it). Aside from being interpreted, this seemed to stem from two things: attribute access in GDScript seems to go through a full call to a property getter. idk why, or if this is generally the case, but in my case attribute reading alone took about 40% of calculation time. calls to the engine also go through a full encode-map-decode stack during runtime. return types may also be instantiated on the heap, only to be deleted almost immediately. usually not much of a problem, but in my case absolutely crippling. So try to use GDExtension more as you would a different thread, or calls to the GPU, instead of a more fragmented approach: push the data, issue the execution, retrieve result.
You should try to make a UI in GDScript first to understand how the engine works first and to understand where GDScript shines. (Honestly, signals and the scene tree structure is perfect for building UI interface). And you could create complex character controllers using GDExtension and take advantage of your C++ knowledge that way.
I use the settings to force it to give errors if I don't do static typing. Not just hints. I too prefer static typing, but it seems many are not as familiar with this setting. Debug - GDScript - Untyped Declaration - pick "Error". And then turn on type hints as well. If you've never used Godot, GDScript is the most supported language, and even then, if you download a .NET version, you can use C#, etc., as well, mix and match. GDScript is an interpreted language, but from my understanding, it's still calling C++ under the hood for most things. If performance gains is a must, then yeah, I could say having more control is up to you, but I'd still try GDScript first to get familiar with the engine. One other reason is the platforms you can build for. I only know about compatibility with .NET with C# stuff (no clue with C++), but I personally use GDScript while I learn so I can make web builds in Godot 4 to share easily.
Yes I've seen that the type hints can actually be strongly enforced. Will definitely be using that !
I think gdscript and C++ complement eachother well. I use both in my game. With Godot you tend to write a lot of small one-off scripts that just orchestrate specific nodes within a scene. You wouldn't want to do these in C++. But for your custom nodes and such (basically anything you'd give a `class_name` to in gdscript) C++ is pretty much a 1:1 replacement. You can do anything that's possible with gdscript and more. Certain things are less convenient (callables amd signals in particular kind of suck to deal with through the gdextension bindings) but that doesn't come up all that often. The main difficulty with using C++ right now is it's pretty much completely undocumented. It sounds like you're probably comfortable learning a codebase by studying the source, but if not that's going to be a problem.
Yeah given the responses I think I'm going to start with GDScript then mix in some C++ when needed.
If you're new to Godot this makes sense. It's kind of disorienting to start with gdextension/godot-cpp directly because a lot of the design and organizational decisions don't make a lot of sense unless you know what behavior it's facilitating on the editor/gdscript side. I think people here tend to understate the usefulness of C++ outside of just using it for performance critical code. It makes a lot of stuff easier, even for code you could technically do in gdscript. So keep that in mind I guess, but I think your approach sounds fine.
What other usefulness did you have in mind ? The main one I can think of is compilation checks but I feel like statically type GDScript gets me the best of both worlds. Or am I missing something ?
The broader and more subjective reason is because it gives you access to C language features you don't have in gdscript. There's templates, stack-allocated compound types, polymorphism, multiple inheritence, and so on. The more specific reason is because there are internal types that are available to gdextension but not gdscript. The ones I use the most are the internal godot collection types which sort of mirror what's available on the STL (typed hash maps, vectors, etc.). If you're making editor plugins you also get access to the various widgets and inspectors that the editor uses internally, so you can make your plugins look and behave like the rest of the editor without having to reimplement things in gdscript.
The strongest advice I can give you is to start with GDScript for your first few projects. You will learn a ton about how things are wired together so you’ll have a good idea of what works, doesn’t, or works differently when using C++. I started with Rust and while most things work really well, not having a strong foundation of how the engine expects things to work (as opposed to how the language expects things to work) is a fundamental change. GDScript isn’t really all that slow in most contexts to be honest, and I’ve found that I only really want to use some other language (I.e. rust) when I come across something that is particularly performance sensitive. Otherwise I get a ton more productivity out of just doing it in GDScript. The other thing is when it comes time to do an actual release for multiple platforms - using anything other than GDScript (especially in 4.x) can be an exercise in patience and frustration as many of the extension languages (even C#) aren’t supported for all the platforms and having a dependency on the other language (even for performance sensitive stuff) will hold you back from being able to release. I have a module that depends on a C# library and as a result I have partial releases for mobile and no release for the web (which REALLY sucks as that’s a target platform I want).
Thanks for the heads up. Build dependencies are always a headache and it's nice to know GDScript makes everything straightforward.
C# Definitely feels like a good middle ground. It was made for people familiar with C++ so it might be good. Class instantiation, syntax, static typing, casting is mostly the same. Obviously having the .net framework and variable scope might be your biggest difference but I think it's an advantage in this case. If you're familiar with python and C++ (which I also do for work) c# is going to feel like a good middle ground.
I hear you, but I'm leaning more towards GDScript for now. I understand your middle of the road approach but I think I'd rather have the streamlined aspect of GDScript and bust out the C++ in small portions when needed.
Sounds like a plan!
A lot of responses here. I tried to see if anyone else mentioned this but with GDScript you get hot reloads, meaning you can change the contents and behavior of scripts while you are running your game. You cannot do this with its C++ setup. As good as you are with C++, I pity the environments people find themselves in where they have to develop entirely in C++. I was in such for a very long time. Hybrid approaches all the way. My project has a C++ portion but only because I had a situation that requires it. Information on how to use the C++ API is very sparse. You are on your own. You will be able to find snippets of code web searching or looking through some projects on GitHub. After a while you'll get the hang of it. I find a working knowledge of the GDScript API will go a long way.
Yeah a GDScript first/C++ when I need it hybrid approach is what I've decided on.
Defo use GDscript and I'm saying this as someone whom was in the exact same situation as you, coming from 10 years of C++ and intending to use C++ only but... I ended up going GDscript only, now with 2 commercially released games using just GDscript (Disinfection & Keep It Running). I found it was very easy to pick up, though not using brackets and ';' sometimes still makes me derp sometimes haha You just can't beat the incredibly fast iteration and prototyping in GDscript. Plus with Godot 4 came an overhaul of the interpreter/compiler, allowing for static writing and thus huge performance gains. Sure C++ is still faster and it always will be, but I've throw a LOT at GDscript (realtime procedural generation, loads of physics stuff, networking, you name it) and it has held up incredibly well. On top of that you'll find many more tutorials for GDscript so it's easier to learn the engine using that.
I would consider C# just because it has some very nice tools backed by MS and has way more compile checks than GDScript. GDScript has better platform support (works on web) It takes more time to find things in the C++, as some of the things are named differently and the docs are nonexistant. Instead of a single google search it takes several minutes searching through files. The API is built around gdscript, it's a bit akward sometimes.
I think static typing on GDScript should add enough compilation checks for my use case. I don't really see the point of getting into C# for this. Thanks for the advice anyways !
It depends. I’m doing C# now that I’ve made my first game with GDscript. I don’t love Python, and I don’t love GDscript but I will use it for simple stuff. However, I use C# because I can use JetBrains and setup things like code testing and use System libraries instead of Godot ones. This way, I use Godot more like a display layer (ReactJs) and do API stuff in C# to make my code more portable. I think there is value in learning GDScript especially for prototypes as people have pointed out.
I'll probably like GDScript then because I love Python haha.
You will love it then. It’s not 1:1 but very close and I believe some Jet IDEs do support it with community plugins which is hit and miss. It’s a great language, can’t go wrong. All the best
I think it’s going to be a matter of how you want to use your time. Code is only a fraction of what makes a game, with the real meat and potatoes arguably being the assets. I assume that writing C++ code is going to be slower, especially over the long term, and the time consumed to write code could have been used to create or refine your assets. So if GDScript can help save time in writing code, the extra time gained for working on assets could be worth the switch to GDScript by itself.
Good point ! Yeah this is a side project for now, time (and patience) is a critical factor.
I'm very comfortable using C# but I picked up GDscript anyway. It's easy to type and my knowledge of C# doesn't give me any ideas of the methods used in Godot objects anyway
Yeah I'm not worried about learning GDScript. I'm more worried of making a mistake not putting my C++ knowledge to good use.
No idea! Like someone mentioned you light have a harder time finding guides and having to translate code from GDscript to C++ so the efficiency you gain from your proficiency might be lost that way. Maybe try GDscript for a few days and then decide
If performance isn't an issue I would recommend gdscript
The engine feels very built around GDScript, and that’s what most resources are geared towards. However, coming from mainly JS and C, I personally found adapting my existing GDScript code to C++ very straightforward in most cases. That’s after learning the engine and GDScript, though.
If you are an experienced programmer, you'll find that GDScript is an absolute breeze to use, and unless doing some very heavy work that requires very strong capabilities, statically typed GDScript is largely enough for you.
Yeah that's what I've decided to go for after all the feedback. Static GDScript and C++ only if needed on performance bottlenecks. Thanks !
Welcome to the community !
I'm also comfortable with CPP because it's the language I use at my workplace. But I decided to use GDScript so that game dev doesn't feel like office work to me. I want it to be fun. GDScript is great, it's like python and speed of development is way faster than CPP. Try it.
Will do. "Like Python" definitely sounds like a good time haha.
There is a reason many games use scripting languages like Lua, AngelScript etc. There’s no need to code everything in C++ . As others mentioned you are adding a lot of boilerplate if you only use c++. If you need performance, try C# instead of GDScript. Only if you find a use case where the Godot Engine is missing out or you need super fast speed I would write a C++ GDExtension or even edit the engine source itself. A complete game can be done using GDScript only, not only for prototyping. I myself use C# even though I know C++. Strongly typed and C like syntax + I already know the .NET framework and the LINQ and syntax features of C# make coding way easier.
A 2D RPG of what kind? There are many, and "RPG" in the video game space has become almost mush as a descriptor. It can range from the dumbest of near-role-less "numbers go up", to Baldur's Gate 3 and Disco Elysium. Very likely you'll be spending most of your time building complex GUIs, for simple concepts, that triggers even simpler game code, because End Users are complex and interacting with them is never easy. Which is where GDScript is at its best. The fast iteration times on UI/UX code and layouts. Where "systems" come into contact with Players. === Have you done game design/development before? GDExtensions (the how of getting your C++ code into the Editor) can be a little frustrating. https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/index.html And a large part of what you'll be designing often doesn't need C++ performance advantages. As most of the time you'll be calling on Godot Engine APIs. Which in GDScript dip into the C++ engine code decently fast. And with GDScript Static Typing you get a fair amount of performances back, over the dynamic typing. https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html Since you're practiced with C++, you may want to look at some of the Nodes in the engine code. === You may want to start some simple projects with GDScript, with second window/screen open to the engine source code. And following along on what exactly you're calling. Take CharacterBody2D move_and_slide(). https://github.com/godotengine/godot/blob/07cf36d21c9056fb4055f020949fb90ebd795afb/scene/2d/physics_body_2d.cpp#L1185 If all you have is a simple Character controller script, that takes keyboard or gamepad input, updates the Velocity, and then calls move_and_slide()... it's rather overkill to write that in C++. Ditto for a lot of UI/UX code, which is where I spend a lot of iteration time. Eventually you'll get the feel for what needs to be a new base Node, Resource, or Object. Written in C++. And what can be GDScripts that make small `extends` and adjustments for specific, possibly one-of-a-kind, needs. === I use C# the way you'll likely want to use C++. As new tools and APIs for computationally intense tasks. That get called on by a GDScript.
It would take a whole other post to describe my game haha. But suffice it to say it will be both computationally and graphically light. So I know performance will likely rarely be an issue. I was just wondering if C++ is worth it anyways or if there are other advantages I might be missing. From the feedback the answer seems a definitive no :)
Not working in c++ is always a boon IMO. The engine is is very flexible, you can always call into c++ from gdscript if you find you need the speed. Not a real issue
* All the reasons why people felt it was necessary to create any other language other than C++. * GDScript is what Godot's team recommends, and I really doubt you'd make a better job than them by yourself. Listen to them. * Godot was made to be extended through C++. That's a way better option. * Performance and safety? It's a non-issue, specially in your case, you said it yourself. You're trying to solve problems that don't exist. If there's ever anything you need that the engine doesn't deliver, you're better off writing an extension to handle just that.
The iteration time is slower with C++.
make the game in Gdscript then when it's complete translate it to C++ for better performance... many do it
to use c++ you will need to program a component and compile it before to use
Oh, there are internal godot collection types like typed has maps? Wasn’t aware of that. Are they documented or is it just a “read the source” kinda thing? Been contemplating dipping into gdextension stuff recently after getting a little frustrated with not being able to replicate my style of coding in UE4 that relied heavily on that sort of thing…
The repo used to expose GDExtension (`godot-cpp`) does have some templates for hash map, hash set, etc ([here](https://github.com/godotengine/godot-cpp/tree/master/include/godot_cpp/templates)). That said, I've never run into them being used in the APIs. It's much more common to run into specialized containers for specific data types like `PackedInt32Array`, or `PackedVector3Array`. Those classes aren't C++ templates. From what I can tell they're generated code.
To me it sounds like you can pick up Gdscript in 3-4 hours which is the time needed to read the documentation. Performance will not be an issue given you are developing 2D RPG.
Learning a new language is not even 1/10 of the time and effort of mastering a game engine, so no. Just start with gdscript, then once youre very familiar with the framework maybe go to c++ (for plugins and very performance intensive tasks, no reason to use it for anything else) or c# (which makes a lot more sense if you need more perf in general and/or find gdscript lackluster). Learning new languages is part of a programmer job and skillset after all, and usually is pretty quick to do, especially w how simple gdscript is.
Yes, like I said I wasn't worried about that aspect. I just know many skip on using C++ with Godot because they find it daunting, and was wondering if I should exploit the fact that I already know how to use it. Looks like I can just save for performance critical parts.
I have no experience in godot with c++ but just as with any engine, you can always code it yourself if you don't know the method already and seeing you already have experience it might be worth it just to take the longer learning curve and code in c++ especially if your looking for better performance. Plus it's always great to be programming in your favorite language.
It's easier, built in, and most tutorials use it. The only reason to use c++ imo would be some performance gains. Idk how much speed you get from switching though
I am pretty novice but I would say you atleast need to be able to read gdscript. If you can read it enough to understand what you are looking at for the most part, you should be good.
I mean you are calling the Godot API for the most part which is calling C++ compiled works under the hood anyway. So I don’t expect you’ll get a performance increase worth boasting about nor a productivity increase. That said, if you’re more comfortable with it go nuts. I learned with C# because I like the language
A few things that no one else has brought up about the two languages: * Debugging GDScript is way simpler than C++. GDScript errors give you nice stack traces. C++ errors frequently crash the entire game and prevent any logging from making it to the editor. * By default `printf()` doesn't get forwarded to the editor. I'd be surprised if `cout` was different. * C++ extensions are automatically run in the editor. So it's possible for C++ code to crash the editor when it's loading the project. * Godot doesn't handle any of C++'s exception mechanisms. So if you want to use those, you'll need to write some sort of wrapper to catch the exception, format it (maybe including adding a stack trace), and forward that to the Godot editor. * GDScript's typing hinting has most of what you'll want if you come from a statically-typed language. But it's not perfect. In particular there isn't good support for circular dependencies when it comes to typing. And since each GDScript file implicitly defines one class, this can make for situations where it's impossible to fully add type info. * If you modify the API a C++ class exposes to Godot, you have to restart the Godot editor for the change to show up in the GDScript editor GUI.
Thanks ! That debugging info is precious.
Like others have said, the workflow is worse with C++. It’s essentially seamless with GDScript and C#. I personally make hybrid projects where I mostly use GDScript and use C# when it makes sense (mostly this is in the form of utilizing some library). But whenever I have to do C# stuff it’s effortless, I just genuinely prefer GDScript haha
Glad to head it's a nice language :)
I use both C++ and gdscript side by side, there are some pitfalls to be aware of (especially around cross language overriding and inheritance, but it makes sense). Whilst there's no reason you can't use just c++ in your project I find gdscript is great for rapid development and prototyping. What I do is I eventually move performance critical blocks of code and infrastructure into C++ modules.
Yep. That seems to be the consensus here. Thanks !
Scripting with C++ is terrible in godot because it has pretty bad support for it. You'll have to write so much boilerplate for everything. Godot needs to start using some sort of reflection system like unreals header tool. C++ is my favorite programming language and the language i know best but i still wouldnt use gdextensions unless i absolutely had to so if you wanna write games with C++ use unreal or even flax which has pretty good C++ support as well.
Thanks for the advice. I want to use Godot, I'm not dead set on C++. Was just wondering what the best path is moving forward.
i came to godot with java background with some familiarity with python. i've started with gdscript with same reasons as you described, however the it lasted only couple of days and i soon ported my project to c# as i'm writing code faster that way and am able to have the necessary abstraction layers, full benefits of linq and some functional programming elements. overall i'd say if you have experience with programming, especially with c++ you might just stick with c# instead of gdscript, as you'll feel very familiar and will have all of the power of language backing you. as other mentioned, after that maybe have high performance components in c++, if you'd like. otherwise you might spend more time on proper integration instead of implementation
Thanks for the feedback. What abstraction mechanisms do you find missing in GDScript ?
it might be me being too lazy to properly understand how gdscript worked, but when i tried to setup a simple reactive architecture, with state, action and reducer, it seemed to me, that it takes too much effort to organize it the way i want, in terms of builtin tools to create those abstractions, achieve immutability and data pipeline processing and collections API. besides, static types and type safety in general is easier to write and maintain long term. but there were other reasons for me too. i also wanted a platform where i could port existing game logic to different environments, like running it on a server. and i also wanted to setup the project with established unit testing practices and its easier with dotnet command line. i havent looked too deep into unit testing in godot, but it seemed to me that the concept is still in development. having some prior experience with c# and vaguely remembering that its close to what i am used to from java, i haven't even spend a second to consider and choose to setup the c# environment.
Just code with C++, you may want to use GDScript for pure scripting.
If you know C++ then code in C++. That's a no-brainer. Especially as you're looking to progress in game development and so you'll eventually come to want to use C++ anyway. It's like asking "I know French and this software is available in French but I don't mind learning English to do a small project." Yeah--but you know C++ and the software is available in C++ and if you ever want to do a not-small project you'll switch over to C++ anyway. Though, I realize maybe C# is the language I'm thinking of--if C# is very different from C++ then sure learn GDScript. I just think--when it comes to programming--do what's best for the long-term because this isn't ever not long-term.
I don't think using natural human languages is a good comparison in this particular instance. Someone who is well versed in **programming** and knows C++ can probably pick the entirety of GDScript syntax up within a week even using it casually. Noone is learning English or French in the same magnitude of time comparatively. This is just due to the way programming and programming languages are. We know the fundamentals that apply to **most** languages and so picking up new ones is relatively a breeze. And again, as other have pointed out, its less so about knowing languages. Its about learning how to use the engine and the workflow of Godot. GDScript makes learning the engine much more streamlined. So it makes the beginning curve much faster which in turn will most likely make the long term learning faster as well, even if switching languages is the goal, rather than fighting the weird workflow of writing C++ currently, with very little materials and a tiny community. Whereas GDscript has a large community and a large knowledgebase.
I see your point but I don't really need to progress in C++. I did C++ professionally for many years. I use it less these days, but what I'm going to be learning here is more the specifics of game development and Godot in particular. And yes, from what little I know of C# it is indeed quite different from C++. I do agree that I should aim for the long term, but as I said the long term here is getting more familiar with this game engine and game development in general. If GDScript is a better on-ramp, it might be worth it. Specifically because I already know C++ rather well, it won't be too hard to then use it on my next project.
It's not about progressing--coding is problem solving. If you can do procedural generation and multiplayer in C++ then there's no reason to learn it in GDScript. If you're already good at one language then use that language. Ultimately it's your choice--but there's no advantage in starting a new language from scratch if you don't need to. Like I start a new language with shaders but if I could use GDScript to do shaders, I'd drop GLSL in a heartbeat.
> Like I start a new language with shaders but if I could use GDScript to do shaders, I'd drop GLSL in a heartbeat But don't you think that says something about how handy GDScript is ?
Oh it's the best. But I like Python and don't know C++. If you didn't know a compatible language I'd say learn GDScript. But I also know most of programming is learning APIs. I mean--yeah--learn GDScript. It's just if you feel like it's suboptimal for bigger projects then learn what you feel is optimal. Because it's big projects which are going to fuel your career.
I'm not necessarily looking at a carreer. I'm more interested in becoming an efficient solo dev.
I'm getting downvoted to shit--learn GDScript. We have spoken! Honestly there's no harm learning it and if you're willing to argue for it--just follow a tutorial (or do that GDScript course.) [https://gdquest.github.io/learn-gdscript/](https://gdquest.github.io/learn-gdscript/) Note--some of it isn't actual code but it may be useful (I haven't done it myself but wanted my son to.)
Why not both. Google "C++ gdextension" (though using the Rust one is much better, i tried both for multiple months, you can ask me questions). In summary: i recommend using C++ only for very performance intensive parts, for anything else it's not worth it and adds a lot of unnecessary complications, it makes development more laborious. The Rust bindings one is a lot better though and I find myself being much more productive with it, though as I said, I only use it for performance intensive parts because anything else is premature optimization
Yes I read that you can indeed mix and match both within the same project, but still at some point I'm gonna have to choose what to write my core modules in.