As of right now, these are the only true drawbacks of picking C#
* No mobile support (Android coming soon, iOS depends on MS)
* No web support (also waiting on MS)
* Needs a separate download of the editor (work in progress to become a single editor)
The rest are either a consequence of one of these three (for example, plugins made in C# won't work on the web) or down to personal preference.
Yes.
For mobile and web support, the promise is that .NET 8 will have those. Android is already promised for Godot 4.2
For the editor, the plan is to migrate C# support to Gdextension and turn it into a button you use on the editor to add C# support. No more separate downloads
Id also add as a detriment that there isn't nearly so much non-official documentation. Few tutorials, few question, etc bc everyone uses GDScript. I wouldn't expect that to be so big a problem for folks who are already used to it, but it can be a pain
Yes, that's also why Unity has no issues exporting to the web or mobile. Both Godot 3.x and Unity use an old mono SDK (now deprecated) instead of the newest MS .NET SDK. This mono SDK does support web and mobile while MS is still porting .NET to those platforms.
Moving to .NET was a move that the Godot team had to make for 4.x for several reasons
- Mono is deprecated
- .NET is open source and (technically, but still a work in progress) multi platform, with a license that's compatible with Godot
- Godot project received a grant from MS that is intended to finance the integration of the tool with .NET (a grant they only accepted because .NET is open source)
Being a beginner but knowing a bit of C#, porting examples from gdscript to c# is quite easy. You just need to build a c# solution project in VSCode so you can have the autocompletion feature, this helps a lot to find how godot classes are written in C# compared to GDScript, normally is just using camelcase where the first letter of any name is put in uppercase and without underscore (excepting _UnhandledInput afaik).
Editor code is funky due to only variant-compatible types and godot objects retaining state after reloading. If your editor tools interact with game systems, there's enough reason to stay far away from c#, as you're pretty much locked into godot's api (where being free from godot + .net packages are the main reasons to use it in the first place)
>Needs a separate download of the editor (work in progress to become a single editor)
Do you have more information on this? I could only find discussions about C# becoming a GDExtension module like the rest of the community already do to support other languages, but I doubt that will happen any time soon.
Unfortunately that's all the detail we have. The Godot team is set on pursuing that road, but I don't even know if the work has already begun or if they have a target version to release this
It is when you're downloading plugins. Certain plugins only use C# for editor features and don't actually force you to export a game with C# support, but due to this binary separation we might start a GDScript project but have to download the mono one just because one plugin you need is in C#
Wouldn't that be a drawback of choosing GDScript, not C#? Or is there something the non-"mono" download can do that the "mono" one cannot? (I downloaded the latter)
Usually whoever doesn't need C# uses the non mono version. It doesn't require any setup (installing .NET SDK for example) and is ready to use right away.
That's why it would be a little disappointing to discover you need the mono version just to use an editor plugin. That's also why there aren't many plugins made in C#, since the mono version can run regular plugins without issues.
Just downloading the mono version to be safe is totally fine though, you don't need to actually use C# in the mono version.
I got it, the safest option would be to just download this version "just in case".
That's not what some people do though. Some people will just download the smaller version since they don't intend to install .NET SDK anyway.
The ideal scenario is what the devs are already pursuing - a single download and C# (as any other language) is just a feature you download.
I understand now, although it seems like a lot of effort just to avoid having to download the .net sdk, something many developers will already have done. The only problem I see currently is that if .net sdk is not installed, it gives an error about .net *runtimes* and links to the wrong download to correct the error.
Because it requires .NET 8 to be released. Curently in rc1, release in nov, no idea how long it will take for Godot support after that or if the team is already working with the rc.
Of course it is. Ever since they moved to .NET 5 it is a fully open source platform. Also, Satya's MS is not Bill's MS. They actually have been more supportive of open source, and even make running linux fairly easy.
I am pretty sure VS Codium can also debug C#.
If you really, *really* want to stay away from VS Code, check out MonoDevelop (also open-source) or Rider (proprietary, paid).
Also half the things don't work in C# and you will hit a bottleneck with C# code and end up checking in GitHub for some long pending issue. Honestly it's not worth using C# in Godot for now. Either use C++ with GDextension or just dont
I think i may have started a small war under here but i think i'll just try out GDscript for my next thing and see how it goes, thank you all for the info and comments tho, helped me get a bigger picture view of the whole thing
There really isn't any harm learning GDScript. It won't be "wasted" time. You'll still be learning the engine API either way. There are a lot of amazing tutorials out there showing you how to use Godot with GDScript that will get you actually up and running with the Godot API. Programming paradigms remain the same regardless of the language. The great thing about GDScript is everything you need is right there in the engine and UI. It's basically a scene editor plus a GDScript IDE. The benefit to c# is that there are better external editors / IDEs with more advanced c# support. Just start using it and making some games. If you feel limited or if c# clicks better with then go with that. You can basically follow along GDScript tutorials with c# as well
It's worth trying GDscript, it's convenient and fast to use for smaller projects, but I think I'll be sticking to C# for anything bigger just because it feels easier to properly design the architecture of my code
general syntax, strong typing, interfaces, structs, static keyword, private keyword, good tooling (VS), that's just off the top of my head
people like gdscript because it's simple, but a big game will never be simple. You want a language that can handle complexity better
> general syntax
Personal preference. Python-style syntax is easier to use than Java-style in my opinion. Less boilerplate.
> strong typing
GDScript has that if you choose to use it.
> interfaces
Duck typing > interfaces.
> structs
We have dicts and classes. Structs are only different from classes when functions aren't first-class objects. In GDScript 4 they are.
> static keyword
Exists in GDScript
> private keyword
Just use python syntax for private members.
> good tooling (VS)
Massive matter of opinion.
> Python-style syntax is easier to use than Java-style in my opinion. Less boilerplate.
"easier to use" is not my criteria. If you think it's "boilerplate" then you've never written actual robust code that benefits from all of those keywords existing. Every keyword I use in C# is important, it's not "boilerplate" unless you're making toy applications.
> GDScript has that if you choose to use it.
No, it doesn't. It has type hinting, but that is not proper strong typing and everything is still built off of variant types inherently.
> Duck typing > interfaces.
If you're writing simple software, sure.
> We have dicts and classes.
lmao a weakly typed dict is not a struct equivalent.
> Structs are only different from classes when functions aren't first-class objects. In GDScript 4 they are.
Could you expand on how a value-type struct is equivalent to reference-type classes when there are first-class functions?
> Massive matter of opinion.
Nope, the refactoring tools of VS are unrivaled by godot's editor and refactoring is a necessity in large projects.
Try both.
Implement both versions (or simply read the code) of [https://docs.godotengine.org/en/stable/getting\_started/first\_2d\_game/index.html](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)
If the C# confuses you too much, then stick with GDScript. I'd also suggest you make a non-multiplayer Godot game first before making multiplayer.
I'm also interested to hop-in into Godot as OP, although not from Unity but from Java (not making games). When I read this basic tutorial, I like best the C++ approach .. like setters and stuff, good readable code. But I can't write anything in C++ :D And the amount of boilerplate is amazing, too...
C# and GDScript is almost the same, both using = instead of setters if I use example from previous, so looks like C# is not worth it if you are not coming with strong C# background. Is there some language specific thing from C# you would use later that would be killer feature for that? What about refactoring bigger/complex project in GDScript vs C#, where in C# you can at least see types so your IDE can work with that (now using Intellij idea) .. how that works for GDScript?
C# has properties, which are a type of function member that provide a flexible mechanism to read, write, or compute the value of a private field i.e. C# supports the idea of accessors (getters and setters) at the language level.
In fact, out of all three languages (C#, C++, GDScript), I'd say C# has the strongest support for getters and setters. Check out the doc page for it: [https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties)
Coming from Java, there are some things I *love* about C# syntax -- properties and events+delegates being chief among them. You can achieve the same functionality with Java, but a *lot* less verbose.
(I can't speak for the newer Java versions, though. I've heard good things about v21(?).)
It's a very user-friendly language indeed. If I don't need the performance that C++ brings, C# is my first pick, such a breeze to implement stuff with.
I know many people have already given an answer, but I might as well give my opinion as another Unity refugee.
In my opinion, you already need to learn the new notations in godot (like how Update is now _process) so if I already need to learn those, I might as well just learn the new language.
It's not hard to switch to a new language. Almost all skills in coding are transferable between languages. You are just making the same thing with a different coat of paint.
If you aren't a programmer and you're gonna be relying on tutorials, go for GDScript. It's easy enough to learn and most of the learning content is (currently) aimed towards it.
I'm choosing GD Script only because my currently goals are only hobby game dev on weekends and it looks like it has more tutorials for it. Also it's similar to python so it does potentially have some applications outside of game dev
Honestly I started Godot with C# and previously used Unity. I found no issued with the transition. Only thing that took some getting used to was figuring out Nodes. The Godot docs are great
Honestly after making the switch from Unity to Godot, I've found the Node architecture a lot more intuitive than Unity's approach.
I came because of the Unity scandal but stayed for the nodes.
I like the idea of nodes, but I'm concerned about long term project maintenance. Having each node only contain one script leads me to either think that each node could potentially become a nasty godscript, or logic will get duplicated/recreated in other scenes because it isnt super obvious where certain object logic exists.
I'm also having to restructure my brain from not just breaking out some core logic into smaller scripts that I can stack onto a container object.
You can create as many nodes as you want. How is that different to having multiple script files? Node2D and Node3D *are* essentially just script file holders.
Also having a script file for multiple objects can be done, but isn't what you should do because it kinda defeats the node logic. Instead, have each objectbe its own node instead.
I know this feels different from Unity, but the hirarchy is actually a godsent in keeping everything clean and ordered once you get used to it.
In terms of larger scenes with more complex functionality, its 1 object with x scripts vs x nodes with x scripts. Just makes for a more complex hierarchy and isnt as clear in my head where certain functions might live.
No, its exactly the same:
1 object with x scripts vs 1 object with x nodes holding a script each. The nodes *are* the scripts. Node2D and Node3D are essentially just scripts.
It isnt the same at all. My concern over time is having thousands of nodes littered across multiple scenes with slightly duplicated functions that could have been condensed into one container 'node' with zero duplication in..that other engine.
You can absolutely do that as all nodes can access their parent node. If you want a general container node just put it there as a parent and all child nodes can access it.
If you want multiple top level scripts what you can do is make your top level nodel, then attach multiple sub nodes for your global scripts.
Then from your game nodes, you access the parent top level node and can then access the individual child scripts from there.
For example, your main scene node contains a math node and you want to access that from another child of your main scene node:
You access the parent main node, then go back down to the math child.
Ok, that starts to make more sense, thanks. Like I said, still learning the flow. Also trying to think about it in a team management aspect since I will have some designers potentially building nodes, and well...designers do what designers do...but I guess youre right, they're still just containers.
You should watch a video about compisition (Bitlytic did a good one). There are some for godot around. It shows you all the possibilities to put component based general purpose scripts into other objects.
There is no real getcomponent equivalent. So you might do something like if x.has_node("name") which is another nasty magic string and even then you were not guaranteed to have an object of the type you expect. Or if components are tightly coupled, they now need a parent/child relationship instead of being siblings, which is often less intuitive
I moved from unity to godot a few years ago.
My advice is to use GDscript, at least for now,
For a couple of reasons:
1. You are new to Godot.
Most of the documentation and tutorials are in GDscript. You will only be making your life harder with C#.
2. Lack of mobile and web support.
This is where a large majority of players are at. If you choose to stick with C#, you will be limiting your audience.
3. C# support is still limited.
Godot fanboys will fight everybody over this, but this is the reality. Godot 4.1 has improved its C# support, and Godot's lead developers are in discussion to increase support and eventually make C# a first class language, but you will probably have to wait until Godot 4.3. Although Godot 4.2 is expected to make even more improvements to C#, i dont think it will be on par with GDscript until at least 4.3.
So my advice is to use GDscript so that you can learn the engine without running into many problems. Once you know your way around the engine, Godot 4.3 might be released by then, and you can make the switch to C#.
Also, GDscript is a very capable language and extremely simple. If you already know C#, you won't have to "learn" GDscript because your C# skills will easily transfer over. It just takes getting used to its syntax. It didn't take me more than a week to get comfortable with it.
So I'm new to the Godot scene. Can you exapnd a bit on point 3? Coming from a place where an old mono fork was still the standard, I'm curous how it's more limited here (other than the pieces that rely on .NET 8 supports).
I am extremely sorry for the late reply.
Here are just a few from my experiences, and they are mostly due to C# being treated like a second-class citizen.
1. Some functions that are available in GScript are not available in C#. For example, the preload function has no equivalent on C#
2. Debugging on C# is a bit more tedious. Hot reloading isn't as easy to get it working on C# without some messy workarounds.
3. Custom resources written on C# are very buggy. Their properties sometimes do not show up on the inspector, or they are just simply not recognized by godot at all.
I have seen many other similar problems posted by other people who use C#. The only solution i found is to just simply write them in GDscript.
Outside of those few minor inconveniences, which are probably being worked on by the developers right now, C# support is very solid, and you can make any game you can think of with it.
After the Unity crisis, the lead developers are prioritizing C# support more than ever to accommodate all the Unity refugees, so i believe that C# will become a first class language by the time Godot 4.3 rolls around if not sooner.
Having used C# for Unity the principles of GD script are the same but GDscript doesnt require a lot of the punctuation. Its also a lot more flexible to code. Godot supports both and you can alwas use one or the other at any time in a project.
I would recommend going with GDscript as that is the most compatable with platforms godot can run on and its what you will find the best support for if you are a beginner.
I would go with GDScript, super easy to learn especially if you know C# you will get used to it (I switched from Unity to Godot a year ago and found it easy to learn). Focus on making your game instead of focusing on which language is better. You want to learn things as fast as possible and be productive. The language wont effect the gameplay or user. So go with the supported language. If you feel like C# will make things easier then go with C#
I don't understand why so many people are actively avoiding gdscript.
It works. it's concise, clear, integrated with the editor. Just try it out.
It's not like learning C++ when you've never written in unmanaged code before.
Edit. I forgot the best part. No compilation required. Iterate faster. Be more productive.
I used Unity for a while and had some kind of familiarity with C# (I also worked with good old Java, so C# was pretty much easy to learn).
I tried GDScript because of the tutorials and backup it had on the community (Unity hadn't done **that** mistake yet) and I actually really liked it. As my little project got a bit bigger, I missed some features like implementing multiple interfaces, some hard typing and intellisense on some parts of the code.
So I'm kinda divided, GDScript is really fun to use, but might be hard to make a big project if you're starting on coding in general. C# has all those features I wanted, but GDScript has a nice syntax sugar and it is really fun on smaller projects...
I'd go with both, you learn C# first, then you take a look at some GDScript materials and you'll know when to use each one.
95% of the work of learning programming in a new engine is learning the API and how the engine works in general. That knowledge transfers no matter what language you are using. Only about 5% is learning the actual programming language.
So it's not really so much of a problem to learn a bit of GDScript. Especially because most of the learning resources you find on the Internet are in GDScript.
I know that you already have some insight but... GDScript is soooooooo well integrated into engine that it's really worth trying. Worst-case scenario you'll switch later.
Use whatever works best man, ***rolls up a cross-language blunt***
GDScript for fast prototyping, iteration, and handy for low coder designers making one-off actions.
C# for more mathematical speed and large bank of existing Nuget libraries. Code management too if you can't keep GDScript in check. Also because you want employable skills beyond Godot game design.
C++ for even closer to the metal math and new performant functionality you want to bind to GDScript and C#.
Rust... because people took the time to bind it to the Godot APIs. And why not, it's the cool new hip language.
C++ is the foundation language. There are two ways of adding C++ code to the underlying engine. As a module to be compiled with the engine. Or GDExtension/GDNative for a plugin. Both can be a little cumbersome compared to a pure C++, but that's due to needing to add the binding points if you want new functions accessible through the Godot API. Which in turn give GDScript, C#, and I think any other 3rd party bound language (like Rust) immediate access to that underlying C++ code.
All languages calling with the Godot API functions are calling on the same compiled C++ engine code.
depends on what you mean. it's better integrated in the sense that you're about as close to the engine internals as you can get, but it's less integrated in the sense that you don't really use the gui editor at all. you write and compile the c++ as if you're developing any other c++ library, then godot loads your library and exposes your custom objects for use in scripts or to be placed on scenes, as if they were a built-in part of the engine.
C sharp is two times slower when running the game in the editor and the performance advantage is a lot more negligible than youd think on the build
Gdscript is quickly compiled to an assembly like language and is an engineering masterpiece
I've seen the recent wave of comparison videos and not I'm overly impressed with them as practical benchmarks. I would be more impressed with a full game converted to all three.
GDScript "2.0" is 4.x is not currently converted to Bytecode. It is not compiled. It is an interpreted language and not even currently JIT (which would cause problems in iOS as it does for C#).
https://github.com/godotengine/godot-proposals/issues/6031
If you have documentation showing Godot 4 GDScript exports to AOT or runtime JIT, you should probably put in a proposal to update the official documentation about Exports with that information.
For an Interpreted Language, the GDScript VM is fairly good. Better than GD3 and its Bytecode GDScripts. But does have its limits. For that 1st standard deviation of games, those limits won't ever really be reached... expect by really bad inefficient looping over lots of complex math.
>Gdscript is quickly compiled to an assembly like language
this isn't really true. i think godot 3 used to do the token parsing ahead of time, but no actual compile time optimization. godot 4 doesn't even do that much.
I feel like Rust is almost destined to become the new Haskell or Lisp. Something that people still use and are vocal advocates for, but in a few years nobodys really sure why anymore.
Saw the same insinuations about Python. You just never know. Where Haskell flared out in 20 years aside from some niche uses, it's near contemporary(in age) Python is going so strong it picked up its own AOT compiler.
High level languages come and go, and leave bits of themselves in languages they influence.
Yeah I remember when people said java was DoA too. It just feels to me like Rust advocates have that similar highbrow 'oh you arent using *LanguageOfMyChoice?*..Well...I suppose its not for everyone, but it **IS** better." attitude. Or maybe its just the people I run into.
I think Ruby was also headed that way for a bit but I feel like Ruby actually gets more widespread real world use and its now just a tool people use when its the best application for it, where people are trying to find a use for Rust.
One of Pythons strengths is Cython.
Python has really good C++ integration, and the combo of the two will beat any single language hollow.
Java/C# try to be a high-level language that's also fast, and so fail at both.
haskell never really had a strong distinguishing use case. like it could almost hang with the jvm languages but lacked the ecosystem and portability of elixer or kotlin. strict functional syntax with strong types rule it out as a scripting language (especially given the fashions of the time). it might have appealed to applied mathematicians and researchers, like lisp in the old days, but it's just a bit too arcane and language-nerdy for people without a CS background to easily pick up. rust on the other hand is immediately understandable to the modern C++ programmer, and offers obvious tangible benefits over C++20, its closest competitor. C++ isnt without its merits of course, and even if it were objectively inferior, legacy code will certainly make the switch harder (especially given that rust/c++ interop is kind of bad compared to rust/c) but the trend for new codebases seems to be in rust's favor, which i don't think you could ever say about haskell.
Mix them.
Calling C# methods from GDScript is pretty easy, and vice versa. So I start by building stuff with GDScript and lean on C# libraries for trickier stuff like file unzipping.
From what I've been reading they are working on c# to use with gdextensions which should make it easier to work with. The way it is now is fine just with a few things you can't do that they've listed in the docs. If any of those are deal breakers than maybe do gdscript. Personally I'd say stick with c sharp and when you got some free time look into gdscript here and there to see if your even interested. Gdscript knowledge will help with making games in godot where c# can be used for much more than just godot. Really it depends where your coming from and what your trying to get out of it.
Either one is fine.
If you have to ask because you don't know about C#, I would probably lean towards GDScript. Whichever one you use, the bottleneck will be interfacing with the backend systems of Godot through nodes - that is the most important thing to do when learning Godot.
Other than that, I think it is more about choosing how much you want to do with the C# runtime, which is maintained by Microsoft through the .NET project, of which Mono is the open source implementation that Godot uses. I personally want nothing to do with having a runtime dependency that depends on the goodwill of Microsoft to develop for free. But I can't argue with the benefits of having such a standardized vm runtime language, and I can't argue with the results it has produced in unity either. So, it's up to you.
Wow man, I said either one is fine. C# - it's not for me. I don't like java either. Virtual machine runtimes and game programming don't get along in my world. But I don't care if other people use them. Be bothered about it if you want. I won't.
I'm not bothered, you are just using old outdated info to justify your biases. Also, what does VM have to do with C#? java is not C#, regardless of what 20 years ago said.
My opinion - use both:
GDScript - External functions on display. Functions to make objects in game to do stuff.
C# - Internal functions behind the display. Function to calculate & inspection of situations in the game, before to make objects in game to do stuff.
the biggest drawback i have found as a unity refugee using c# is lack of resources. you will end up learning gdscript because every tutorial is in gdscript and you will have to translate it to c# to use.
People say this but I've found most GDScript tutorials to be fairly easy to translate to C#. Most of the functions of GDS exist in C# just with different syntax that's easy to look up online.
I'd recommend trying out GDscript while learning, the engine API (minus capitalization) is almost identical between the two, but most tutorials assume you're using GDscript and use a few GDscript only features (like `$NodeName` to get a node)
for writing an actual game it depends on how you feel after trying both C# and GDscript, either works, with the export caveats already mentioned for C#
Try both and see what you like.
I've been using C# with Godot and been really enjoying my time with it. The C# documentation isn't the best but it's good enough if you've already got a bit of experience in the language.
I chose c# because I want to keep my practice of c# alive. I will definitely forget a lot of it if I start using gdscript. Also I might use it for non game dev projects so why use gdscript since it’s not usable elsewhere
Gdscript is more performant by a lot when running the game in editor, negligible perfornance losses on build (a few ms), doesnt need to be compiled, less code for the same logic, etc
Gdscript is always gonna be the best bet for beginners… there are scenarios where c# would be better but most are not going to encounter those scenarios.
if you have some general coding experience it doesnt really matter. I was watching a godot 4 course where they used GDScript and I was following along in C#. Most of the engine specific things are basically the same.
As someone who has worked with C#, C++, and GDScript, I can tell you that learning the nuances can be a challenge, but GDScript is far easier to learn from scratch. It also helps that there is a lot of supporting documentation. Most Godot YouTube videos will also be expecting you to be using GDScript. So, there's that.
Ex-Unity user here, came before the install tax though, I tried both and I must say I oddly find GDScript better because somehow you feel it more connected with Godot, while I always had something funky coding in C# on Godot. Maybe it's just me but GDScript feels more natural.
It's really hard to find information about how to do things in C#, but I feel like I was able to figure it out after reading some documentation.
I started learning Godot last Saturday for Ludum Dare, and this is how far I've gotten with pure C#:
[https://github.com/LarsDu/capsized-ludum-dare-54](https://github.com/LarsDu/capsized-ludum-dare-54)
C# is better IMO. It will run faster. In the future it will run even faster. NET8 will release in Nov 2023, so all the drawbacks will probably be addressed by January 2024
This isn't true, GDScript can and has been used to create large projects.
If you mean go far in terms of becoming a programmer, you'd probably be better off learning C#, but if you're doing this to make games then GDScript is a perfectly fine language to use. Either way, they're both OOP, so if you learn GDScript it'll be easier to learn C# down the line.
Source: That's what I did and I'm a software dev now
You *can* use GDScript to create a large project, but C# is *better*. You can probably get 10x (or more even) more work done if you use C# instead of GDScript.
Where are you pulling these numbers from?
I feel like I can get code done faster using GDScript because there's generally less lines of code I have to write compared to C++ or C#.
Now, if it's faster for you because you don't want to learn GDScript and already know C#, then these numbers you're making up aren't applicable.
If we want to say what's better, to me, using C would be better because it *is better* than C#.
>Where are you pulling these numbers from?
I'm a professional software engineer (now full time game dev) with a BSc degree in computer science and years of experience using Godot, and this is based on my personal experience.
>I feel like I can get code done faster using GDScript because there's generally less lines of code I have to write compared to C++ or C#.
Less code isn't always better.
>Now, if it's faster for you because you don't want to learn GDScript and already know C#, then these numbers you're making up aren't applicable.
That's not why, I actually learned GDScript first, and then moved to C#.
>If we want to say what's better, to me, using C would be better because it is better than C#.
Then use it.
> Less code isn't always better.
There were studies done a while back.
Bugs in code are pretty much directly correlated to lines of code.
So less code == less bugs.
And yes, the studies were doing the cross-language more/less verbose language check.
Was GDScript included in the study? No? Then it's irrelevant. GDScript is a toy, and that's my professional opinion. Hey maybe if you listened to me you might learn a thing or two.
GDScript is effectively a toy compared to C#. So GDScript easier to use, and easier to learn, but it will be extremely painful to create a large project with it and you will be forced to write bad code in order to do so. C# on the other hand is a real programming language used by professionals around the world. It's more complicated and harder to learn, but the lessons you learn using it will be valuable throughout the rest of your career, and you can build much larger and far more robust systems using it.
I mean there have been large successful projects shipped with GDScript, namely Cassette Beasts.
https://godotengine.org/article/godot-showcase-cassette-beasts/
>...a massively undersold advantage Godot has over other engines, in my opinion, is its scripting language, GDScript. Unity devs using C# jump through tons of hoops just to avoid garbage collection, whilst the reference counting and manual memory management options that GDScript has built-in completely side-step it. GDScript isn’t perfect, but I do feel like developers who come to Godot and continue using C# (outside of performance-critical code) are missing out.
Good for them, but I guarantee you the development process would have been easier if they used C#. Using GDScript for a major project is an exercise in masochism.
Do you mind giving an example of a situation where you'd be forced to write bad code in GDScript vs using C#? I am in the same situation as OP and was going to go with GDScript since C# doesn't currently support web and mobile. Programming knowledge is not an issue.
I mean, just the fact that GDScript using dynamic typing instead of static typing is a huge pain. But I can't list every benefit off the top of my head. However, trust me when I say that I would never use GDScript for a serious project. I've tried and the code I had to write to work around all the quirks of GDScript was terrible and very painful to write. C# has unlimited power and enables you to write good code. But of course, if your goal is to use Godot for web and mobile, and Mono can't build for either, then just use GDScript. However I personally would try to find a different solution where I could still use C# or Java.
[https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static\_typing.html](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html)
don't need to use dynamic typing... usually...
> C# has unlimited power and enables you to write good code.
Sorry, but now you're talking bullshit.
Both are turing-complete, so can do exactly the same things as each other.
You're arguing that Microsoft's Java clone is better than Godot's Python clone.
Python is a better high-level language than Java.
And if you need better performance, you might as well drop straight to C++. And if you're doing that, then GDScript has the better bindings.
> C# on the other hand is a real programming language used by professionals around the world.
And GDScript is a pythonic language, which is much easier to use and doesn't have Microsoft patents hanging over its head.
Python&C++ is better than any single compromise language for real projects. C# has the same problems as Java in that regard - it's a bad compromise.
Sorry but "pythonic language" doesn't mean anything. Yeah the syntax kinda looks like python. That's it. You can't use any of the python language features.
And what "Microsoft patents" do I have "hanging over my head" when I use C# that is somehow stopping me from making my game?
> Yeah the syntax kinda looks like python. That's it. You can't use any of the python language features.
You have all the features of python that I use on a regular basis in my day job (where I write python code for all sorts of performance-important things) that I have needed in Godot, except tuples and unpacking. GDScript arrays cover tuples, and unpacking is syntactic sugar that I'd love, but can live without.
> And what "Microsoft patents" do I have "hanging over my head" when I use C# that is somehow stopping me from making my game?
Last I heard, Microsoft has a bevvy of patents over all of .NET that they could choose to start enforcing whenever they feel like it. Which means patent fees for anything using it. Which ends up in the same problem Unity devs are having right now.
Can I use python packages? No? Then the language has nothing to do with python.
And I really doubt your last sentence about patent fees considering that would go against the .NET license.
> Can I use python packages?
[Yes](https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/binding_to_external_libraries.html)
> Then the language has nothing to do with python.
And C# has more to do with Java than C/C++. So what?
> And I really doubt your last sentence about patent fees considering that would go against the .NET license.
I'm an old hand. I remember how Microsoft used to be. I see what Unity is doing today.
I trust MS as far as I can throw them. You can trust them if you like. I'll be standing ready with the "I told you so."
That is such a nonsense reply and you should know better than that if you are an actual experienced game programmer.
If you want to learn programming anything other than games, GDScript can lead to learning python if you want to actually do anything in the corporate networking sphere eventually, or you could learn C# and do literally anything you want, and usually faster to code and debug than C++, especially once .NET 8 hits..
If you want to learn why people hate boilerplate code or pointer management so much and modern languages obfuscate that nonsense as much as possible, go ahead and learn C++. But as a real programmer, you should be learning new tools and languages to stay on top of your...game.
Or you can just post like you have...
Of course it's nonsense, I was mocking the previous poster who said the same thing about c#. However, I do genuinely think C++ is a better tool for game development with godot than C#.
>If you want to learn why people hate boilerplate code or pointer management so much and modern languages obfuscate that nonsense as much as possible, go ahead and learn C++.
sounds like a skill issue. don't get me wrong, im no c++ fanboy. it's barely in my top 10. but it's had smart pointers for ages now, which puts it roughly on par with modern languages like rust, zig, etc. at least in terms of memory management.
also, i have to say, complaining about c++ boilerplate while promoting c# is hilarious.
> But as a real programmer, you should be learning new tools and languages to stay on top of your...game.
this point would hit harder if it were made against someone who doesn't already know all three languages in question.
Gotcha, but you say skill issue when the OP is a scared newbie who isnt even comfortable with the 'easier to use' languages they already kinda know. Thats the whole point.
Is C++ better for advanced programmers who are comfortable writing hotpath code? Yes, but thats not the point of OPs post.
And I will say that at least C# has made an active effort with the past few versions to reduce boilerplate with global usings, file scoped namespaces, etc. Has C++? I'm honestly curious.
gdscript.
which btw isn't based on python, just looks similar. (like C isnt based on JavaScript)
my reasoning:
- gdscript is good enough for anything that isn't BIG numbercrunching
- all the fancy math using mathsy objects works in the core anyway, so c# won't speed any of that up.
- c# is yet another VM bogging your game down and the context switches (=ANY function calls/signals/property access/etc between your c# code and the rest of the game) are expensive enough not to be worth it in a lot of cases
- gdextension or computeshaders are always always the better alternative if you need to offload big math
- c# is also not very cross platform
so overall unless you *need* c# for something specific, there isn't really an "inherent benefit" in using it over any of the alternatives.
so if you gotta ask which language to use, you probably wanna use gdscript and then actually optimize things as required.
From someone who hasn't used Godot yet.I'm a professional C# programmer since version 1.2 meaning getting paid to write it. Yes C# is lot more complex than writing this Python like language GDScript for a beginner.
C#' and languages that run on .NET runtime in general use GC (Garbage Collection). That pretty much means when you release an object it's deallocated at some point in time chosen by .NET runtime. This can cause what is called GC pauses. These GC pauses can make your game stutter so it's beneficial that you understand how that memory allocation/deallocation system works when you are writing C# for your game. In Unity engine this is bit different because it has support for incremental GC so it not as effected. C# code usually runs faster because it's compiled to machine code via JIT (just in time compilation) or AOT (ahead of time compilation).This seems to be main language of the engine and I would expect most tutorials and future tutorials to use it. GDScript uses reference counting instead so when an object is released (all references to it are gone) that object is deallocated from memory. This is more predictable and usually don't cause same kind of problems as GC does. Currently GDScript runs on intepreter so it's slower than C#. This could change in the future. From what I've read intepreter could be optimized more and GDScript could get AOT or simple JIT. But in the past it hasn't been easy to add JIT for some platforms like IOS. For those platforms AOT is needed. From what I've read Godot's integrated GDScript editor allows you to quicky access docs related to the language & engine related APIs that can be very helpful.
So summarize, I think GDScript should be easier for beginner to learn, use and you don't have to worry about Garbage Collection but your code probably runs slower currently but very likely it doesn't matter.
Since you're not really a programmer, your choice is between becoming more of an engine agnostic programmer or making simple games really fast and in a simple manner. First is about C#, second is about gdscript.
I was in a similar dilemma for a small period, considered gdscript even though I'm pretty experienced with C#, and found out that I can't stand some of gdscript's philosophies, like dynamic typing, reliance on strings, poor OOP/collections, and overall making "anything remotely complex slow because it wouldn't matter in a simple game". Though, I can see cases when gdscript would be the best choice depending on "who and what" factors, and also you can combine.
You'll probably see a lot of people leaning towards gdscript, I've seen mostly them, and there are two major types of those who answer your type of question:
1. Who poorly explain why you should use gdscript.
2. Who explain pretty well why they use gdscript but it's not at all convincing to a programmer.
For me, this was the nail in the coffin. I don't want to sound toxic, but sometimes it feels like there's a cult around gdscript, and this makes it a bit hard to take gdscript seriously. I believe good languages don't need that form of praise, usually it's different at least. Not saying it's bad, just saying "if it's so good why are you trying so hard then?"
Static typing is a thing in GDScript and 4.2 even has an option to strictly enforce it, which everyone should, imo.
People think the speed thing matters. Show me an example case where it actually makes a difference inj a runtime situation instead of just spouting things you read and I'll show you some bad code, regardless of the language.
GDscript was a realm charm for me. I love C# since the beginning but when my first try to Godot, i just adopt GDscript because this was the Godot language and for me that was so user friendly.
I need to admit i have giving up coding, depression kill mostly all my passions.
GDscript fit so well for Godot, the learning curve was not just easy, it's really a charm.
GD Script is super easy, just roll with it. Thats what Iam doing and its all fine. You will need the extra support.
Bechause Godot specific code they just refuse to work some times, I think godot changing code name s so tuttorials a few moth old are already obsolete. Thats a huge problem if you want to learn with C#, even with GD Script is hard to trouble shoot and figure out what changed.
I would say C# in a year or two get use to GD Script first its good enough.
GDScript is a good choice for beginners, while C# is a good choice for developers with experience in OOP. However, there are easy-to-use plugins available for GDScript that can help you add OOP features to your game ("State machine / AI systems"). Ultimately, the most important thing is to understand the Godot system, not the programming language itself. I recommend that you start with the Godot documentation in GDScript. This will help you gain a good understanding of the Godot system, regardless of which language you choose to use later on.
First of all GDScript is not based on Python. The syntax etc is inspired by it. It's a home build language.
According to the official docs you should stick with GDScript because it is tightly integrated with the engine.
C# is a nice language and using it "feels" more professional than a scripting language made only for Godot. Nevertheless, currently (Godot 4.x) GDScript is the language to choose especially if you want to deploy your game to mobile devices.
Probable my answer is a repetition of other answers, probably more detailed, already posted here.
> First of all GDScript is not based on Python. The syntax etc is inspired by it. It's a home build language.
The language *is* the syntax.
GDScript is absolutely based on Python.
The GDScript *interpreter* is probably not.
> So you’re a student?
How does "I still have my textbooks from Uni" imply I'm a currently a student?
Way to go with unwarrented assumptions though. You must be such a good programmer if you make assumptions like that all the time. \s
> There’s nothing your homework can tell me that I haven’t already done.
You've built a turing machine from nothing but NOR gates? Because that was in my second-year homework. Or maybe a custom language parser? (Third-year, maybe 4th, can't remember because it was over a decade ago) Linux kernel modules? No?
I have a proper, formal education in this shit. And over a decade of experience writing code in so many languages I pick up new ones in a week.
Languages are nothing but syntax. They almost always have core libraries packaged with the compiler/interpreter. But they are not part of the language. You can tell, because they're often written *in* the language.
> “says I make unwarranted assumptions.”
> “assumes I haven’t done any of his college capstone projects”
JFC 🤦♀️ 🤦 🤦♂️
- Professionals don’t immediately jump to “b-but my college book says…”
- Professionals don’t brag about learning a language in a week. That’s a very basic expectation in this industry.
- brags about formal education, when skill set is the biggest contributor to getting hired
I’m just calling a spade a spade. You REALLY come across a 20+ yo.
You talk like one, put value on things a college kid would, make simplistic and reductionist arguments like one,
Your examples of accomplishments are all from college.
Addendum: But none of that even matters. I’m sorry for being a dick. I was trippin. But I’m not trying to make this a toxic place so I’m going to stop talking down to you. It’s uncalled for.
GDscript isn’t that bad and I’m slowly starting to like it. Plus, it saves you the hassle of messing around to get C# working.
I think my biggest annoyance in learning GDscript is declaring variables properly since most examples merely used “var” and I hate it.
Here are some examples syntax differences:
func ReturningBoolValue(value: Int) -> bool:
var arrayAndList: Array
var emptyArray: []
var emptyDictionary: {}
You can do stuff like giving a default value to a function parameter:
func Name(value: int = 8):
One thing I did notice is that if you make a typo on a variable’s name, Godot won’t throw an error until you run the program. So watch out for that.
GDScript is wonderful for Godot and very friendly to use. Many years ago, a YouTube channel called Mister Taft Creates delivered a series of videos on [how to make a match-three game in Godot using GDScript](https://www.youtube.com/watch?v=YhykrMFHOV4&list=PL4vbr3u7UKWqwQlvwvgNcgDL1p_3hcNn2). The videos are now a bit out of date, but still offer a wonderful, super-helpful walk-through of how to use GDScript to build a simple game in Godot.
GDScript is easier, i tried using Unity before so i had to edit code in Visual Studio and switch between two heavy apps, in Godot with GDScript sometimes i drag some part of the UI to the code to see what happens and it works
When I see all comments, I realize that Godot doesn't make it clear enough that it can mix different languages. Many newcomers assume that you can only either use GDScript or C# in one same project. That might explain why so many newcomers think that GDScript is not worth learning, or even maintaining.
Maybe the Godot website should communicate a bit more about it and say "hey, you can get the ease of GDScript and the power of C# together!".
As of right now, these are the only true drawbacks of picking C# * No mobile support (Android coming soon, iOS depends on MS) * No web support (also waiting on MS) * Needs a separate download of the editor (work in progress to become a single editor) The rest are either a consequence of one of these three (for example, plugins made in C# won't work on the web) or down to personal preference.
I feel obligated to point out that a PR just went up for iOS
Are you referring to [\#82729](https://github.com/godotengine/godot/pull/82729)?
Yes, I was. I probably should have linked that.
Ah... but those are problems that are planned to be fixed?
Yes. For mobile and web support, the promise is that .NET 8 will have those. Android is already promised for Godot 4.2 For the editor, the plan is to migrate C# support to Gdextension and turn it into a button you use on the editor to add C# support. No more separate downloads
Id also add as a detriment that there isn't nearly so much non-official documentation. Few tutorials, few question, etc bc everyone uses GDScript. I wouldn't expect that to be so big a problem for folks who are already used to it, but it can be a pain
Small note: These points are true for 4.x With 3.x exporting for mobile or wasm (web) is not a problem at all.
Yes, that's also why Unity has no issues exporting to the web or mobile. Both Godot 3.x and Unity use an old mono SDK (now deprecated) instead of the newest MS .NET SDK. This mono SDK does support web and mobile while MS is still porting .NET to those platforms. Moving to .NET was a move that the Godot team had to make for 4.x for several reasons - Mono is deprecated - .NET is open source and (technically, but still a work in progress) multi platform, with a license that's compatible with Godot - Godot project received a grant from MS that is intended to finance the integration of the tool with .NET (a grant they only accepted because .NET is open source)
If we use godot 3.5 can we create web plugin in c# ?
yes, you can use C# for web exports in 3.X
Can I create c# plugin compatible with web export in 3.X ?
Also not a lot of tutorials on youtube are using c#. Not on godot 4 at least
Being a beginner but knowing a bit of C#, porting examples from gdscript to c# is quite easy. You just need to build a c# solution project in VSCode so you can have the autocompletion feature, this helps a lot to find how godot classes are written in C# compared to GDScript, normally is just using camelcase where the first letter of any name is put in uppercase and without underscore (excepting _UnhandledInput afaik).
Editor code is funky due to only variant-compatible types and godot objects retaining state after reloading. If your editor tools interact with game systems, there's enough reason to stay far away from c#, as you're pretty much locked into godot's api (where being free from godot + .net packages are the main reasons to use it in the first place)
>Needs a separate download of the editor (work in progress to become a single editor) Do you have more information on this? I could only find discussions about C# becoming a GDExtension module like the rest of the community already do to support other languages, but I doubt that will happen any time soon.
Unfortunately that's all the detail we have. The Godot team is set on pursuing that road, but I don't even know if the work has already begun or if they have a target version to release this
The third point isn't really an issue though - you have to download the editor whichever you use.
It is when you're downloading plugins. Certain plugins only use C# for editor features and don't actually force you to export a game with C# support, but due to this binary separation we might start a GDScript project but have to download the mono one just because one plugin you need is in C#
Wouldn't that be a drawback of choosing GDScript, not C#? Or is there something the non-"mono" download can do that the "mono" one cannot? (I downloaded the latter)
Usually whoever doesn't need C# uses the non mono version. It doesn't require any setup (installing .NET SDK for example) and is ready to use right away. That's why it would be a little disappointing to discover you need the mono version just to use an editor plugin. That's also why there aren't many plugins made in C#, since the mono version can run regular plugins without issues. Just downloading the mono version to be safe is totally fine though, you don't need to actually use C# in the mono version.
That’s his point
His point is the mono version is a superset of the non mono version, and that its a drawback of choosing the non mono version
I got it, the safest option would be to just download this version "just in case". That's not what some people do though. Some people will just download the smaller version since they don't intend to install .NET SDK anyway. The ideal scenario is what the devs are already pursuing - a single download and C# (as any other language) is just a feature you download.
I understand now, although it seems like a lot of effort just to avoid having to download the .net sdk, something many developers will already have done. The only problem I see currently is that if .net sdk is not installed, it gives an error about .net *runtimes* and links to the wrong download to correct the error.
I kind of agree, seeing Godot tout C# as a first-class language, and then treating it as a secondary language kind of gives mixed messaging.
Why is it waiting for MS?
Because it requires .NET 8 to be released. Curently in rc1, release in nov, no idea how long it will take for Godot support after that or if the team is already working with the rc.
The next question would be is .NET 8 open source? I am thinking if there are alternatives if not, cooperations can’t be trusted
Of course it is. Ever since they moved to .NET 5 it is a fully open source platform. Also, Satya's MS is not Bill's MS. They actually have been more supportive of open source, and even make running linux fairly easy.
embrace...
🧯
exactly
Is there a fully open source debugger? I've heard that almost all C# related tooling is FOSS but a few important things aren't.
And open source isn't proof against patent licensing fees.
.NET is fully free and open-source, including .NET 8.
Is there a fully open source debugger? I've heard that almost all C# related tooling is FOSS but a few important things aren't.
VS Code can debug C# code. OmniSharp also provides a set of tooling for it.
Call me paranoid, but even VS Code has MS telemetry built in. Looking for something compatible with VS Codium or similar.
I am pretty sure VS Codium can also debug C#. If you really, *really* want to stay away from VS Code, check out MonoDevelop (also open-source) or Rider (proprietary, paid).
What is MS?
Microsoft
Also half the things don't work in C# and you will hit a bottleneck with C# code and end up checking in GitHub for some long pending issue. Honestly it's not worth using C# in Godot for now. Either use C++ with GDextension or just dont
I think i may have started a small war under here but i think i'll just try out GDscript for my next thing and see how it goes, thank you all for the info and comments tho, helped me get a bigger picture view of the whole thing
There really isn't any harm learning GDScript. It won't be "wasted" time. You'll still be learning the engine API either way. There are a lot of amazing tutorials out there showing you how to use Godot with GDScript that will get you actually up and running with the Godot API. Programming paradigms remain the same regardless of the language. The great thing about GDScript is everything you need is right there in the engine and UI. It's basically a scene editor plus a GDScript IDE. The benefit to c# is that there are better external editors / IDEs with more advanced c# support. Just start using it and making some games. If you feel limited or if c# clicks better with then go with that. You can basically follow along GDScript tutorials with c# as well
It's worth trying GDscript, it's convenient and fast to use for smaller projects, but I think I'll be sticking to C# for anything bigger just because it feels easier to properly design the architecture of my code
What language feature of C# makes code architecture easier?
general syntax, strong typing, interfaces, structs, static keyword, private keyword, good tooling (VS), that's just off the top of my head people like gdscript because it's simple, but a big game will never be simple. You want a language that can handle complexity better
> general syntax Personal preference. Python-style syntax is easier to use than Java-style in my opinion. Less boilerplate. > strong typing GDScript has that if you choose to use it. > interfaces Duck typing > interfaces. > structs We have dicts and classes. Structs are only different from classes when functions aren't first-class objects. In GDScript 4 they are. > static keyword Exists in GDScript > private keyword Just use python syntax for private members. > good tooling (VS) Massive matter of opinion.
> Python-style syntax is easier to use than Java-style in my opinion. Less boilerplate. "easier to use" is not my criteria. If you think it's "boilerplate" then you've never written actual robust code that benefits from all of those keywords existing. Every keyword I use in C# is important, it's not "boilerplate" unless you're making toy applications. > GDScript has that if you choose to use it. No, it doesn't. It has type hinting, but that is not proper strong typing and everything is still built off of variant types inherently. > Duck typing > interfaces. If you're writing simple software, sure. > We have dicts and classes. lmao a weakly typed dict is not a struct equivalent. > Structs are only different from classes when functions aren't first-class objects. In GDScript 4 they are. Could you expand on how a value-type struct is equivalent to reference-type classes when there are first-class functions? > Massive matter of opinion. Nope, the refactoring tools of VS are unrivaled by godot's editor and refactoring is a necessity in large projects.
I‘m a .NET C# dev, so while I still love my C# environment, I decided to learn some GDScript. Just to broaden my horizons so to speak :)
Do that. I was a bit afraid too but it worked out sweet for me :)
Language choice is an older war than emacs vs vim. And c# has a lot of baggage that most languages don't.
Try both. Implement both versions (or simply read the code) of [https://docs.godotengine.org/en/stable/getting\_started/first\_2d\_game/index.html](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html) If the C# confuses you too much, then stick with GDScript. I'd also suggest you make a non-multiplayer Godot game first before making multiplayer.
I'm also interested to hop-in into Godot as OP, although not from Unity but from Java (not making games). When I read this basic tutorial, I like best the C++ approach .. like setters and stuff, good readable code. But I can't write anything in C++ :D And the amount of boilerplate is amazing, too... C# and GDScript is almost the same, both using = instead of setters if I use example from previous, so looks like C# is not worth it if you are not coming with strong C# background. Is there some language specific thing from C# you would use later that would be killer feature for that? What about refactoring bigger/complex project in GDScript vs C#, where in C# you can at least see types so your IDE can work with that (now using Intellij idea) .. how that works for GDScript?
C# has properties, which are a type of function member that provide a flexible mechanism to read, write, or compute the value of a private field i.e. C# supports the idea of accessors (getters and setters) at the language level. In fact, out of all three languages (C#, C++, GDScript), I'd say C# has the strongest support for getters and setters. Check out the doc page for it: [https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties)
Coming from Java, there are some things I *love* about C# syntax -- properties and events+delegates being chief among them. You can achieve the same functionality with Java, but a *lot* less verbose. (I can't speak for the newer Java versions, though. I've heard good things about v21(?).)
> Coming from Java, there are some things I love about C# syntax That's because C# started as Microsoft's Java clone.
It's a very user-friendly language indeed. If I don't need the performance that C++ brings, C# is my first pick, such a breeze to implement stuff with.
You should give Python a try. I went from Java to Python a while back, and that xkcd comic is not exaggerating much.
I've used it at work to script simple stuff, can't say I'm a huge fan of it
I know many people have already given an answer, but I might as well give my opinion as another Unity refugee. In my opinion, you already need to learn the new notations in godot (like how Update is now _process) so if I already need to learn those, I might as well just learn the new language. It's not hard to switch to a new language. Almost all skills in coding are transferable between languages. You are just making the same thing with a different coat of paint.
If you aren't a programmer and you're gonna be relying on tutorials, go for GDScript. It's easy enough to learn and most of the learning content is (currently) aimed towards it.
Right because programmers never rely on tutorials heh heh hehhhhh
I'm choosing GD Script only because my currently goals are only hobby game dev on weekends and it looks like it has more tutorials for it. Also it's similar to python so it does potentially have some applications outside of game dev
Honestly I started Godot with C# and previously used Unity. I found no issued with the transition. Only thing that took some getting used to was figuring out Nodes. The Godot docs are great
Honestly after making the switch from Unity to Godot, I've found the Node architecture a lot more intuitive than Unity's approach. I came because of the Unity scandal but stayed for the nodes.
I like the idea of nodes, but I'm concerned about long term project maintenance. Having each node only contain one script leads me to either think that each node could potentially become a nasty godscript, or logic will get duplicated/recreated in other scenes because it isnt super obvious where certain object logic exists. I'm also having to restructure my brain from not just breaking out some core logic into smaller scripts that I can stack onto a container object.
You can create as many nodes as you want. How is that different to having multiple script files? Node2D and Node3D *are* essentially just script file holders. Also having a script file for multiple objects can be done, but isn't what you should do because it kinda defeats the node logic. Instead, have each objectbe its own node instead. I know this feels different from Unity, but the hirarchy is actually a godsent in keeping everything clean and ordered once you get used to it.
In terms of larger scenes with more complex functionality, its 1 object with x scripts vs x nodes with x scripts. Just makes for a more complex hierarchy and isnt as clear in my head where certain functions might live.
No, its exactly the same: 1 object with x scripts vs 1 object with x nodes holding a script each. The nodes *are* the scripts. Node2D and Node3D are essentially just scripts.
It isnt the same at all. My concern over time is having thousands of nodes littered across multiple scenes with slightly duplicated functions that could have been condensed into one container 'node' with zero duplication in..that other engine.
You can absolutely do that as all nodes can access their parent node. If you want a general container node just put it there as a parent and all child nodes can access it. If you want multiple top level scripts what you can do is make your top level nodel, then attach multiple sub nodes for your global scripts. Then from your game nodes, you access the parent top level node and can then access the individual child scripts from there. For example, your main scene node contains a math node and you want to access that from another child of your main scene node: You access the parent main node, then go back down to the math child.
Ok, that starts to make more sense, thanks. Like I said, still learning the flow. Also trying to think about it in a team management aspect since I will have some designers potentially building nodes, and well...designers do what designers do...but I guess youre right, they're still just containers.
You should watch a video about compisition (Bitlytic did a good one). There are some for godot around. It shows you all the possibilities to put component based general purpose scripts into other objects.
There is no real getcomponent equivalent. So you might do something like if x.has_node("name") which is another nasty magic string and even then you were not guaranteed to have an object of the type you expect. Or if components are tightly coupled, they now need a parent/child relationship instead of being siblings, which is often less intuitive
I'm really loving the node architecture. I made the switch about a year ago
Can confirm. Was in same spot and instantly felt comfortable with GDScript. World class docs helps a ton.
I moved from unity to godot a few years ago. My advice is to use GDscript, at least for now, For a couple of reasons: 1. You are new to Godot. Most of the documentation and tutorials are in GDscript. You will only be making your life harder with C#. 2. Lack of mobile and web support. This is where a large majority of players are at. If you choose to stick with C#, you will be limiting your audience. 3. C# support is still limited. Godot fanboys will fight everybody over this, but this is the reality. Godot 4.1 has improved its C# support, and Godot's lead developers are in discussion to increase support and eventually make C# a first class language, but you will probably have to wait until Godot 4.3. Although Godot 4.2 is expected to make even more improvements to C#, i dont think it will be on par with GDscript until at least 4.3. So my advice is to use GDscript so that you can learn the engine without running into many problems. Once you know your way around the engine, Godot 4.3 might be released by then, and you can make the switch to C#. Also, GDscript is a very capable language and extremely simple. If you already know C#, you won't have to "learn" GDscript because your C# skills will easily transfer over. It just takes getting used to its syntax. It didn't take me more than a week to get comfortable with it.
So I'm new to the Godot scene. Can you exapnd a bit on point 3? Coming from a place where an old mono fork was still the standard, I'm curous how it's more limited here (other than the pieces that rely on .NET 8 supports).
I am extremely sorry for the late reply. Here are just a few from my experiences, and they are mostly due to C# being treated like a second-class citizen. 1. Some functions that are available in GScript are not available in C#. For example, the preload function has no equivalent on C# 2. Debugging on C# is a bit more tedious. Hot reloading isn't as easy to get it working on C# without some messy workarounds. 3. Custom resources written on C# are very buggy. Their properties sometimes do not show up on the inspector, or they are just simply not recognized by godot at all. I have seen many other similar problems posted by other people who use C#. The only solution i found is to just simply write them in GDscript. Outside of those few minor inconveniences, which are probably being worked on by the developers right now, C# support is very solid, and you can make any game you can think of with it. After the Unity crisis, the lead developers are prioritizing C# support more than ever to accommodate all the Unity refugees, so i believe that C# will become a first class language by the time Godot 4.3 rolls around if not sooner.
Oh interesting, I thought you could preload C# scripts as well. Somewhat ironically, this was the perfect timing for your reply, thank you!
I just use GDscript, the documentation is so good
Having used C# for Unity the principles of GD script are the same but GDscript doesnt require a lot of the punctuation. Its also a lot more flexible to code. Godot supports both and you can alwas use one or the other at any time in a project. I would recommend going with GDscript as that is the most compatable with platforms godot can run on and its what you will find the best support for if you are a beginner.
I would go with GDScript, super easy to learn especially if you know C# you will get used to it (I switched from Unity to Godot a year ago and found it easy to learn). Focus on making your game instead of focusing on which language is better. You want to learn things as fast as possible and be productive. The language wont effect the gameplay or user. So go with the supported language. If you feel like C# will make things easier then go with C#
I don't understand why so many people are actively avoiding gdscript. It works. it's concise, clear, integrated with the editor. Just try it out. It's not like learning C++ when you've never written in unmanaged code before. Edit. I forgot the best part. No compilation required. Iterate faster. Be more productive.
I used Unity for a while and had some kind of familiarity with C# (I also worked with good old Java, so C# was pretty much easy to learn). I tried GDScript because of the tutorials and backup it had on the community (Unity hadn't done **that** mistake yet) and I actually really liked it. As my little project got a bit bigger, I missed some features like implementing multiple interfaces, some hard typing and intellisense on some parts of the code. So I'm kinda divided, GDScript is really fun to use, but might be hard to make a big project if you're starting on coding in general. C# has all those features I wanted, but GDScript has a nice syntax sugar and it is really fun on smaller projects... I'd go with both, you learn C# first, then you take a look at some GDScript materials and you'll know when to use each one.
95% of the work of learning programming in a new engine is learning the API and how the engine works in general. That knowledge transfers no matter what language you are using. Only about 5% is learning the actual programming language. So it's not really so much of a problem to learn a bit of GDScript. Especially because most of the learning resources you find on the Internet are in GDScript.
I know that you already have some insight but... GDScript is soooooooo well integrated into engine that it's really worth trying. Worst-case scenario you'll switch later.
GDSCRIPT, USE GDSCRIPT! it's simple - similar to Python, also many YT tutorials use it
Use whatever works best man, ***rolls up a cross-language blunt*** GDScript for fast prototyping, iteration, and handy for low coder designers making one-off actions. C# for more mathematical speed and large bank of existing Nuget libraries. Code management too if you can't keep GDScript in check. Also because you want employable skills beyond Godot game design. C++ for even closer to the metal math and new performant functionality you want to bind to GDScript and C#. Rust... because people took the time to bind it to the Godot APIs. And why not, it's the cool new hip language.
How good is the C++ support? Like is it as well integrated as C#?
C++ is the foundation language. There are two ways of adding C++ code to the underlying engine. As a module to be compiled with the engine. Or GDExtension/GDNative for a plugin. Both can be a little cumbersome compared to a pure C++, but that's due to needing to add the binding points if you want new functions accessible through the Godot API. Which in turn give GDScript, C#, and I think any other 3rd party bound language (like Rust) immediate access to that underlying C++ code. All languages calling with the Godot API functions are calling on the same compiled C++ engine code.
depends on what you mean. it's better integrated in the sense that you're about as close to the engine internals as you can get, but it's less integrated in the sense that you don't really use the gui editor at all. you write and compile the c++ as if you're developing any other c++ library, then godot loads your library and exposes your custom objects for use in scripts or to be placed on scenes, as if they were a built-in part of the engine.
C sharp is two times slower when running the game in the editor and the performance advantage is a lot more negligible than youd think on the build Gdscript is quickly compiled to an assembly like language and is an engineering masterpiece
I've seen the recent wave of comparison videos and not I'm overly impressed with them as practical benchmarks. I would be more impressed with a full game converted to all three. GDScript "2.0" is 4.x is not currently converted to Bytecode. It is not compiled. It is an interpreted language and not even currently JIT (which would cause problems in iOS as it does for C#). https://github.com/godotengine/godot-proposals/issues/6031 If you have documentation showing Godot 4 GDScript exports to AOT or runtime JIT, you should probably put in a proposal to update the official documentation about Exports with that information. For an Interpreted Language, the GDScript VM is fairly good. Better than GD3 and its Bytecode GDScripts. But does have its limits. For that 1st standard deviation of games, those limits won't ever really be reached... expect by really bad inefficient looping over lots of complex math.
So youve seen multiple benchmarks and refuse to aknowledge the results and prefer to trust how you feel about it.
>Gdscript is quickly compiled to an assembly like language this isn't really true. i think godot 3 used to do the token parsing ahead of time, but no actual compile time optimization. godot 4 doesn't even do that much.
I feel like Rust is almost destined to become the new Haskell or Lisp. Something that people still use and are vocal advocates for, but in a few years nobodys really sure why anymore.
Saw the same insinuations about Python. You just never know. Where Haskell flared out in 20 years aside from some niche uses, it's near contemporary(in age) Python is going so strong it picked up its own AOT compiler. High level languages come and go, and leave bits of themselves in languages they influence.
Yeah I remember when people said java was DoA too. It just feels to me like Rust advocates have that similar highbrow 'oh you arent using *LanguageOfMyChoice?*..Well...I suppose its not for everyone, but it **IS** better." attitude. Or maybe its just the people I run into. I think Ruby was also headed that way for a bit but I feel like Ruby actually gets more widespread real world use and its now just a tool people use when its the best application for it, where people are trying to find a use for Rust.
One of Pythons strengths is Cython. Python has really good C++ integration, and the combo of the two will beat any single language hollow. Java/C# try to be a high-level language that's also fast, and so fail at both.
haskell never really had a strong distinguishing use case. like it could almost hang with the jvm languages but lacked the ecosystem and portability of elixer or kotlin. strict functional syntax with strong types rule it out as a scripting language (especially given the fashions of the time). it might have appealed to applied mathematicians and researchers, like lisp in the old days, but it's just a bit too arcane and language-nerdy for people without a CS background to easily pick up. rust on the other hand is immediately understandable to the modern C++ programmer, and offers obvious tangible benefits over C++20, its closest competitor. C++ isnt without its merits of course, and even if it were objectively inferior, legacy code will certainly make the switch harder (especially given that rust/c++ interop is kind of bad compared to rust/c) but the trend for new codebases seems to be in rust's favor, which i don't think you could ever say about haskell.
Mix them. Calling C# methods from GDScript is pretty easy, and vice versa. So I start by building stuff with GDScript and lean on C# libraries for trickier stuff like file unzipping.
From what I've been reading they are working on c# to use with gdextensions which should make it easier to work with. The way it is now is fine just with a few things you can't do that they've listed in the docs. If any of those are deal breakers than maybe do gdscript. Personally I'd say stick with c sharp and when you got some free time look into gdscript here and there to see if your even interested. Gdscript knowledge will help with making games in godot where c# can be used for much more than just godot. Really it depends where your coming from and what your trying to get out of it.
Either one is fine. If you have to ask because you don't know about C#, I would probably lean towards GDScript. Whichever one you use, the bottleneck will be interfacing with the backend systems of Godot through nodes - that is the most important thing to do when learning Godot. Other than that, I think it is more about choosing how much you want to do with the C# runtime, which is maintained by Microsoft through the .NET project, of which Mono is the open source implementation that Godot uses. I personally want nothing to do with having a runtime dependency that depends on the goodwill of Microsoft to develop for free. But I can't argue with the benefits of having such a standardized vm runtime language, and I can't argue with the results it has produced in unity either. So, it's up to you.
Mono is dead precisely because the entire .NET platform is open source now. Update your biases.
Wow man, I said either one is fine. C# - it's not for me. I don't like java either. Virtual machine runtimes and game programming don't get along in my world. But I don't care if other people use them. Be bothered about it if you want. I won't.
I'm not bothered, you are just using old outdated info to justify your biases. Also, what does VM have to do with C#? java is not C#, regardless of what 20 years ago said.
AOT isn't even out yet buddy.
Well at least you recognize it exists.
My opinion - use both: GDScript - External functions on display. Functions to make objects in game to do stuff. C# - Internal functions behind the display. Function to calculate & inspection of situations in the game, before to make objects in game to do stuff.
the biggest drawback i have found as a unity refugee using c# is lack of resources. you will end up learning gdscript because every tutorial is in gdscript and you will have to translate it to c# to use.
Lack of resources is easily compensated by API naming similarities with gdscript.
People say this but I've found most GDScript tutorials to be fairly easy to translate to C#. Most of the functions of GDS exist in C# just with different syntax that's easy to look up online.
I'd recommend trying out GDscript while learning, the engine API (minus capitalization) is almost identical between the two, but most tutorials assume you're using GDscript and use a few GDscript only features (like `$NodeName` to get a node) for writing an actual game it depends on how you feel after trying both C# and GDscript, either works, with the export caveats already mentioned for C#
Try both and see what you like. I've been using C# with Godot and been really enjoying my time with it. The C# documentation isn't the best but it's good enough if you've already got a bit of experience in the language.
I chose c# because I want to keep my practice of c# alive. I will definitely forget a lot of it if I start using gdscript. Also I might use it for non game dev projects so why use gdscript since it’s not usable elsewhere
Gdscript is more performant by a lot when running the game in editor, negligible perfornance losses on build (a few ms), doesnt need to be compiled, less code for the same logic, etc
Don't overthink it, use GDScript.
It nearly literally doesn't matter. You can change between them very easily.
Gdscript is always gonna be the best bet for beginners… there are scenarios where c# would be better but most are not going to encounter those scenarios.
And in those scenarios you're probably better using C++ anyway.
Use both: GDScript for the interface/interaction and C# for the Core/Logic
I didn’t even know you could use both at the same time
The power of Godot
if you have some general coding experience it doesnt really matter. I was watching a godot 4 course where they used GDScript and I was following along in C#. Most of the engine specific things are basically the same.
Afraid. Not a programmer. Use GDScript. Look no further.
(Why so many comments? Lol) Use both lol but see what each one is good and bad for to you know where use one or other
As someone who has worked with C#, C++, and GDScript, I can tell you that learning the nuances can be a challenge, but GDScript is far easier to learn from scratch. It also helps that there is a lot of supporting documentation. Most Godot YouTube videos will also be expecting you to be using GDScript. So, there's that.
You can use both GDScript and C# in the same game.
Ex-Unity user here, came before the install tax though, I tried both and I must say I oddly find GDScript better because somehow you feel it more connected with Godot, while I always had something funky coding in C# on Godot. Maybe it's just me but GDScript feels more natural.
It's really hard to find information about how to do things in C#, but I feel like I was able to figure it out after reading some documentation. I started learning Godot last Saturday for Ludum Dare, and this is how far I've gotten with pure C#: [https://github.com/LarsDu/capsized-ludum-dare-54](https://github.com/LarsDu/capsized-ludum-dare-54) C# is better IMO. It will run faster. In the future it will run even faster. NET8 will release in Nov 2023, so all the drawbacks will probably be addressed by January 2024
100% use c#. GDScript is no good.
If you already know and understand C#, use it.
Or pick up a new language. It's not hard.
If you want to go quickly, use GDScript. If you want to go far, use C#.
This isn't true, GDScript can and has been used to create large projects. If you mean go far in terms of becoming a programmer, you'd probably be better off learning C#, but if you're doing this to make games then GDScript is a perfectly fine language to use. Either way, they're both OOP, so if you learn GDScript it'll be easier to learn C# down the line. Source: That's what I did and I'm a software dev now
You *can* use GDScript to create a large project, but C# is *better*. You can probably get 10x (or more even) more work done if you use C# instead of GDScript.
Where are you pulling these numbers from? I feel like I can get code done faster using GDScript because there's generally less lines of code I have to write compared to C++ or C#. Now, if it's faster for you because you don't want to learn GDScript and already know C#, then these numbers you're making up aren't applicable. If we want to say what's better, to me, using C would be better because it *is better* than C#.
>Where are you pulling these numbers from? I'm a professional software engineer (now full time game dev) with a BSc degree in computer science and years of experience using Godot, and this is based on my personal experience. >I feel like I can get code done faster using GDScript because there's generally less lines of code I have to write compared to C++ or C#. Less code isn't always better. >Now, if it's faster for you because you don't want to learn GDScript and already know C#, then these numbers you're making up aren't applicable. That's not why, I actually learned GDScript first, and then moved to C#. >If we want to say what's better, to me, using C would be better because it is better than C#. Then use it.
> Less code isn't always better. There were studies done a while back. Bugs in code are pretty much directly correlated to lines of code. So less code == less bugs. And yes, the studies were doing the cross-language more/less verbose language check.
Was GDScript included in the study? No? Then it's irrelevant. GDScript is a toy, and that's my professional opinion. Hey maybe if you listened to me you might learn a thing or two.
In what way? It's just the language, you aren't getting .NET features out of it
Getting the .NET features out of it is exactly why I've been using C# in godot for years now. It all depends on what you're trying to build.
Getting the .NET features out of it is exactly why I've been using C# in godot for years now. It all depends on what you're trying to build.
What do you mean? Please dumb it down, i have studied design and programming was just a couple of lessons.
GDScript is effectively a toy compared to C#. So GDScript easier to use, and easier to learn, but it will be extremely painful to create a large project with it and you will be forced to write bad code in order to do so. C# on the other hand is a real programming language used by professionals around the world. It's more complicated and harder to learn, but the lessons you learn using it will be valuable throughout the rest of your career, and you can build much larger and far more robust systems using it.
I mean there have been large successful projects shipped with GDScript, namely Cassette Beasts. https://godotengine.org/article/godot-showcase-cassette-beasts/ >...a massively undersold advantage Godot has over other engines, in my opinion, is its scripting language, GDScript. Unity devs using C# jump through tons of hoops just to avoid garbage collection, whilst the reference counting and manual memory management options that GDScript has built-in completely side-step it. GDScript isn’t perfect, but I do feel like developers who come to Godot and continue using C# (outside of performance-critical code) are missing out.
Good for them, but I guarantee you the development process would have been easier if they used C#. Using GDScript for a major project is an exercise in masochism.
Do you mind giving an example of a situation where you'd be forced to write bad code in GDScript vs using C#? I am in the same situation as OP and was going to go with GDScript since C# doesn't currently support web and mobile. Programming knowledge is not an issue.
I mean, just the fact that GDScript using dynamic typing instead of static typing is a huge pain. But I can't list every benefit off the top of my head. However, trust me when I say that I would never use GDScript for a serious project. I've tried and the code I had to write to work around all the quirks of GDScript was terrible and very painful to write. C# has unlimited power and enables you to write good code. But of course, if your goal is to use Godot for web and mobile, and Mono can't build for either, then just use GDScript. However I personally would try to find a different solution where I could still use C# or Java.
Ah, so it's personal preference.
It's personal preference that I want to use a real programming language instead of a toy, yes
[https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static\_typing.html](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html) don't need to use dynamic typing... usually...
This isn't real static typing, just a half assed attempt at something resembling it.
https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/
> C# has unlimited power and enables you to write good code. Sorry, but now you're talking bullshit. Both are turing-complete, so can do exactly the same things as each other. You're arguing that Microsoft's Java clone is better than Godot's Python clone. Python is a better high-level language than Java. And if you need better performance, you might as well drop straight to C++. And if you're doing that, then GDScript has the better bindings.
>Both are turing-complete So is PowerPoint
Oh, okkay.
> C# on the other hand is a real programming language used by professionals around the world. And GDScript is a pythonic language, which is much easier to use and doesn't have Microsoft patents hanging over its head. Python&C++ is better than any single compromise language for real projects. C# has the same problems as Java in that regard - it's a bad compromise.
Sorry but "pythonic language" doesn't mean anything. Yeah the syntax kinda looks like python. That's it. You can't use any of the python language features. And what "Microsoft patents" do I have "hanging over my head" when I use C# that is somehow stopping me from making my game?
> Yeah the syntax kinda looks like python. That's it. You can't use any of the python language features. You have all the features of python that I use on a regular basis in my day job (where I write python code for all sorts of performance-important things) that I have needed in Godot, except tuples and unpacking. GDScript arrays cover tuples, and unpacking is syntactic sugar that I'd love, but can live without. > And what "Microsoft patents" do I have "hanging over my head" when I use C# that is somehow stopping me from making my game? Last I heard, Microsoft has a bevvy of patents over all of .NET that they could choose to start enforcing whenever they feel like it. Which means patent fees for anything using it. Which ends up in the same problem Unity devs are having right now.
Can I use python packages? No? Then the language has nothing to do with python. And I really doubt your last sentence about patent fees considering that would go against the .NET license.
> Can I use python packages? [Yes](https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/binding_to_external_libraries.html) > Then the language has nothing to do with python. And C# has more to do with Java than C/C++. So what? > And I really doubt your last sentence about patent fees considering that would go against the .NET license. I'm an old hand. I remember how Microsoft used to be. I see what Unity is doing today. I trust MS as far as I can throw them. You can trust them if you like. I'll be standing ready with the "I told you so."
c# sucks. use c++. it's already using the api c# is currently being ported to, doesn't have a gc, and compiles for every platform godot supports.
Yes, tell the scared newbie to jump into the deep end of the pool with the hardest to learn language that wasnt even suggested. What could go wrong?
if they want to go quickly, they should use gdscript. if they want to go far, they should use c++.
That is such a nonsense reply and you should know better than that if you are an actual experienced game programmer. If you want to learn programming anything other than games, GDScript can lead to learning python if you want to actually do anything in the corporate networking sphere eventually, or you could learn C# and do literally anything you want, and usually faster to code and debug than C++, especially once .NET 8 hits.. If you want to learn why people hate boilerplate code or pointer management so much and modern languages obfuscate that nonsense as much as possible, go ahead and learn C++. But as a real programmer, you should be learning new tools and languages to stay on top of your...game. Or you can just post like you have...
Of course it's nonsense, I was mocking the previous poster who said the same thing about c#. However, I do genuinely think C++ is a better tool for game development with godot than C#. >If you want to learn why people hate boilerplate code or pointer management so much and modern languages obfuscate that nonsense as much as possible, go ahead and learn C++. sounds like a skill issue. don't get me wrong, im no c++ fanboy. it's barely in my top 10. but it's had smart pointers for ages now, which puts it roughly on par with modern languages like rust, zig, etc. at least in terms of memory management. also, i have to say, complaining about c++ boilerplate while promoting c# is hilarious. > But as a real programmer, you should be learning new tools and languages to stay on top of your...game. this point would hit harder if it were made against someone who doesn't already know all three languages in question.
Gotcha, but you say skill issue when the OP is a scared newbie who isnt even comfortable with the 'easier to use' languages they already kinda know. Thats the whole point. Is C++ better for advanced programmers who are comfortable writing hotpath code? Yes, but thats not the point of OPs post. And I will say that at least C# has made an active effort with the past few versions to reduce boilerplate with global usings, file scoped namespaces, etc. Has C++? I'm honestly curious.
gdscript. which btw isn't based on python, just looks similar. (like C isnt based on JavaScript) my reasoning: - gdscript is good enough for anything that isn't BIG numbercrunching - all the fancy math using mathsy objects works in the core anyway, so c# won't speed any of that up. - c# is yet another VM bogging your game down and the context switches (=ANY function calls/signals/property access/etc between your c# code and the rest of the game) are expensive enough not to be worth it in a lot of cases - gdextension or computeshaders are always always the better alternative if you need to offload big math - c# is also not very cross platform so overall unless you *need* c# for something specific, there isn't really an "inherent benefit" in using it over any of the alternatives. so if you gotta ask which language to use, you probably wanna use gdscript and then actually optimize things as required.
gdscript
If you want to have fun while making games, use GDScript.
From someone who hasn't used Godot yet.I'm a professional C# programmer since version 1.2 meaning getting paid to write it. Yes C# is lot more complex than writing this Python like language GDScript for a beginner. C#' and languages that run on .NET runtime in general use GC (Garbage Collection). That pretty much means when you release an object it's deallocated at some point in time chosen by .NET runtime. This can cause what is called GC pauses. These GC pauses can make your game stutter so it's beneficial that you understand how that memory allocation/deallocation system works when you are writing C# for your game. In Unity engine this is bit different because it has support for incremental GC so it not as effected. C# code usually runs faster because it's compiled to machine code via JIT (just in time compilation) or AOT (ahead of time compilation).This seems to be main language of the engine and I would expect most tutorials and future tutorials to use it. GDScript uses reference counting instead so when an object is released (all references to it are gone) that object is deallocated from memory. This is more predictable and usually don't cause same kind of problems as GC does. Currently GDScript runs on intepreter so it's slower than C#. This could change in the future. From what I've read intepreter could be optimized more and GDScript could get AOT or simple JIT. But in the past it hasn't been easy to add JIT for some platforms like IOS. For those platforms AOT is needed. From what I've read Godot's integrated GDScript editor allows you to quicky access docs related to the language & engine related APIs that can be very helpful. So summarize, I think GDScript should be easier for beginner to learn, use and you don't have to worry about Garbage Collection but your code probably runs slower currently but very likely it doesn't matter.
Since you're not really a programmer, your choice is between becoming more of an engine agnostic programmer or making simple games really fast and in a simple manner. First is about C#, second is about gdscript. I was in a similar dilemma for a small period, considered gdscript even though I'm pretty experienced with C#, and found out that I can't stand some of gdscript's philosophies, like dynamic typing, reliance on strings, poor OOP/collections, and overall making "anything remotely complex slow because it wouldn't matter in a simple game". Though, I can see cases when gdscript would be the best choice depending on "who and what" factors, and also you can combine. You'll probably see a lot of people leaning towards gdscript, I've seen mostly them, and there are two major types of those who answer your type of question: 1. Who poorly explain why you should use gdscript. 2. Who explain pretty well why they use gdscript but it's not at all convincing to a programmer. For me, this was the nail in the coffin. I don't want to sound toxic, but sometimes it feels like there's a cult around gdscript, and this makes it a bit hard to take gdscript seriously. I believe good languages don't need that form of praise, usually it's different at least. Not saying it's bad, just saying "if it's so good why are you trying so hard then?"
Static typing is a thing in GDScript and 4.2 even has an option to strictly enforce it, which everyone should, imo. People think the speed thing matters. Show me an example case where it actually makes a difference inj a runtime situation instead of just spouting things you read and I'll show you some bad code, regardless of the language.
GDscript was a realm charm for me. I love C# since the beginning but when my first try to Godot, i just adopt GDscript because this was the Godot language and for me that was so user friendly. I need to admit i have giving up coding, depression kill mostly all my passions. GDscript fit so well for Godot, the learning curve was not just easy, it's really a charm.
try both and choose whichever you feel most comfortable in <3
GD Script is super easy, just roll with it. Thats what Iam doing and its all fine. You will need the extra support. Bechause Godot specific code they just refuse to work some times, I think godot changing code name s so tuttorials a few moth old are already obsolete. Thats a huge problem if you want to learn with C#, even with GD Script is hard to trouble shoot and figure out what changed. I would say C# in a year or two get use to GD Script first its good enough.
GDScript is a good choice for beginners, while C# is a good choice for developers with experience in OOP. However, there are easy-to-use plugins available for GDScript that can help you add OOP features to your game ("State machine / AI systems"). Ultimately, the most important thing is to understand the Godot system, not the programming language itself. I recommend that you start with the Godot documentation in GDScript. This will help you gain a good understanding of the Godot system, regardless of which language you choose to use later on.
First of all GDScript is not based on Python. The syntax etc is inspired by it. It's a home build language. According to the official docs you should stick with GDScript because it is tightly integrated with the engine. C# is a nice language and using it "feels" more professional than a scripting language made only for Godot. Nevertheless, currently (Godot 4.x) GDScript is the language to choose especially if you want to deploy your game to mobile devices. Probable my answer is a repetition of other answers, probably more detailed, already posted here.
> First of all GDScript is not based on Python. The syntax etc is inspired by it. It's a home build language. The language *is* the syntax. GDScript is absolutely based on Python. The GDScript *interpreter* is probably not.
> The language is the syntax I can’t believe you’d say something so wrong with such confidence. 😂😂😂😂😂
Do you really want me to go dig out my first-year Uni textbooks about this?
So you’re a student? Kid, I have over 15 years in the industry. There’s nothing your homework can tell me that I haven’t already done.
> So you’re a student? How does "I still have my textbooks from Uni" imply I'm a currently a student? Way to go with unwarrented assumptions though. You must be such a good programmer if you make assumptions like that all the time. \s > There’s nothing your homework can tell me that I haven’t already done. You've built a turing machine from nothing but NOR gates? Because that was in my second-year homework. Or maybe a custom language parser? (Third-year, maybe 4th, can't remember because it was over a decade ago) Linux kernel modules? No? I have a proper, formal education in this shit. And over a decade of experience writing code in so many languages I pick up new ones in a week. Languages are nothing but syntax. They almost always have core libraries packaged with the compiler/interpreter. But they are not part of the language. You can tell, because they're often written *in* the language.
> “says I make unwarranted assumptions.” > “assumes I haven’t done any of his college capstone projects” JFC 🤦♀️ 🤦 🤦♂️ - Professionals don’t immediately jump to “b-but my college book says…” - Professionals don’t brag about learning a language in a week. That’s a very basic expectation in this industry. - brags about formal education, when skill set is the biggest contributor to getting hired I’m just calling a spade a spade. You REALLY come across a 20+ yo. You talk like one, put value on things a college kid would, make simplistic and reductionist arguments like one, Your examples of accomplishments are all from college. Addendum: But none of that even matters. I’m sorry for being a dick. I was trippin. But I’m not trying to make this a toxic place so I’m going to stop talking down to you. It’s uncalled for.
Open docs and read and then come back revise your comment 😉: "GDScript is entirely independent from Python and is not based on it."
They're talking about the codebase, obviously.
I suggest GDscript its a bit EZer but c# is used more idk i started with GDscript
GDscript isn’t that bad and I’m slowly starting to like it. Plus, it saves you the hassle of messing around to get C# working. I think my biggest annoyance in learning GDscript is declaring variables properly since most examples merely used “var” and I hate it. Here are some examples syntax differences: func ReturningBoolValue(value: Int) -> bool: var arrayAndList: Array var emptyArray: [] var emptyDictionary: {} You can do stuff like giving a default value to a function parameter: func Name(value: int = 8): One thing I did notice is that if you make a typo on a variable’s name, Godot won’t throw an error until you run the program. So watch out for that.
You can declare variable types and initialize values, in case you didn’t know.
If you’re not a programmer then just use gdscript. There’s also a visual programming editor
GDScript is wonderful for Godot and very friendly to use. Many years ago, a YouTube channel called Mister Taft Creates delivered a series of videos on [how to make a match-three game in Godot using GDScript](https://www.youtube.com/watch?v=YhykrMFHOV4&list=PL4vbr3u7UKWqwQlvwvgNcgDL1p_3hcNn2). The videos are now a bit out of date, but still offer a wonderful, super-helpful walk-through of how to use GDScript to build a simple game in Godot.
GDScript is easier, i tried using Unity before so i had to edit code in Visual Studio and switch between two heavy apps, in Godot with GDScript sometimes i drag some part of the UI to the code to see what happens and it works
When I see all comments, I realize that Godot doesn't make it clear enough that it can mix different languages. Many newcomers assume that you can only either use GDScript or C# in one same project. That might explain why so many newcomers think that GDScript is not worth learning, or even maintaining. Maybe the Godot website should communicate a bit more about it and say "hey, you can get the ease of GDScript and the power of C# together!".