Hello everyone. I have recemtly decided to start using Godot for my game projects.
I have about 18 years of experience coding in C# and thought that I could continue using this language while developing with Godot. Through reading through docs and forum post, its seems to be that C# can be some what limited to using GDScript (Profiller doesn’t work, must recompile entire project for code changes to take effect).
I was wondering what you would recommend using in Godot?
Is it worth learning GDScript for some additional functionality?
Should I stick with my trained knowledge of C# despite less features?
What are some pros and cons of using one over the other?
Thanks for taking the time to give me some feedback.
I have thought a lot regarding what to chose, and the answer is, whatever you like. If you do not have experience in game dev, I would recommend to start with gds to just get familiar with the env., functions, nodes etc. and when you feel comfortable using Godot, start switching to C#. gds will be faster, as it is built on top of C++, and its basically the Godot’s main language, but it does not mean that C# is bad uisng in Godot. Start with gds, get familiar, and then switch to C#.
When I first picked up Godot, I started with C# as I was already familiar with the language. I then later gave GDScript a try to see what it’s like. Personally I prefer GDScript. The engine integration is really handy, no recompiling every time, being able to change code mid testing without restarting. The faster workflow is what hooked me.
Then again, C# has advantages too. The biggest thing I miss in GDScript are interfaces. With neither multiple inheritance nor interfaces, it can be hard to write code that is flexible and avoids redundance. Not to say it’s impossible though. Access modifiers and certain data types like uint or smaller ints like a byte are also a C# only thing. Also if you wanna use any already existing C# libraries you have to use C# of course.
It’s also important to consider what kind of project you would like to make. I am not sure if Web export with C# is a thing yet. When I started it wasn’t. You can always mix and match C# and GDScript within the same project too. However, C# limitations are applied.
So yeah. For your first project it probably really doesn’t matter what you use (unless you need Web export). I would probably recommend starting with C# to focus on learning Godot and then trying out GDScript later. Just so you don’t have to learn EVERYTHING new at once. That is what frustrated me a lot at first. And once you tried out both, you can pick your favorite. :>
@olekmandruk, is that true? I was under the impression that C# was the faster running code. At least I heard people say that GDScript in comparison is slower. But maybe that’s just certain people being louder than others. I don’t have any data to back up either side.
Yes, for calling inner functions gds is faster, but for doing custom calculation C# will be faster. On YouTube I found a video, where it was compared which is faster and when.
Replied again as not sure If I hit the reply button
I think you should at least have a look at gdscript and then decide what you prefer. It’s easy to learn with your experience and you should quickly see whether you like it or not.
And in other similiar posts here or on reddit there should be mentioned all the pros and cons people have.
In my opinion, everyone should develop in GDScript, and then for things where it makes sense, refactor into C#. GDScript is always going to be faster accessing godot internals.
C# is faster at some things but not all. Collections, and Collection.Generic, C# is demonstrated to be as much as 20x faster…BUT, unless you have very large data sets doing lots and lots of read/write/sorting operations (basically a data science project) you won’t realize any real benefit from that.
System.IO is also measurably faster if your network game is an MMO or high CCU high speed FPS, then you might want to consider building your network class in C#, but otherwise…you won’t see any real performance gains.
The gain in productivity speed of using GDScript in most cases is overwhelmingly more beneficial than the incremental performance gains you are going to see using C# for most use cases.
At the very least become versed in it, prototype in GDScript and refactor in C# If it makes sense.
as a note, most people here use and swear by gdscript. asking if c# or gdscript is better would be like going to a Mac forum and asking which is better: Android or iPhone? it is what it is, myself included, just keep that in mind.
with Unreal and Unity, there isn’t really a gdscript debate because there is no gdscript equivalent. Unreal uses c++ and Unity uses c#. gdscript will never have the people and resources behind it that c++ and c# do. it sucks but that is reality.
learning a new game engine and learning a new programming language at the same time, i think it would be better just to learn the game engine and stick with the programming language you already know.
at some point it wouldn’t hurt to learn gdscript, sometimes it is convenient to throw a simple script into a node to test something.
Don’t really agree, C# is more adult language. you get some benefits from coding in it. and you can always can refactor to GDScript for your optimization if needed .
For heavy duty still can program C++ and put there assembler code inside.
When you know how program C# in Godot you will be able program GDscript with no extra effort.
No offense but I have to disagree here because of the thing i mentioned earlier.
GDScript is very much built in a way that best supports component based systems as it has the limitation of no interfaces nor multiple inheritance, as well as Godot itself only allowing one script per node. If you are not used to that, for example because you previously worked with Unity, this will be something you will need to learn in addition.
While in C# you would do something like
public partial class Player : CharacterBody2D, IHurtable, IInteractable, ILootable
in GDScript you would need to make a separate HealthComponent, an InteractComponent and a LootComponent and attach them as node children. Then also manage how these components communicate with each other as the functionality has been spread out more and so on.
If you have worked with component based systems in C# before then it’s fine, but if you haven’t, it is something you should ideally know when working with GDScript. Because in C# you have the choice, while in GDScript, you are more or less forced.
generics are incredibly convenient. without them i would die. public/protected/private etc… overloading virtual elements of a class. extension methods. implicit/explicit operators. easily placing globals into static members of a class. not having to deal with signals except for interacting with godot itself. there are so many convenience of using c#. with c# you have a lot more flexibility. external IDEs have countless quality of life features, such as the ability to rename all elements in your code with a key press.
Maybe that’s just my fetish, but I would try to avoid any class declaration like that in Godot.
We are using an engine where nodes can be composed freely. Inheritance makes composing very hard since you can’t just plug-in new behavior without introducing a new layer of abstraction.
A component based approach forces you encapsulate behavior by default.
Having a HealthComponent that works in a general way is much easier to reuse. It’s also more understandable than hiding it in different implementations.
you can use properties/signals to access variants created in gdscript from c# and visa versa. the only downside is this is limited to variants. so if i have a function in gdscript, i can invoke it from c# as a godot callable. it is messy but it works.
That’s not my point.
Of course you use inheritance. To extend a node you need to inherit a Node.
You shouldn’t design features based on inheritance if it can be solved otherwise.
That’s not a personal opinion, rather a common technique.
Generally I’m arguing from the point of a professional. For me it’s more important to have a readable and understandable project that it’s easy to get into as a new dev.
For example: a large inheritance tree is a first slap in the face of new dev who should implement a certain feature for a new entity. You need to encapsulate this behaviour first and make it reusable.
You’re right but being restricted to Variants is not a good deal imo.
When I get a pull request with a comment like “it is messy but it works” in a fundamental component, it’s rejected with
I’ll leave it at that since OP probably knows the ins and outs of inheritance.
Would be nice to know what OP decided to use and why
.
