Just coming back from little try of Unity and wonder if it makes sense to use mono version, I quite like VS Code as IDE instead of built in Editor .
Quite liked some of the features the C# provides such as “interface” and “scriptable object”, but unfortunately Unity heavily failing to deliver consistent rendering quality to Mac ( it stutter for some reason in build versions ) .
C# has a MASSIVE ecosystem of NuGet packages. There’s a NuGet package for literally anything you can imagine, and skills you learn with C# you can take with you everywhere else, since it’s an industry standard.
However, if you’re only starting off, and you’re not interested in using other engines in the future, and you just want to keep this as a hobby, go with GDScript. It’s a lot more friendly.
So if you want to work for big companies, learn and use C#, if not, just use GDScript
Also edit: “scriptable objects” aren’t a C# feature. It’s a Unity feature.
so NuGet is much different from GDExtension in terms of performance ?
I still treat it like hobby, but tried a few languages and Python/GDScript are easier but speed of C was multiple time faster so just wonder if this could be used for something where GDScript just is not fast enough .
C# currently has some drawbacks–mainly that it can’t be used with web exports and many Godot community addons don’t provide C# support. But if you like C# and don’t plan on publishing to web (e.g. for game jams, especially) then go with C#.
You can do that, buf if you’re entirely new to C#, I highly recommend doing some basic tutorials first. The ones provided by microsoft are really high quality and good.
not completely new but not experienced either , as only started in mid January on Zenva , before was GDScript in Godot and mainly Blender following Grant Abbit’s courses on GameDev.TV
I have just started making games and have found that GDScript is easy to learn but I’m not sure if C# has any “benefits” and it also depends on preference and what kind of game you’re making. (again not sure since first time
C# has many, many benefits, it’s a much more mature language, it’s the industry standard so with C# experience you can go work at a lot of places.
The same sadly can’t be said for GDScript, putting that on your CV will likely get you no jobs what so ever.
You can use VSCode or Rider as an external editor with GDScript, so that’s not a reason to choose C#. If you like external editors, I recommend checking out Rider. JetBrains makes fantastic IDEs.
Godot has support for the @abstract keyword, which provides everything that interface does except supporting multiple inheritance. However Godot’s node system works very well with composition and can be used to leverage the features of multiple inheritance in a different way that is frankly often less confusing to new programmers.
That’s comparing apples and oranges. NuGet is a package manager, like the AssetLib tab you use to install Godot plugins.
GDExtension has language bindings that allow you to use Godot with a programming language other than GDScript.
C is faster than almost everything out there. But let’s be clear, C is an older version of C++ that does not have support for classes. Almost all programming languages are written in C or C++ - at least initially. And you are talking about C#, which was originally written in C and C++, but now is bootstrapped, which means it is written in C# these days. (It consumes itself.)
If you want to write in C++, that’s a completely different discussion than what we are having, and even more difficult than using C#.
Having said that, there are very few things that C# does these days that it does faster than GDScript when it come to Godot. Because C# is a multi-purpose language, and GDScript is highly optimized to make games in the Godot editor.
That’s a slow and likely frustrating way to learn. Learn the language, then learn how to make games in it. It’s a longer learning curve than using GDScript.
It all depends on your perspective. You are not new for a Godot developer, but you are very new compared to professional developer. And while I like both the GameDev.tv and Zenva courses, I will say that both of them teach some really bad GDScript habits.
I know you’re trying to be helpful, and I applaud you for that. But preference often leads people down the wrong path when it comes to choosing C# over GDScript. They come from Unreal or Unity and believe that the experience of years of scripting is going to make the transition easier. They also often falsely believe that because C# is a “real” language (I put that in quotes because that’s not something all professional developers agree on), that it will be better for game development.
It also does not depend at all on what kind of game you are making. It used to, back in Godot 2.x and Godot 3.x. Now, Using 4.x if you are creating a game in Godot that needs code optimization, you really should be looking at using C++ and GDExtension.
I agree with this, and everything else that @tibaverus has said in this thread. However I do not believe that learning C# in Godot is the way to add something to your resume. If you are learning how to program, and making games excites you, use GDScript. Then if you want a language on your resume, go actually learn C# or another programming language and learn how to make something else other than games with it. The skills you learn with GDScript will not abandon you.
I say this because if I see C# on a resume, I’m going to ask you C# questions, and OOP questions, and software development lifecycle questions. Two minutes in I’m going to have dismissed your skills because you’re going to think you know what you’re talking about, and I don’t. And I’m the one hiring.
If you want to become a software developer, learn how to be a software developer. I’ve seen plenty of applicants with 4-year bachelor computer science degrees that can’t program their way out of a paper bag.
If you want to become a C# developer, go learn C#. If you want to be a software developer, you need to know more than one programming language. And AI is just going to make it harder to prove you have that knowledge, so really learn how to program.
Generally I tell people not to start with game development if they want to learn programming. I find that it’s unnecessarily cruel to beginners, and they WILL give up on both programming AND game development before they get anywhere.
However, when it comes to learning programming, I find C# to be quite nice, as it has a great balance of forcing new users to learn about the different variable types (and not just rely on var or letcough javascript cough cough), BUT it’s not so complex (looking at you, C++) that they won’t get anywhere even after weeks of learning.
WoW, many thanks for this input.
I was not really into resume , rather to finally have idea how to make - Working, Visually pleasing , - survival game and fiddle with some ideas example
" like transition of day/night cycle was stored in empty gameObject which I guess could be Node and attach to it two different DirectionalLight nodes "
One thing I missing and wonder what be closest way to do is Inventory system where its 3d object is represented with collider and also as, itemData which occupy slot in UI element as button with Icon and checking for state of type of item to equip, consume, destroy, stackable/ non stackable .
Check out Godot 4: Build an Action Combat RPG | GameDev.tv by GameDev.tv. Bramwell’s explanation of how to do an inventory in a 3D game is the best one I’ve seen anywhere, even in free YouTube tutorials. I refer back to that project all the time for reference.
I done that and it’s way too many nodes , also it’s not dropable only equip and take from chest to inventory , so half of job .
thinking of how to link 3d object ( best if is rigid body ) with resource which is represented in inventory .
Example https://youtu.be/DpMv7646Kqw?si=Kyziil5vouUnTU8c , it exist on interactive layer which is detected by ray from camera to pop up interaction , if is stored to inventory then it’s removed and vice versa when dropped .
Ok, but it’s enough to show you how to do it. Dropping an item is pretty trivial. You allow the user a drop command from inventory and spawn the object on the ground. Obviously he didn’t include models for that in the tutorial, but it’s literally just taking what you learned about chests and doing it backwards.
Also, ok if you think it’s too many nodes to make a good-looking inventory item, make something simpler. But that’s what scenes are for, so you can layer things.
I didn’t look. You can use a RayCast3D if you don’t want to use Control nodes, but you’re going to run into a bunch of problems later on IMO.