C# is BETTER than GDScript but...
HTML-код
- Опубликовано: 25 ноя 2024
- Which language should you use for scripting in Godot 4? Clearly GDScript right? Well, yes and no. C# vs GDScript debate settled.
In this video, we'll compare C# and GDScript, two popular programming languages for Godot. We'll explore how they're similar and different, and which one is better for specific tasks.
If you're looking to learn more about C# or GDScript, this video is for you! By the end of the video, you'll have a better understanding of which language is right for you and how to use it to improve your programming skills.
First off I'd like to say that I am super happy that I was able to start a dialogue about this. The response was not expected. I have made a list of some of the common questions I am getting and I'll do my best to answer them here for you guys. Feel free to let me know if you feel like I have misrepresented something or missed something you think is important. I will leave this comment pinned and update as needed.
TLDR
It doesn't matter which language you use as long as you understand the limitations of it, and GDScript has some pretty severe limitations.
1. "Why not use the bindings? They are a language feature!"
What if there is no binding for the logic you are trying to implement? These tests were specifically designed to test workloads that are common in game dev. The tests, with the exception of Fisher-Yates shuffling have no equivalent binding in GDScript; at least not one that I am presently aware of, and please correct me if I am wrong about this. GDScript uses heap sort in its binding, I wrote the test with bubble sort. GDScript has no binding for matrix multiplication either. Using bindings is an acceptable way to write your logic, but they aren't always applicable, and in some cases they simply don't exist. In that situation you must write the logic out yourself in a different language to avoid the performance degradation. Doing this means you now have to know and manage two languages in your code base which is not beginner friendly and should be avoided where possible. What if you need A* pathfinding or a flood fill algorithm? I would be interested in seeing an entirely GDScript solution to such algorithms that are computationally intensive or require recursive iteration, even if they did incorporate some bindings.
2. "C++/C/Rust is faster though!"
Yes, a low level language is faster. If I put a set of tires on a Toyota Celica and put those same tires on a Ferrari F40, the tires on the Ferrari will go faster. Is it because the tires are faster or is it because of the vehicle that carries them? Your CPU doesn't know C# or GDScript...it doesn't even know C/C++. Your CPU knows machine language and lower level languages require less interpretation/compilation to translate the instructions into something the CPU can read. C# and GDScript are HIGH level languages and that is what this video is testing. All of these algorithms will perform better in a low level language, although the performance gains may only be slight over C# in some instances because C# is a compiled language whereas GDScript is interpreted; this distinction is important.
3. "C# is harder to learn than GDScript!"
Yes, absolutely. It does not have the bindings that GDScript has which are essentially shortcuts that allow you to skip writing some parts of your logic in favor of efficiency. The bindings that are available are wonderful. They will speed up your coding quite a bit, even if you are familiar with the logic they are performing. However, they remove ALL control of their logic from your hands. For me, this is a problem because 1.) I want absolute control over my logic and 2.) If you don't know how to write the logic yourself, using the binding is not going to teach you how to do it. I can write Fisher-Yates or Bubble Sort or any of the other algorithms I have learned over the years in any language I'm asked to write them in because the logic is essentially the same everywhere. Beginner developers SHOULD be learning these things because they are crucial to your career as a software developer; and not just in game development but across the entire industry. I don't hate bindings, but I cannot in good conscience promote their use for someone who is trying to learn software development. I'm old enough that I remember having to memorize phone numbers, so I might be a little old school in my thinking here. Use them if you have them, but be aware that they will not always be there.
4. "C# has more features that GDScript"
Yes, it does. C# has been under development by one of the largest software corporations in the world since the year 2000. It stands to reason that C# is going to be the more feature rich language. It's also more widely used and more performant for the same reason. The longevity and applicability of C# is a very important consideration to make if you are trying to get into the software industry. There simply are no jobs for people who only know GDScript; I cant say there are absolutely no jobs, but those jobs are going to be few and far between. The thing about the software industry is that we would all like to be game developers working on the next big thing, but what we actually do is write automation software to replace Dianne, the secretary, so some company can save $45,000 a year on employment expenses. We also work with databases to collate and analyze sales information to more effectively target consumers. We all hate working with dates and aren't too fond of having to write regex either.
We make games on the side because we love them; we don't do it for the money. We do it because we love games and love to share them with other people. There's no reason to question everything that every other developer does. It's actually our duty to help out other developers whenever we can so that they can flourish and hopefully some day help us out when we need it. That's literally all I'm trying to do here guys. There's no need for debate. There's no need for flexing our collective knowledge and there certainly is no need to diminish someone else's opinion because we all have different workflows and experiences.
Also, C# is totally better than GDScript. Thanks for taking the time!
If we follow your logic, we can go all the way to assembly language. You want complete control over the logic. Why don't you want full control over the renderer, for example? Also, maybe you don't need an editor, you can use a framework and have even more control.
How do you deal with the gc stutters in C#?
@mannythepirate great question. Any garbage collected language can be subject to stuttering if you are generating a lot of garbage. The two most common approaches to mitigate this are minimizing the garbage your code generates and manually collecting the garbage during periods of the gameplay where it would be less noticeable. Garbage can be manually collected with GC.Collect.
In order to minimize garbage generation the best thing you can do is to avoid storing transient objects on the heap. Reference types are always stored on the heap, value types are usually stored on the stack and when used properly do not generate garbage.
Another consideration to make is object pooling. If an object must be stored on the heap, which is common with most objects, there's no reason to free that object if it can be reused. Examples of this would be particle effects, damage numbers, bullets, etc. Objects that can be recycled should be recycled.
All of these things are common practice in any C# programming tasks.
C# also allows manual memory management through unsafe methods, but care should be taken when writing unsafe code as it can lead to memory leaks and unexpected crashes.
Personally I went with c# not just because of the performance, but the language features and the eco system. Godot in general as a language just feels very limited to me, but that’s mostly because I generally use strongly typed c style languages at work (c#, cpp, java, ts).
With that said, go with the language you’re comfortable with. You can always just optimize and refactor once you need it anyway.
100% right, it's far more important to use the language you are comfortable with and just understanding and working within the limitations. GDScript has some pretty severe limitations when it comes to writing custom logic that doesn't already have an integrated binding. Thanks for watching!
for me, the decision is very simple:
learn C# and you can do: godot, unity, flax, (other game engines that use c# (or your own engine)), web apps, servers, desktop apps, mobile apps.. almost anything you can imagine. Its highly versatile language
learn GDscript and you can do: godot
That's pretty much the situation, yes. Thanks for watching
Or learn the "all programming languages are the same, pseudocoding and algorithmic skills matter more" doctrine and you can do: any engine you want. Anything you can imagine. More versatile than any single language
16 years ago I started to learn gamemaker and GML - now I senior unity developer. This is an example of how this can scale up. You start with simple language with easier learning curve, with super ease and interesting environment (you need one or two program to make a game (in terms of godot you need also image editor)) and just learn what it is about. What is programming and so on.
@@WeslomPo For people that are absolutely brand new to programming, they should use Scratch or some other visual scripting language engine until they learn to solve problems iteratively and construct logic. I really wish things like that existed two decades ago when I started.
@@hamsterbyteI don't think so. GameMaker also has DND visual language, but it is not worked to help understand anything about programming, but help chm file with description of GML was helped. I think major problem is motivation. If you start learn general language - you have to imagine some irrelevant problems that you need to solve to gain experience and learn something. But if your goal is a game that you want to play so badly, and first steps looks easy - you lose motivation over longer time.
I'd disagree with "it's an unfair comparison". If you write something in GDScript and it does something sneaky as far as I'm concerned it's still GDScript. It's not cheating. It's smart.
Good video though. Cheers dude
It really comes down to the fact that passing the workload to a lower level language means that the logic isn't being executed in the same language it was written in, which of course is true of all languages outside of machine code. That being said, comparing C# to GDScript bindings that are passed directly to C++ means that it is no longer a direct comparison of high level languages. There's no debate to be had about a low level language being more performant than a high level language and testing performance metrics in that way is not valid. Of course, everyone is entitled to their own opinion and that is mine. Moreover, it's worth noting that not all possible logic can be represented with bindings and these tests are targeted at those situations. If you ignore the existence of bindings, these are the metrics you can expect across the noted workloads. In a situation where a binding is available, not only should you use it, but you must use it in order to maintain performance. Using the binding means that you are sacrificing control which is something most experienced developers are not willing to do as it can make certain operations more difficult, if not entirely impossible. When you encounter this you have no choice but to use a more robust language, which begs the question, why use GDScript in the first place knowing that something like this may be inevitable? Again, this is all my opinion, but that opinion is formed around concrete facts and I do stand by it. The most important thing for any developer is to use whatever language they are most comfortable in and working within it's limitations. Thanks for watching and I appreciate your engagement! Always nice to have a dialogue about things.
The problem is that the performance benefits may only exist in that one test and aren't representative of if you were to use GDScript in a different scenario. We're not doing tests to figure out the speed of specific algorithms, we want to know the general speed of the language so we know what to expect from our own algorithms.
@@NihongoWakannai It might not be obvious whether your code is using this lower level language. Most of the time it wouldn't matter. It's transparent. As far as you're concerned you're using GD Script. I suppose that's a problem with all modern languages. There's more than one way to skin a cat. If you've written code that works, how do you know if there is a much more efficient way of doing it. Experience and hard work. Who can be bothered with that! :)
You make a good point though.
@@NihongoWakannai again, exactly this.
Godot Bindings to CPP is a perfectly fair way to compare the languages. Bindings ARE a language feature, not a hack. Its even easy to do, as its well documented.
I totally agree, its a feature of the language but I get why he says that.
I appreciate your opinion, but I respectfully disagree. What you deem as a feature is actually a pretty substantial limitation. As I've said before, the best language to use in Godot is the one you are comfortable with. The biggest thing to understand is the limitations of the language you are using. Thanks for your input and watching! I appreciate the interaction.
@@hamsterbyte i think its unfair to not use the built-in bindings cause thats how you're supposed to use gdscript. That would show beginners that you dont need to bother with c# and gdscript is more than enough. It probably doesnt matter much which language you choose but gdscript is obsviouly more productive even if you're familiar with c#
GDScript is more beginner friendly, I agree with that. Thanks for watching.
@@hamsterbyte lmao nice edit
You completely missed the part about OOP and how C# has many more language features which GDScript doesn't have. You also missed the part about dev tooling for both languages.
From personal experience using both languages (first GDScript now switching to C#), you should not use GDScript for anything other than quick iteration and small stuff. It just doesn't work out as your project scales.
Also for performance, it generally doesn't really matter, and shouldn't be the final consideration when choosing a language. It's also unfair to not demonstrate the built-in methods in GDScript for sorting, etc. Realistically, you would be using them.
I agree with your second point. You are raising common questions that I've received from several people so I will pin a comment to try and elaborate on some answers.
im very curious on learning gdscript because its different than im used to C#, but the problem with gdscript its just a specific engine language, while c# i can use on other projects outside of godot.(unless i reach a point where im totally confident with c# and i wouldnt mind learning another one.)
@@tPlayerioT there's really not much to learn from GDScript that you wouldn't already know from C#. The syntax is different and certain operations require the use of purpose built API bindings to execute performantly.
But OOP is not a C# specific thing. You can apply OOP principles in GD script as well. You can take OOP concepts and apply them to gdscript easy. I use multiple oop concepts like Classes, inheritance etc. for my game and it's developed in gdscript. So he didn't miss any part with oop. Maybe read a bit more before spreading misinformation
The problem with relying on built-in methods is that you are limited to what those built in methods can do. As soon as you want to implement custom logic all of a sudden you're screwed with orders of magnitude worse performance. That's why you don't use built-in methods for speed tests.
C#的重要意义在于，极大的扩展了这个引擎的功能库！这个小工作室什么级别？微软什么级别？ 我们可以直接把C#代码移植到游戏中。你不用C# 相当于缺少了极大一部分功能！
notable enhancement involves the use of Just-In-Time (JIT) compilation, which translates GDScript to C++ behind the scenes. This technique aims to boost performance without requiring extensive changes to the existing codebase
Minor point: strictly typed languages do not require that you define the type of the variable, but the variable once typed cannot be changed. In C#, the var command can be used to reduce the complexity of a type name, but the variable is still strictly typed. For example:
var videoSettings = GetVideoSettings(); // This is an object
var fullScreen = videoSettings.FullScreen; // This is a boolean
var screenWidth = videoSettings.Screen.Width; // This is an integer
// ...
The code above works, and each variable is a different type, despite all of them being "typed" as a var. Personally, I hate the var command with a passion, but it does serve a purpose. If the videoSettings class was an inner class multiple levels down, the type name could be very annoying to type, especially without any form of Intellisense:
Globals.Settings.VideoSettings videoSettings = GetVideoSettings();
Yeah I only use var when I don't care about readability, which is pretty much only in prototyping things quickly that won't be seen by other devs. It would have been more correct to say staticly typed as the industry doesn't have an agreed upon definition for strongly/strictly typed. When you use var the type is set automatically by inference so you have still technically assigned a type when declaring the variable. What bothers me most about using the var keyword is when working with number types e.g. double, float, int, uint, etc.
var myNumber = 10; // This works, but is it unsigned or just a normal integer? Who knows?
Out of context this could be a tuna sandwich.
@@hamsterbyteit is a Int32 integer. Some time ago I too was didn't like var keyword, but now I don't care about types, because this is cognitive complexion that I don't want to burden me when I have another work to do. When I want to know type - I can check that with IDE tool. As I know in gdscript there are same keyword var: with semicolon - that works like var in C#: var := 32 - will guess type automaticaly. But I prefer that var work like this in first place by default.
@@WeslomPo It's personal preference. The var keyword makes code more difficult to read, especially when working on someone else's code.
@@hamsterbyte yep, I know, I also was thinking the same. But now - I think different.
Great video, just discovered your channel! I'm interested in starting to use C# at Godot, not because of performance but to benefit from the library ecosystem, but the 'plug-and-play factor' of GDScript weighs a lot because I work in a team of four people where I'm the only programmer. It's the same with custom builds for Android, the setup and maintenance process isn't friendly to non-programmers, and I have no interest in 'babysitting' other team members due to a technical choice made by myself. If the performance or architecture of our projects starts to scale in an unfeasible way, I'll think about it again.
Godot 4 does not currently support mobile builds with C# to my knowledge. I would very much like to see this change in the future. Thanks for watching!
I believe boxing we are using like "(float)delta" part is the root of the performance problem in c#.
Casting definitely has a performance cost associated with it so you are definitely not wrong there. Thanks for watching!
Can you benchmark these comparisons with .NET 8? It came with a lot of new performance improvements, one of them including dynamic PGO enabled by default now
How about dev time for prototyping? I am currently prototyping a procedural, large world in gdscript and I just love how fast I can run the project, tweak something, and run it again. Also, the fact that I only need one window and zero configuring of anything is great. Yes, in the end the heavy lifting will be done by c# or most likely cpp. So the final implementation will be in one of those two.
I'm pretty sure GDScript has hot reloading...so you don't actually have to run the project again; you can just modify and save the code while it is running. If you like GDScript then you should use it, but you should also learn how to make a loading screen if you plan to do any sort of proc gen with it.
@@hamsterbyte Depends on what you have changed. But yes it has that.
This excellent video just earned you a SUBSCRIBER.🙂
Very much appreciated! I'm glad you enjoyed it!
If u have to overload engine with heavy MATH functions, u just can install C++ extensions for that.
Of course, and C++ will perform slightly better than properly written C# code...the point of the video is to illustrate the difference between GDScript and C#. However, C++ is not something most people using Godot are going to be comfortable with. Most use GDScript because it is easy and beginner friendly. C# is in the middle for difficulty and nearly as performant as C++ if implemented correctly. Also, it's not really just about math as iteration is the main drawback of using GDScript. It struggles when iterating over collections and that is something that is prevalent in ALL code bases. It's impractical to implement C++/GDExtension for everything that requires some sort of iteration. At that point, you should just write the entire project in C++...
I use c in Godot for one important reason code strachoure
In C as long i use brackeys and ; im able to organize those in the way i want
In Gdscript on the hand you have to used each line in specific strachour for example
If have space before my line started in gd scrip i have error for some reason even if they line have 0 errors and i really hated that
Believed or not it's the main reason i use c# instend off gdscript
Hello, just to make sure I understand: the way you doubled the C# FPS at 4:37 is by running the code outside of the _icons objects themselves, where as previously the script ran on each _icons node individually?
I doubled the FPS by managing the logic as whole in a single script instead of having a script on each individual object. This approach is relatively common for optimizing code. Thanks for watching, great question!
I think that's what I meant by what I said. Thanks.@@hamsterbyte
i developed all of my engine in c, but i have included a binding with lua, so i can call functions from c in lua and program my game logic in a more friendly language, so i guess i have the better of both worlds
Congrats on writing your own engine! That's a monumental task. Do you share it publicly? I would be interested in having a look.
Nice! That's basically exactly what gdscript does. Technically, I guess you could write everything for Godot in C or C++, but gdscript is so much easier to just get something going.
at the end it doesnt matter which I wasnt expecting :)
For most game programming it really won't make a huge difference. There are certain things that are going to be much slower in GDScript like interacting with large datasets, procedural generation, etc. Anything that is computationally expensive. In which case you would want to go with C# or, if you have the knowledge, GDExtension and C++ or Rust. GDScript is more than adequate for most applications.
C# looks familiar, but it has its own eco system to learn. So, if I needed it to run faster via C#, I'd definitely need some time investment in learn the C# way of doing things. Also, if this forced me install the best I call Visual Studio is a good chunk of space and yet another tool to learn and buy into its project format. Some of this is just my personal preference. But, I didn't agree with you comparing custom implementations when GDscript already had a built-in that you'd use and I think that made for pointless comparisons on in those cases. But, you did come up with a surprise ending : )
GDScript does not have bindings for many common algo's, so in that case you would have to write the logic yourself. The only binding GDScript has that would qualify for comparison in the context of this video is Fisher-Yates shuffle. Thanks for watching!
why not just use visual code instead? its way less bloated than visual studio and generally much better to work with anyways. And also supports a ton of different extensions such as a full neovim intergration (which, I personally use as it speeds up my coding workflow by a huge margin and removes the frustration of having to deal with a mouse every 5 seconds
@@Faunarr I personally use Jetbrains Rider, but have well over a decade of experience with Visual Studio. I am no more qualified than a Google search to teach people how to navigate VS Code as I've little to no experience with it. Given that, I can't suggest that people use it as I would not be able to assist them competently with any issues they may be having. It's really just a matter of personal experience and preference, just as your preference favours VS Code. I always suggest that people use whichever tools and language make them the most efficient.
@@hamsterbyte it is personal preference. But there is nothing with suggestion a lighter alternative in regards to the comment.
If C# is only good for performance critical that don't operate though Godot API I rather go straight for C++ using GDNative instead of C# to squeeze performance when needed instead of just using a less slower language than GDScript
C# isn't 'less slower' and in most cases it will rival the performance of C++. C++ is slightly faster and won't be subjected to the marshalling costs when accessing the Godot API, so if you are comfortable using the lower level language and care about a few extra FPS that's definitely the way to go for you. There's no wrong language to use in Godot, it's really more about what you are comfortable with. Thanks for watching!
I think the real takeaway here is that there's areas that C sharp beats out GD script however there's also areas that C++ beats out both of them, and areas where GD script would be the preferable choice I think the beauty of this is that we have the option of working in three languages that are basically fully supported and one project having these different layers of construction will make project iteration between multiple programmers so much faster
@Red_Paper6495 I have never used GDNative, it was removed by the time I started using godot in favor of gd extension, I have also never used gd extenstion though I find it interesting. However I was referring to using source builds and modules where you have full control, also if u wanted to build a whole game that way you could, but it would be a annoying workflow, Is that what you mean by not being able to write a game in c++?
I prefer C#, but I use Godot with GDScript.
Something most ppl seem to ignore is that by using GDScript for your game you are making it easier to port it for consoles in the future.
Why does using GDScript make a game easier to port to console than C#? There are many games written in C# on consoles.
@@hamsterbyte Well, first reason is that GDScript has no GC, which makes things easier. Second reason is that most of Godot's users use GDScript, therefore most efforts will be put for porting GDScript games to console, not C#.
Proof of that is the free switch port that has been created: it doesn't support games using C# or GDExtension, only games using GDScript.
The issue I'm having is the tutorials for GDScript are all outdated. I have a tut that uses a KinematicBody2D which was removed in Godot 4.
I have a tutorial for a basic platformer controller that uses a CharacterBody2D; it's in C# though. I don't really do GDScript content, and unfortunately the way you do things in GDScript is often quite different than the way you do them in C# as the GDScript implementation would rely heavily on the use of bindings and a C# implementation would avoid bindings wherever possible.
@@hamsterbyte Thanks, but I'm looking for Monkey Island style movement script.
One thing that's underappreciated about GDScript is how fast it compiles
I can make a change to a script in a large project and press run, it's almost instant
That's because GDScript isn't a compiled language, it's interpreted. There is a C++ based interpreter through which all of the GDScript logic passes. Since you aren't changing the interpreter no compilation is necessary. That's why I chose to test iteration and calculation as these workloads are required for almost all custom logic and the interpreter cannot pass them directly to a C++ binding. That's where the real problems in GDScript arise.
@@hamsterbyte Thanks for the clarification, I'd assumed GDScript was JIT compiled, but looks like that's indeed not the case
Hopefully they add that in the future, especially for exported builds, I think it'll help bridging the performance gap a lot
@@oxdeadbeef no problem, when built GDScript instructions are compiled to byte code but those instructions still need to pass through the interpreter. JIT would help with that, or the immediate solution is to use a compiled language like C++ or C#
For me # just doesn't have the use case when I can just use the API binding with any performance oriented language (C, C++, Rust, etc.).
The best language to use in Godot is the one you are the most comfortable with, and if that is a lower level language for you, I fully endorse your decision to take that route. Thanks for watching!
Since I keep hearing C# is not as developed in Godot, I'm curious to know if you've hit any walls or experienced any limitations?
C# is fully supported in Godot. See my other reply. Thanks for watching!
I just gave up Godot, at least for now, because my biggest gripe with it in the past years and current is the focus on GDScript. It feels like reinventing the wheel over and over again, there were good scripting languages out there already for use like Lua, Python itself, C#, etc, but they insisted in GDScript. I tried using with C# but learning material, community posts, workflow with IDEs is just really clunky rn. I love Godot, and want to use it, but it's been 10 years and still very clunky. I'll support it and donate to it as I've have but I'm just annoyed that I really don't want to use Unity and Godot still not there.
I have not experienced any unique issues in my C# development with Godot. Except when trying to serialize data to JSON, or when creating generic classes. Avoid those two things and everything else should work smoothly. Also, I have several tutorials for C#/Godot on my channel. Happy coding!
If I understand, the marshalling cost comes from having the same script on every node, and therefore one _Process method call on each one, versus a single manager and single _Process?
Or is there further to understand on how to reduce marshalling costs?
Simply put, in the context of using C# with Godot, marshalling occurs whenever you access the Godot API. Using a manager script doesn't eliminate the marshalling costs entirely, it simply reduces the overhead required to run the logic as only a single script needs to access the API instead of hundreds or thousands of individual scripts. Managing your code this way is a near universal way to increase performance regardless of the engine, platform, or language that you are using. It's a common practice throughout the software industry. The best C# performance in Godot will come from writing your logic with a more data oriented approach and batching the calls to the API with a manager script. Keep in mind that this isn't necessary most of the time as the marshalling costs, though expensive, are not something that are going to outright tank your performance. Where it becomes a problem is when you have a lot of complex logic trying to access the API multiple times. The easiest way to avoid marshalling is to simply eliminate usage of the Godot API where it isn't strictly required. Personally, when I write code for Godot in C# I try to limit my access to the API to assigning and accessing values, and I minimize the access to values by caching the information gathered from the API in variables. Hope that helps clear things up! Thanks for watching and good luck!
Basically,
GDScript is for beginners or for those who need fast prototyping,
while C# is for more advanced developers who focus on performance in their games.
GDScript can be performant if used correctly. The biggest issue most experienced developers would have is the lack of control in the logic. Trying to fully control GDScript in the same way you would a compiled language will result in loss of performance, which could be substantial depending on the use case.
If GDScript moves certain feature to lower level languages.
Then would it be possible to write in just that lower level language?
Same to how you can write C++ in Unreal instead of blueprints. The performance difference here seems to be rather large.
And for people looking to grow their next projects, this would be a great leap from easy to harder but with great performance benefits.
While Godot offers interaction through GDNative with C++, and even community-supported implementations for Rust and Go, C# provides a compelling alternative due to its balance of performance and developer friendliness.
C#'s syntax shares similarities with JavaScript, making it a more approachable option for a wider range of programmers compared to C++ or Rust. Additionally, recent advancements in C# compilation, such as Native AOT, allow it to achieve performance levels comparable to lower-level languages.
It's important to consider the technical merits of a language beyond historical biases. While C# may have faced negativity in the past due to its association with Microsoft, its strengths in readability, maintainability, and performance make it an excellent choice. Furthermore, the job market for C# developers is significantly larger compared to GDScript developers. However, for novice programmers or hobbyists, GDScript is a well-suited option due to its approachable nature.
That being said there are a few caveats:
Web Export Limitation: Currently, Godot does not support exporting C# projects directly to the web. This functionality is under active development with the release of .NET 8, but it's not yet available.
Marshalling for Godot Consumption: When using C# with Godot, marshalling may be required to bridge the communication gap between the languages. This process can impact performance if not carefully managed. It's crucial to identify which parts of your C# code necessitate marshalling, scene tree access is the biggest offender here. Techniques exist to minimize the performance impact of marshalling. While marshalling adds some overhead, most well-written C# operations will still outperform their GDScript counterparts.
I think the Tail's Quest game proves that GDScript is enough for the indie dev
Do you have a link to this game? I would be interested in seeing it, always like to see games made in Godot.
@@hamsterbyte Sorry, the game is called "TailQuest": ruclips.net/video/KfZ6gmuLVuY/видео.html&ab_channel=Kivano
@@hamsterbyte It was made in godot 3.x
GD只是脚本 而C# 是功能强大的程序库！！！
Really cool animation! How are you doing that???
You'll have to be more specific, there's a lot of animation in my videos haha
@@hamsterbyte lol sorry. I meant animating the characters. Is that manual or are you using some type motion tracking
@@TheSearchForAwesome Manually, with Adobe Character Animator
Hello. Please tell me, can I use two languages at once in one engine project: GDScript and C#?
Absolutely, the Godot version which supports C# also supports GDScript. I actually had to use both languages for the custom tooling in my upcoming tutorial video.
Thank you!
I want to do c# cause I’m switching from unity but there’s no tutorials to learn how to use it in godot
I have several on my channel, but some are quite advanced.
Did you run the C# code within Godot or separately? Because GDScript is going to have the added burden of having the Godot engine bundled along with it. Also, GDScript runs faster once the game is exported as it is compiled to bytecode (still interpreted by the engine, though). Unlike what you said, GDScipt is not weakly or losely typed. That is when the language will coerce types automatically, like how you can add a number and a string together in JS. GDScript is, however, dynamically typed which has its benefits and its weaknesses. It can be statically typed but that's missing many features like generic types, but for most cases static typing works fine in GDScript, and you can use dynamic typing in the few cases it doesn't.
Yeah, I tend to use strong/weak to define languages where the type is explicitly defined vs implicitly defined and you are right that this is not technically correct. There's not really an agreed upon definition for these terms and to avoid confusion in the future I will use static/dynamic instead. Good catch.
As far as where the code was executed - all the code was executed from within Godot. Compiling the code will make a difference in the execution time, but I don't think it will impact the performance enough to invalidate the results. The main goal was to illustrate some of the strengths and weaknesses of these two languages to give people a better idea of how and when to use them; moreover, I wanted to illustrate that C# is definitely viable in Godot and is actually better for many things. Thanks for the insightful comment. Honestly, one of the first non-troll critiques I've seen so that is much appreciated. You made some good points. Have a great day!
If C# has such bottlenecks when interacting with Godot API, wouldn't Unity with first-class C# be the better choice (isn't C# compiled to C++ there)?
Well, unless you develop on Linux and want to tinker with VR, then there isn't really any choice. Unity Editor doesn't support VR on Linux, but Godot does. The question is, with these massive marshaling costs, can you actually use C# for VR which is much more performance sensitive (frame timing consistency and high fps)?
I'm not sure Godot is the correct engine to choose if you are planning on developing a VR game; it's certainly possible but I think Unity is better suited to that because it is a more feature rich engine and has been in the space a lot longer. I don't think that Unity compiles C# down to C++ or some lower level either. My understanding is that Unity's C# support is still through Mono, which is great for sure. If you want peak performance in Unity the new ECS/Jobs/Burst Compile does get compiled down into low level code and is absolutely amazing. Don't be deterred from making games in Godot with C# though, it's great when it comes to that, even when accounting for the marshalling costs. I REALLY stressed my system and the tests showed min 80+ FPS with 8192 active objects performing operations through the API. The marshalling costs are relatively high but Godot is very optimized and lightweight. A typical project I make in Godot runs at over 1000 FPS with C#; usually 3000 FPS. The marshalling costs are definitely a bottleneck, but the way you get around it is by simply not using the API for things that can be done outside of it.
What version of Godot was this comparison performed?
Version 4.0, thanks for watching!
Nice and interesting video. Some feedback though, I personally found the background music quite annoying and I didn't exactly like the animated beginning either... Your visualization and content itself is excellent though!
Noted! I can tone down the background music, but most people find it a little dry without it, and the animated intro has brought my retention numbers up substantially according to the analytics, so I'm probably going to stick with that format. In the future I will add chapters for people who wish to skip it. Thanks for the feedback and interaction, much appreciated!
I honestly don't get the "easier to learn" thingie. I started from scratch as a self taught hobbyist. Python was such a mess, so many things you have to keep track of yourself because the language is simply not designed to fail and tell you when you do something that is only midly stupid.
C# was a breeze. When you do something wrong it complains right away and then you don't have to spend hours trying to figure out if it's the logic you programmed that doesn't work, or if you made a silly distraction mistake.
C# is harder than GDScript because it forces you away from using built-in bindings that can make more complex logic trivial. It isn't a matter of syntax, it's a matter of the amount of prerequisite knowledge you need to acquire before you can work effectively. Most gdscript bindings have been made available for use in C# but due to marshalling costs they should be avoided wherever possible. Thanks for watching!
A pretty good video about the features of both languages for Godot . . . and here I am, learning C++ as a novice and without knowing if it's even possible to use it for scripting in Godot.
Help :)
You can use GD Extension to run C/C++ code in Godot. This is not a beginner friendly approach in my opinion because low level languages like that are quite a bit more difficult to learn than C# or GDScript. You could use a hybrid approach and use GD Script for general workloads and C# or C/C++ for more intensive workloads like pathfinding or procedural generation algorithms, but it really is just easier to do everything in C# and do your best to minimize the marshalling costs by avoiding access to the Godot API wherever possible; you'll find that this is actually quite easy in most situations. As long as you use good practices, C# will be more than performant enough for any workload you want to write. If you are a novice this is the approach I would recommend. It saves you from having to learn the more difficult lower level language and from having to use a hybrid of two languages. By all means, learn C/C++. The fundamentals you will learn from them are priceless and will absolutely translate to other industry standard languages. Thanks for watching!
So between gdscript and c#, what should I learn first? I know the very bare basics of c# but I know more python, and I heard gdscript is very similar to python
Just gonna make 2D pixelated games (as a hobby), and I wanna kinda start fast, so what do u recommend? Thx
GDScript is faster to learn but useless outside of Godot. If you want to make a web build you have to use GDScript or a different engine. GDScript is similar to Python, just make sure to read the docs and use whatever bindings they have available
obligatory RUclipsr mascot is obligatory
I thought so lol
*[CinemaSins ding sound]*
Would it be C or C++ it would even more faster
Of course, because those are low level languages. Rust and custom assembly code would also be faster, but that's not really what was tested here. It's a high level language comparison of the two most popular scripting languages that are used in Godot. In situations where performance is absolutely critical and you can't optimize your high level code enough to get the performance you need, you would use a lower level language for that portion of your logic.
I like your video but is funny not consider the low level implementation of godot because in practice we will use it. you should test the tree options.
Considering the low level implementation would invalidate these tests which are targeted at custom logic. If you are using GDScript you must use bindings to maintain performance and I would encourage you to do so. If you need custom logic that doesn't exist in a predefined binding, GDScript has to find a way to force that logic through the interpreter which will lead to substantial performance degradation. Consider this, I need to sort an array of objects by a specific variable and that sorting must be stable; GDScript has no built in binding for this. GDScript has a sort function, but it isn't stable, so you would need to write custom logic. That custom logic will be far less performant if written in GDScript. You then have two options, use C# or C++. These tests were chosen specifically because their logic cannot be passed directly to a C++ binding that does all of the work in the back end. It's not a test of a low level language vs a high level language. It's a test of how efficiently these two high level languages can execute functionally identical workloads. You should use whichever language you are most comfortable with and the most important thing is understanding the limitations of the language and working within them. GDScript has severe limitations when it comes to custom logic because of the interpreter. C# has limitations when it comes to accessing the Godot API because of marshalling costs. Thanks for watching!
I am currently using C#. Is there a way to get better performance when using marshalling? Thanks
Avoid accessing the Godot API wherever possible. Sometimes that means coding logic that is already built into the engine in native C# - I know, it's not ideal. You can check if a built in class or method will be affected by marshalling by checking its definition. If the definition contains bindings, it will be affected by marshalling. Many of the built in data types are already ported into native C#, i.e. Vector2, Vector2I etc., but anything that interacts with the scene tree is likely going to be affected by marshalling. Marshalling should not cause serious issues in normal use, these tests were written to stress the system with 8192 operations interacting with the scene tree every frame. If you are having specific performance issues, you can check the profiler and try to figure out what the root cause is.
@@hamsterbyte Thank you for your thorough guidance.
I feel like this is all a setup and not an actual test 🤨
Also, remember, not everyone is disposed to learn C#
Edit: I thought this guy made this video as a setup to favor C#, my bad, it wasn't
Definitely not a setup. The tests were specifically designed to explore some of the most common types of game dev workloads without the use of predefined bindings. If you use the built in bindings your GDScript performance will be markedly better than the metrics in this video, but there isn't always a binding for the specific logic you need - that's when you need to make a decision about which language to use and it really depends on how critical performance is for that logic.
@@hamsterbyte I'm currently using GDScript cuz i'm new, also, i though it was fake because you showed the timers but not the test, that's why i got suspicious about it
@@RayOfSunlight984 the source code is in the video. That means the results can be peer reviewed and replicated. If I were faking it I would not have shown the source code. 😅
@@hamsterbyte Oh, i haven't saw that, thanks for clarifying.
in that case, dont we should to using the Godot.Colections API to C# instead of base class library? Maybe a bit better idk
Anyway, great video
Any access made from C# to the Godot API will incur marshalling costs that are going to hurt your performance, not just when applying transformations, but across the board. GDScript does have certain functions built in to mimic some of these workloads such as sort() and shuffle(), and you should use that functionality if you want to get the best performance from GDScript. However, as I stated in the video using that functionality removes the logic from GDScript and transfers all of that execution to a lower level. This is great for performance, but not great for control because you didn't write the logic. It's really a race to see how quickly your code gets to machine language. Your CPU doesn't know GDScript or C#, so all of the logic you write in either of these languages needs to be compiled or interpreted down to machine language before it can be executed. All that being said, it really doesn't matter which language you choose, it's more important that you understand the limitations of these languages in the context of Godot and write your code to accommodate that. I would definitely be interested in seeing other ways that these same sort of workloads can be written in GDScript that would increase their performance. I'm happy to take a look at what you find and test anything that holds all of the execution inside GDScript, anything that moves the execution is going to be more performant and that would invalidate the test. Thanks for watching!
For raw performance, GDExtension is the way to go. C# can't beat Rust or C. As for working with the Godot API, GDScript is for me the obvious choice. It's cleaner, simpler and faster than C#.
My conclusion is that C# is not the best choice for Godot. Not for me, at least, since I'm not particularly fond of C# and I don't thrive to use it.
C# can't beat rust or C, but it is relatively competitive for a high level language. GDScript is excellent for working with the Godot API, but falls short in other types of workload. This video was not a comparison of a low level language vs a high level language, just some information about how and when you may want to use the high level languages Godot supports. Everyone knows that a low level language is faster, but let's say someone is already a pretty experienced Unity dev and wondering if their knowledge would carry over to Godot; the answer is yes, and it will be plenty performant 99.9% of the time.
As far as GDScript looking cleaner, that's a matter of opinion. I personally don't like weakly typed languages or syntax that is dictated by white space at the beginning of a line, but that's just my opinion. Thanks for the comment and thanks for watching!
@@hamsterbyte You raise fair points. I wasn't thinking about GDScript being more performant on pure computation. About that, C# is definitely way faster. The strong point of GDScript is more about calling built-in functions than really doing computation itself. A bit like Python is really performant when it uses mostly Pandas to do the calculation, but it is slow when it iterates over an array of values.
About C# vs Rust, honestly, I only know about a benchmark showing that Rust was significantly faster and lower in memory than C#, which doesn't surprise me since Rust is running on metal. But I agree that it really depends on the usage. It's true that Unity developers will appreciate the support of C# in Godot, but since not all Godot developers are former Unity developers, this argument doesn't appeal to me. The right tool for the right task, that's more my motto.
And about being cleaner, yeah, that was a bit pretentious of me to put an opinion as a fact. I used to dislike Python's formatting too, but I got past that, and I find now the C curl formatting too cryptic. I still write with it, especially in typescript and java, but I prefer now the indented formatting. About weak typing, you should really try the new 4.x feature for typing variables and methods. It's still at its infancy, and it can even lead to loss of performance, but strong typing is not in GDScript too. And me too, I appreciate that a lot.
I am full Stack with c#
I'm going to say one word. Interfaces. C# has interfaces. GDScript does not. Granted you don't really *need* interfaces but it saves a lot of time and work. How would you do something like, "The player is a human but also a biped, an omnivore, can wear clothes and use tools so the player needs to be part of the Human class. Biped class, Omnivore class, Clothes wearer class and Tool user class"? Yeah, good luck doing that in GDScript (for now). It's not always just about performance. Sometimes it's about functionality and C# beats GDScript by a mile on that front.
C# is years ahead of GDScript and has a lot of useful features that GDScript does not. Interfaces are just one example. There are many other techniques that I use in my normal workflow which would be impossible in GDScript as well. The shortcomings of GDScript make it quite difficult to maintain DRY principles. Don't get me wrong, I'm not a fan of modern clean code practices as they often lead to performance degradation and that has no place in game development, but DRY is something you should always try and stick to wherever possible. For example, I use a lot of generic classes and methods so that I can reuse certain portions of code for things that are similar but not the same. This is particularly annoying because even in C#, Godot does not fully support generic classes. github.com/godotengine/godot/issues/79519
All of the comment replies seem very angry. I am a C# unity dev but even I would have to say that GDscript just dog walks c# . Any language does really. C# just has too many arbitrary rules and a fairly steep learning curve. If I was starting over, it would be with Godot and GSscript
I understand why most people would prefer to use GDScript, but the rules in C# are not arbitrary. There are rules you must follow in any programming language, including GDScript. The major shortcoming of GDScript for me is the lack of control you have over the logic and being forced to use built in functions to maintain performance. Because the language relies so heavily on these built in functions to maintain performance, it means that certain operations cannot be done in GDScript alone; this is not a problem that C# suffers from.
What are you referring to? I honestly have no idea what people mean when they say c# is hard to learn.
@@cptant7610 everyone has blind spots and different difficulties in learning different things. What may be easy for you may be a daunting task for someone else. Personally, I prefer C# syntax as I find it much more readable. That being said, someone who comes from a web dev background may prefer GDScript as the syntax is closer to Python/TypeScript. Point is we all learn differently so it's easy to see why one may prefer either language. Thanks for watching!
@@hamsterbyte But C# being "harder" is mentioned so often as a con of the language. I just simply have no idea why it would be inherently harder.
@@cptant7610
I don't know how proficient you are with C# and GDScript and I won't make assumptions about that, but would you not agree that an interpreted language that emphasizes and relies on the use of low level bindings would be easier to learn than a language where those bindings, though present, could lead to serious performance issues and consequently require to you write functionally identical logic yourself from scratch? In the context of Godot, C# just simply is the more difficult language for this reason. The difference in syntax between the two languages is so trivial that it's irrelevant.
The main thing that still keeps me from using C# is the fact that I can use GDScript right in Godot editor. Sure I can use C# as well but I dont get autocompletion like if I use GDScript. I just very much prefer the workflow of writing the code in the Godot itself instead of using external editor thats why i still use GDScript.
I can understand that; it's a nice QoL feature. Do you have any experience in other available industry standard engines like Unity or Unreal? Those both require an external IDE for scripting, but also support an internal system for visual scripting; Bolt and Blueprints, respectively.
@@hamsterbyte No, I do not. Godot is my first game engine.
@@ariton2990 That makes sense. Godot is going to be good enough for you no matter what language you use. If you feel like you want to learn how to work with C# in Godot I have several useful lessons on my channel. Thanks for watching!
Cuz we do lots of bubble sorts in game programming.
YOU may not personally use bubble sort, but you will most definitely use an iterative workload at some point. I could have used a search algorithm instead? Or perhaps a flood fill? What if I used A* pathfinding? Marching squares/cubes? The bubble sort test was selected to illustrate the performance of an iterative workload, which it does very well. It doesn't matter how that iteration happens and bubble sort was chosen specifically because it is inefficient. The pinned comment further elaborates on some common question I have received if you want more clarification.
@@hamsterbyte None of those are likely ever to be implemented in C# or GDScript.
Agree to disagree. If you truly believe that, there is nothing I can say that you will consider valid. Have a great day!
@@Christobanistanyou’ve got no idea what you’re talking about
@@nikefootbagSeriously? If I ever see someone doing an algorithm where performance is critical in GDScript, I'll LOL.
Thus, one is for beginners or small-time projects who/that don't have to care yet about maximizing performance.
While the other is for the more experienced who can maximize (or efficiently use) the language to achieve optimal results.
However, when it comes down to it, it is about preference as each outperforms the other in different scenarios.
However, as a personal opinion, I dont think massive games are made in Godot and so Id prefer to use Gdscript as performance from transforms seems more important to me. However, i dont have time to learn a new language and will thus stick to good ol' C sharp.
Greag video man. Really short and straight to the point with Fakts
I think Godot is going to have more larger projects associated with it in the future; it really is a great engine. As far as transform performance goes, you can still apply transformations in C#, just minimize your calls to the API for maximum efficiency. I have had no problems with performance when doing things this way, and even so...when I tested applying transformations I used 8192 nodes and still maintained over 80 FPS when used without a manager. Like you say, it doesn't matter which one you use, it only matters that you use what you are most comfortable with and write your code according to the limitations in that language. Thanks for watching!
@@hamsterbyte very good video by the way, extremely well put together
@@alfierichards2340 thanks for watching! I'm glad you enjoyed it, have a great day
no good doc , no tuto in c# is hard for beginer
There is a mountain of C# tutorials on RUclips, though not all written specifically for Godot, the information should still carry over. The difference would be the API, which you would have to learn for GDScript anyway. Also, the Godot API documentation is pretty well fleshed out as far as C# goes. C# is definitely more difficult than GDScript though, especially in the context of Godot.
this is exactly what i searched for, thanks
No problem!
Why you saying its unfair to use the build in sorting function in GD SCript, its the one you will use for your game? Not bubble sort..
Because bubble sort is easy and stable. The test isn't about whether or not C++ is faster than C#. It's about GDScript vs. C# and it tests the speed of the operations when they are manually implemented. Using a built- in function that binds to the C++ backend isn't the same as comparing GDScript performance to C# performance. Congruency is paramount in performance tests, and congruency is not possible if you use GDScript bindings. The whole test is invalid. That being said I could have used quick sort and C# would still be faster than a hand coded GDScript version...
@@hamsterbyte it just makes the comparisons useless, because you dont keep the use case of gdscript in mind.
@@Snapper-gaming Is the built in sorting function in GDScript 100% congruent with the built in sorting function in C#?
That means the logic is functionally identical and contains the same number of operations/iterations.
Imagine you have two cars in a race. They both start at the same place but one car takes a winding road to the finish and the other takes a straight road. Is the car that arrives first the faster car?
Well, maybe. It depends. Was it the car on the longer route? If it was, then yes. Was it the other car? Then maybe, you can't say for certain. The test is not valid because the conditions are not congruent. Garbage in, garbage out.
That's why congruency is so important in performance tests.
Do you think I chose bubble sort because it's fast? I chose bubble sort because it's a worst case scenario and illustrates the relative performance of the two languages when given an iterative workload.
Before you make a counterargument to a series of empirical tests like this you should first understand the original argument. The source code is on screen so anyone can replicate these tests and I encourage you to do so.
The data presented in this video is not my opinion, it's factual evidence. Your opinion that the tests are unfair is irrelevant, baseless, and provides no counter argument to the evidence that was presented.
The solution to the issues this data uncovers is not as simple as saying, "just use the bindings" or "you'd never use bubble sort in your game".
The array shuffle could be faster for C#. Based on the case I will say. Same for bobble sort. And the matrix one
All of those things were definitely faster in C#. Thanks for watching!
@@hamsterbyte I am just saying there are ways to make it faster. Such as replacing the array with a Span as read and write access is faster and also uses no memory. Though Span cannot always be used but where it can you often should
@@patfre @patfre I agree with your assessment, but am presently unaware of the existence of a Span equivalent in GDScript. Given the logic must remain as close as possible to maintain congruency in the tests, using a span would invalidate the data. I had to use a jagged array to test the matrix multiplication as GDScript doesn't support multidimensional arrays, and even that was kind of a stretch to say the logic was congruent since I used a multidimensional array in the C# test. Thanks for the input though, you are right that span is most often more performant than an array albeit with more limits on usability.
Godot 4 is pointless it only vulkan supporting!?
No, they have what they call a compatibility renderer for those who are targeting lower end hardware. Next to the build button as well as in the project settings there are options for setting which renderer to use; Forward+ is going to be Vulkan, selecting mobile or compatibility will give you a renderer targeted towards lower end hardware. There is no support for DX11/12, but Vulkan is more performant, as per testing in several popular AAA titles that support both, and widely supported anyway so I don't see this as an issue.
iam talking about mobile here@@hamsterbyte
specific android
Vulkan is the Forward+ renderer. The other two renderers supported by Godot are not Vulkan.