For more gamedev videos, subscribe to GDQuest: / gdquest Here, I answer your quick questions about Godot and game development in simple videos. If you have a question that we can answer in 5 minutes max, ask away!
Note that you can use both GDScript and C# in the same project, and they are interoperable. So you can absolutely code some systems in C#, some in GDScript. Though of course, this is something we can't recommend to beginners as you need to deal with two languages, but it might be interesting to professionals. One consideration I did not include in the video is performance because beginners, whom I think is the main target for this question, can have misconceptions about performance. C# can be quite a bit faster than GDScript code, but it depends on the context. If most of your code calls functions built into Godot, the difference is very limited because most of the code you run comes from the Godot engine. The difference gets big for 100% custom systems that you code from scratch in your game. Godot provides many features out of the box so many games never need such custom systems. We're talking about things built from scratch, especially things where you use many loops like procedural content generation algorithms. In those cases, you may need a language faster than GDScript, and you can use C#, or a lower-level option like C++. At GDQuest, we chose to use GDScript exclusively for gameplay code and C++ if we need a lot more performance. That's because we can directly reference the engine's source code and tweak it. We also generally code the system once in C++, recompile the engine, and then we keep the very fast iteration times in production with GDScript. But this isn't an option for everyone: you need to know C++, and while C# is about as feature-full, the learning resources for C++ are unfortunately often less accessible than for C#. So if you find GDScript too slow for your game, but you don't want to use two different languages, C# is a convenient option. I would also recommend it in this specific case. Just don't forget the tradeoffs: build and iteration times will become slower than with GDScript.
If a person begins development with the standard version of Godot, using GDScript, and 3 years later they realize some of their systems may benefit from being written in C#, is it possible to simply load the same project within the Mono version? Will migrating like this break anything or is a painless transition? I can only assume that it's impossible to go back to the standard version once you've implemented anything with C#.
@@kovitikus Yes absolutely, you can open a project in the Mono edition of Godot anytime. And vice-versa, if your project created in the Godot mono edition has no C#, it should run no problem in Godot standard. The Mono version is just a little bit heavier because it adds C# support, which is why it exists as a separate download.
The main people who ask this question may be beginners *to Godot*, but they are not necessarily beginners to game development or programming. That's even more true now that so many are switching from Unity (and C#) to Godot. Switching to Godot necessarily entails decisions like what language to use, and performance is a very important consideration, depending on what kinds of applications you'll be developing. Another consideration that I didn't hear mentioned in this video is portability to target platforms. If I'm going to spend a lot of time developing an app, but then it can't run on the web platform because I wrote it in C#, it's important to know that in advance.
I personally started using c# with godot because it gives you a more "standard" development experience. It makes my workflow more about using godot as a tool and less about endlessly learning the engine. It allows you to carry over your workflow from other engines easily, and has much more to offer (static variables, classes, structs etc...)
@@surplusking2425 and static variables XD, but it doesnt have strict static typing, interfaces, no possibility to declare visibility of variables, functions etc, and its just significantly slower on certain performance intensive operations, but when it comes to the usual "indie games" i think gdscript does fine for the most part
@@s1ndrome117but it doesn't have static typing due to the nature of the dynamic language. Some dev are coming from static-typing world and preferred to have a language that really enforce those rules.
I've been teaching Game Design to high school students for 2 years. The previous teacher used Unity so I followed in their footsteps. I thought, well it's an industry standard tool, C# is more known etc, but in the end, most of my students are not actually going to work in the industry. I'm really thinking of using Godot and your tutorials next school year. Unity is such a resource hog and runs slow on our computers. Having GD Script more tightly integrated into the engine is a HUGE welcome too. I think what I most need to do with my students is to expose them to the ideas of game development and teach them how to make prototypes, and then if they go on to college and study it more, they could choose to learn Unity et al. In the end, my class is an elective, and I do get students who have no interest in writing code, and the hurdles Unity puts in front of us really breaks some of those kids, then they check out. I think Godot would work better and keep more students engaged and help them be more successful on their projects.
That sounds great! We also offer a free app to get started with GDScript, and we're building a curriculum and tech to help teachers and schools (we're looking into ways to enhance the Godot web edition for schools, among other things). If you're interested, I'd love to hear about your needs. You can reach me via email here: www.youtube.com/@GDQuestQA/about Or via Twitter: twitter.com/NathanGDQuest (my direct messages are open)
@@teddycat1212 Terribly presumptive for a teacher. Worrying, even. When I was in high school, our teacher taught us game development using Adobe Director because he also probably reasoned "none of us will work in the industry anyway". You will probably google Adobe Director and find out literally no one used it, even people at Adobe apparently. Two of us in that class went on to become professional game developers that use Unity, because, as this high school teacher said, it is an industry standard with countless job opportunities.
@@skeletr It's high school - it's a time for kids to gauge interest in various topics and choose what to pursue. If they spend 10-20% of their class time waiting for Unity on slow hardware, they're wasting what little time they get to find what they enjoy. If Godot saves them that time, they get to spend more time learning to code and making things, and therefore more time to determine if this is something they actually enjoy or not. Everything they'd learn from a high school class (variables, arrays, functions, debugging, development patterns, etc) will still be useful if they choose to continue game development in college or on their own, regardless of whether that college uses Unity or Unreal. As for whether or not it's realistic to believe not all high school students would continue to pursue game development: The average game development job pays less than software development jobs in more "boring" industries, often has far more demanding hours, and only around 5% of all programming jobs are in the games industry. I imagine most of them would end up elsewhere at some point in their careers, and stick to game development in their free time as a hobby.
For me, we use GDScript for prototyping, so that the testing team and the gameplay programming team could have quick fixes and improvements to the game. However, we use C# for production code, and we always use C# for everything that is related to networking. Type hinting is a welcome addition to GDScript, but for C# is a primary function. This way most bugs could be eliminated even without testing.
GDScript doesn't just have type hints. It's not like Python: the language is gradually typed. In Godot 3, the type checker lacks some features, but thankfully in Godot 4, you can type collections, e.g., Array[Vector2] or Dictionary[Vector2, Node2D].
I would expand this to say that the C# knowledge would transfer better to any programming/technical field, not just game development. C# is a general-purpose language used widely in industry, while GDScript is obviously exclusive to Godot. While it is obviously influenced heavily by Python, the generic "programming experience" learned from C# is more applicable to other languages, whereas Python (GDScript) has a very unique syntax and way of doing things that can only really be applied within that language, and doesn't translate well into other languages. If one already knows one language and not the other, then by all means I would recommend using the one you are familiar with, but if choosing to learn one for the sake game development and/or interest in programming, C# is indeed the far wiser option.
For a video titled "Should I use GDScript or C# ?", I expected some arguments for both sides (and not only GDScript) apart from "use C# if you're already familiar with it". Informative, but I'm a little disappointed
The thing is, there aren't so many arguments in favor of C# for the people whom this video is for, to me (people who can't decide themselves). There's one C# language feature in particular that can be really nice, interfaces, as it gives you quite a lot of flexibility in how you can structure your code. There's one argument that C# developers will give you that's the ecosystem, the fact you have big code libraries available, but it's more that if you're a C# developer, you might be used to working with those libraries. Just like a Python developer might be used to relying on Python libraries. Godot provides lots of things built-in so you rarely need said libraries. So yeah I don´t have too many arguments that don't have an immediate counter-argument. The big one is likely performance if you need it, and that's covered in the pinned comment because there again, I think it's a bit beyond the target audience for this question.
@@GDQuestQA As a person who uses C# myself for godot I would say my main argument for C# is actually reflection. It can make your life so much easier and coding so much more plesant. For example: * Easy to do stuff like adding two of the same objects together (eg. player stats / buffs), if you add new fields to the class no need to update your adding code. If you need flexibility you can use annotations to for example specify that something should be multiplied instead of added. * Want to create a list of all items or something in your game. Just inherit them all from the same base class then use reflection to resolve at runtime. No need to maintain a list. * I worked on one project that allowed replication of member variables in godot over the network simply by adding a single annotation to any member in a class. You could even replicate entire custom classes with a single annotation (this is open source MDFramework on github). * Great for making tools, I made a C# data object editor that relies on code annotations to create an editor for my game data. If I want to bind the value of a json string to a C# enum I just add a single annotation to my code and I constrain my editor to the value of that enum. Or I can constrain it to the output value of a static method with another annotation. (Also open source, on my github same user name as youtube) * For one of my projects where I had huge data classes of level data where I wanted to make small changes between levels I expanded on this idea by having my editor use reflection to get a list of all properties in my LevelInput class, then you could simply override any value in the editor. If you changed the LevelInput class and compiled the program the editor auto detected this and would rebuild this list for you automatically. No need to go maintain the data tool on changes. These are just the five first examples that pop into my head regarding reflection, there are actually so many more uses for it. But in short it saves you the trouble of mainting things (tools, lists of stuff, methods for combining, etc..) while you are developing. Also reflection is by nature easily reusable. And before anyone mentions it, yes reflection can be slow. But during game startup it is fine, caching can make it alright for occasional use and in the worst case you can replace your reflection code with explicit code before release once there are not so many changes anymore. During development it's fine to trade the speed for convenience.
@@GDQuestQA Of course you can use duck typing instead of interfaces in GDScript, but then you lose the benefits of static typing. I think you made the right choice given the target audience here. Personally I think C# vs GDScript with Godot is all about trade-offs and what gives you the best experience as a developer. I switched to C# for a while and then switched back, and I have to say my workflow is much faster with GDScript and I haven't noticed any meaningful performance difference (though this does vary depending on the nature of the game)
@@GDQuestQAthere is a ton useful stuff in c#. Also interfaces should not be dismissed as a nice to have. On large projects things like interfaces are massively important to structuring projects. Also stuff like reflection, linq etc. It is good practice anyway to learn a universal programming language than one that just is specific to the engine. I opens much more doors for you.
The tools feature is working well on C#. But you need to press on "build" button after the changes. Best advantage of C# for me, it works faster than GDScript. But of course, GDScript makes you feel more integrated to the engine.
The speed difference, though it got smaller with GDScript 2, is still a difference at an order of a magnitude. You can still use GDScript, if you prefer it, for parts that don't need the performance, but you should always use C# or GDNative for performance critical parts.
Most notably, C# got updated to .NET 6 and C# 10. As with the rest of Godot, the devs took the opportunity to clean up the C# API/bindings and to improve performance between Godot and C#, it seems.
C# is not technically compiled but hybrid, still faster than GDscript but it doesn't really make a difference of you make a 2d game or a light 3d one as modern devices can run thel both smoothly and almost effortless.
One thing that confuses me is when 70% of tutorials use simple GDScript, then when I click on the other 30% of tutorials I see scripts including void and < and > and I don't know why some people use one style over the other. It's made learning GDScript confusing for me tbh. It was easier learning C# for Unity.
I'd prefer c#, since it just feels more robust. Whenever i write c#, i have a programmer mindset, thinking about writing good code, hiding information etc., With gdscript, my brain neglects all of that because it doesnt have a way to mark stuff as public or private, other than relying on conventions. Its also annoying that when you connect signals to a script, you have to manually type out the parameters of the reciever method, its really tedious compared to gdscript.
As a person who has learned almost full C#, I'll be using C# more like n Godot because I'm comfortable with it as I also learned unity. But I'll use GdScript Too
There are countless of c# tutorials/discussions/solutions online. GDScript sounds awesome but, as someone who does native mobile, web and desktop applications l, etc, I just cant slow down/pause on C#. Hopefully it improves in the future, I'm just gonna focus on trying to get more into godot.
I think performance isn't mentioned here, because unless you're doing some very expansive iterative logic every frame I don't think you'll see the performance benefit of C# that much. Note that this channel puts a big focus on beginners, and for people who are just starting out, the simpler syntax and better integration of GDScript into the Godot editor is probably a bigger benefit than C#'s raw performance (since they won't be pushing the limits that much anyway). Unless they already code in C# of course - then going with C# might be easier since they are learning just the engine, and not the programming language at once. As I had previous experience with Python, but not with C#, Java or C++ I was happy to learn GDScript and I absolutely love it, especially how it works in Godot 4. If I was experienced with C# I'd probably try it first instead. - unfa
@@pygmalioninvenus6057 To be fair unity is like a very small percentage of use for c", it's mainly famous because of microsoft, a lot of corporation use it for web dev or Desktop applications
I wanted to know just in case, but yh, it just made sense on paper to use GDscript as it is included in the godot install. With unity ans unreal you need an IDE and install the programming language the engine uses, otherwise you cant edit it.
As usual - great explanation. Thank you! I work with GDScript and try to type everything to make debugging easier, but also I believe in Godot 4 it provides a slight performance benefit. - unfa
Sure, we recommend GDScript after all. And this channel's format is: we answer your questions in 5 mn max. If you'd like, you can ask "how is it like to code in C# in Godot?" or "how well is C# supported in Godot?" or even "what are the advantages of C# over GDScript in Godot?" and I'll gladly add it to our bucket list! And I'm pretty sure then I'll also get a couple of "this video's very oriented, you didn't even show the pros of GDScript." But it's fine, I think it comes with the format.
@@GDQuestQA You answered to the question "Why to choose GDScript rather than C# ?" in your video. You didnt mention any advantage that you have to code in C#. That is why I think the video is not balanced. Being short is not an excuse since you choose the format and the questions of your videos.
@@michelsardur8233 I agree, it's not balanced, and I'm not claiming otherwise. That's My answers to people's questions are and will be highly subjective (as are most answers online). It's still my genuine 5-minute answer to the question, even if you don't like it. I genuinely don't see any definitive advantages to using C# primarily in Godot. That is unless you particularly like C# or you're a C# developer already, as mentioned in the video. There are many situational advantages, such as higher performance without having to use a second language, but it's not relevant for most of the community. It's gonna be very contextual. This is why I think what you'd like is a good fit for different questions and answers. And again, if this is what you want, the questions are welcome, please ask anytime!
I mean, even if you are a C# developer, does it matter that much ? If you're a programmer to begin with, language adaptability is an important part of the programmer's toolset. Surely over the course of a full game development, the time lost to adapt to GDScript is worth the speedup.
This. People make a great deal about them being "different" languages like if they were learning Prolog or something. At the end of the day, both are imperative languages and doing algorithms for both is mostly the same. The only thing C# has true advantage on is tooling. I often feel the GDScript *editor* to be more of a speed bump due to its lack of features (compared to Visual Studio) and weird idiosyncrasies, like having to press the Script button and lose sight of my scene if I try to edit an script. But the language itself it's not an issue in 2024 because it can be a typed language and with its tight integration, hot reloading capabilities, threading, signals and being generally optimized for game developing, you ought to be mad/stubborn to try to stick to C# because that's what the cool kids are doing nowadays.
@@carlosleyva-calistenia6400 Yeah I feel like I might do some C++ stuff if I have some performance critical code to execute, but the difference between C# and GDScript is just not worth in in most game scenarios !
@@carlosleyva-calistenia6400Godot doesn't support interfaces OR the concept of scopes. Add to that how many C# developers dislike Python-like languages. There's generally no reason to just switch to GDScript. Engine integration? I've seen at least two comments on this video say they had better luck working with VSCode C# than Godot GDScript and I agree with them. Signals? C# supports them, and it's only very slightly more annoying to work with than GDScript's signals. Optimized for game development? GDScript is better for prototyping but for actual game development C# is better.
@@richallenxbox1976Check out C# Player's Guide, it's an amazing C# book that teaches you programming from scratch. It uses video games as examples and has a lot of challenges to keep you on your feet.
I never programmed in C#. That's why I want to use it in Godot. Ist it a dumb idea to start learning C# in Godot? (I am not a too good programmer.. just finished my studies and have around 4 yrs of experience and have programmed in java, C/C++, JavaScript, Python)
simple question: do you want to take your skills outside of GameDevelopment? then use C# as this is not tied to godot and knowledge of c# can be used everywhere, if you don't gdscript is the better option
As unity developer that presently started Godot I prefer C with one main reason Code organizer for some reason in Gdscript If use the if steamed and press space before word I have plan to make the have error 😔 On the other hand if use c I'm able to use the word in whatever order I want as long the are interested the brackeys It's very anointing for my that gdscript need very specific order you are to write ✍️ each line And believe or not it's the only reason I don't like gdscript If Godot fixed this anointing error limitations I will probably not have any problem using gdscript
This definitely will help many persons to decide and get started. And agree, GDScript is the way to go unless you already are a C# developer and don't like GDScript (for any reason). Thank you for the content.
I don't understand why they developed gdscript... It has no use outside of Godot! They could have provided one or two languages that are widely used in game dev.
But if you're going to use AI to assist with your coding, c# might be better. I started using gdscript and got stuck in my project. I'm thinking of using AI to help with my game development. I don't think I can do that with gdscript.
AI assistant depend mostly on how much data it could train on, not only about a language, but about the specific frameworks. So for Godot C# the issue you'll face is that there's way less training data than for GDScript, so the AI will likely struggle to suggest useful Godot-specific functions and whatnot. What they could definitely help with is explaining the foundations of a popular language like C#.
The C# is going to be very slow compared to most uses of C# because Godot runs against the metal, but C# runs in a managed runtime. That means constant context switches every time youneed to call C# (or call a C/Godot API from C# code). And context switches are crazy slow. There's no getting around this unless Godot reimplements how C# is called.
I don't know if anyone will read this but I am starting new and don't know anything about programming. I heard godot is very beginner friendly, so I want to ask, is it better to learn gdscript of c#?
learn gdscript because it is easier to learn, with C# you are kind of jumping into the deep end, you don't need to worry about all that because you will be designing very basic logic at first and gdscript is really robust to learn when you are new because it covers concepts in a easier manner.
Regarding Godot 4, I wonder - if my game would for example need very expansive AI logic that needs to iterate over a lot of data every frame etc, would it be better to use C# or make an extension in say C++ to then call that extension from GDScript to offload the heavy-lifting to it? Would it make development and deployment more difficult than using C# instead?
Being a Linux and FOSS guy, I imagine you're comfortable compiling programs? If so, I'd recommend something like C++. You can even prototype in GDScript, and code generally translates pretty well to C++ when you hit a performance limitation. The C++ language is... definitely harder to use than C# due to memory management and terrible errors. But at the same time if you compile your own version of the engine and work on a game for a long time, using a C++ module, you won't suffer the frequent little compilation times you have with C# when testing your game. That's why I think it's worth trying out C++ for performance in Godot. Better even, if you have the budget or a good friend who knows C++, prototype your AI in GDScript and let them port that to C++ and provide the compiled engine. The biggest hurdle I've found with writing C++ is getting the memory management right when writing for performance, mostly due to really poor error reporting. When practicing writing data structures, I've had to ask an experienced C++ dev. to mentor me because I'd get an error in a method, but it was due to a line somewhere else and that line wouldn't get linter warnings or compiler errors.
@@nahuakang I recommend C++ right now mostly because you'll generally compile your engine with your module occasionally, just for a little high-performance code. While if you use C# right now you need to use the mono version of the editor and you'll add compilation time on each run of your game. But I also recommend c++ to Unfa because he already knows how to compile a c++ program, lots of people working with Free Software like him do things like these. And yes you can use the third-party Rust bindings for Godot with GDNative/GDExtension too
i start get into gamedev cuz i like to think about better game design for the game i have played game like valorant, apex legends and rocket leauge. Im closed with people who are into science stuffs like AI and computer software. I know they are closed to Python , so thats why i choose Godot engine cuz Gdscript is closed to Godot
DO NOT USE C#. It won't scale well. I wasted month because its integration is absolutely horrible. Since it runs in its sandbox, most feature ands up not working properly as it would with GDScript (which won't scale well either since it is badly optimized, even compared to C#'s runtime). They can't be extended as well, and since most classes are sealed, you won't be able to address issues yourself. You won't be able to use custom projects or class libraries, since godot only scans the game project for classes. Most things end up breaking in the editor, and custom resources ends up turning into empty objects without you noticing (once you save, you lose data. FUN!). tl;dr: DO. NOT. USE. C#. WiTH. GODOT.
godot is still lacks quality... can't even sync c# code properly... Yeah Unity has it's own problems... What godot is missing out is that there are tons of C# game devs out there. Time to decide godot.
