Note: Godot supports two gameplay scripting languages, C#, and its domain-specific language GDScript. You can also use C++ and C for high-performance code without having to recompile the engine via its GDNative technology. These are the four officially supported languages. Both interviewees are aware of that. C# has only been available in Godot for several years and until recently, it had issues or limitations. It's now getting to the point where it's supported about as well as GDScript and used by many users. But since this state is recent, neither Ben nor François have extensive experience with C# in Godot. If you code games with C# in Godot, please share your experience in the comments below, so people can get a sense for how it is right now.
Switching over to C# was a good experience and I have not encountered a single issue regarding compatibility or support of a specific feature yet. I am using C# with Visual Studio Code for programming and debugging since it has a better support for the language. The editor can still be used for everything else without a problem. The whole setup can be quite a ride tho, be warned. But if I could do it, you can do it too, it's not too bad. I switched over to C# a few weeks ago because I was missing some tools that help me write clean and efficient code. C# is a much more developed language with wayy more users and years on it's back. With GDScript I am looking forward to functionalities like generics and lambda functions. These methods allow greater readability and make the overall experience of writing an algorithm much more swift and pleasant. Also, I do not like defensive programming as a method to deal with undefined values like how it's done in GDScript. C# is a strongly typed language, which not only makes the code clear and straight forward but also eliminates some code issues on its own and improves the helping capabilities of your IDE necessarily. Nevertheless I am looking forward to the improvements of GDScript and I am ready to switch back when the time has come.
Here is an idea for a follow up video. Since 3.2.3 was released with Visual Studio support. Why not make a video explaining the current position of C# in the engine and why one may choose C# over GDScript?
I picked up Godot about 2 months ago, and directly took the risk of doing everything in C# without having to bother with gdscript. I just didn't like the way it felt and saw some preliminary stress tests that revealed a huge performance increase with C#. I knew that it was not supported fully yet and unstable (which even if I didn't know, Godot instantly told me when I first started the Mono Version) and was kinda expecting to get some Problems or even to get to a Point where gdscript inevitable but I've not run in to a single Problem ever since I started even though I got into Godot really hard really quickly. Sure, most of the code available Online for godot is in gdscript, but it's really no effort to just rewrite it into C#. I've worked on a handful of 3D Games now and Performance seems really good. Unfortunately, I can't directly compare it to gdscript's Performance because I haven't really worked with it and I didn't take the Time yet to rewrite a Game in gdscript and Compare. With a few tweaks I'm now able to use Godot with VS 2019 aswell and it works like a charm, really! There's an Extension for Godot Code Completion, Debugging, etc.. Support and it makes coding Godot Games with VS2019 super nice. Yeah so, I have had no Problems at all with C# and you can also just use it in Combination with gdscript, so you could write Performance-heavy Scripts in C# and the rest in gdscript, I think the Loading Screen in one of my Games is written in gdscript still because I took the code from the internet and didnt bother to rewrite it yet because it doesn't actually affect ingame performance and it works just as you would expect it too in the gdscript Godot Version.
I switched to Godot from Unity gradually over a course of time. For me the main pros of Godot are that the workflow is just so satisfying and enjoyable. I like how fast the editor is. I like the way scenes work in Godot, just makes the workflow so much cleaner and less overwhelming. And the fact, that the engine is open-source and MIT licensed. These are some of the pros of Godot for me. But even with all that, for a long time I was hesitant that Godot's 3D functionality wasn't good enough. But as I tried Godot in my spare time from day to day. I realised that for my purpose, Godot was absolutely perfect. Though it's 3D capabilities are not on par with Unity at the moment, but for my 3D needs of creating simple basic games, Godot is enough. And as I said before, it just feels so fun to work in Godot, it's workflow, speed and user interface makes the experience a real charm. As for Unity, though it's true it has many more features than Godot, but I often get a feeling that they are still very unpolished. I feel like Unity really needs to improve and polish some of their existing aspects of the engine. I still like it a lot and wish a bright future ahead for Unity.
I've made the same game in Unity and Godot, the 2D from Godot is far better than Unity, the collisions are more precise and your game take less storage, because It's not a "fake 2D environment", Godot has a dedicated system to it, and the best part it have the own code editor. So, I prefer to use Godot for 2D and Unity for 3D. :)
Can you explain this “fake 2d” in unity? I major in computer graphics and the only time I heard “fake x” was in wolfenstein era when they try to raycast and try to simulate 3d. Oh you made a lot of games. More precise? Less storage? Would you mind sharing these games of yours.
@@화성-v4g With this word I mean 3D and 2D in Unity are basically camera switchs, Godot has a dedicated 2D workspace that turn it more lightweight for the games, and for begginers like me, with not much hardware acess by the way, it turn more useful, you can test the game more fast for example.
Alright, so I'm a software engineer that uses C# daily. And recently I started getting more into game development. A while back I installed Unity and tried getting some stuff to work, but the sheer amount of tools and how huge it was was quite intimidating. So a few weeks ago I tried Godot, this engine immediately felt easy to use. It had a very small learning curve and has a simple and straightforward UI. I personally love it in combination with C#. I'm not gonna switch anytime soon!
@@_v_m_ Nope,he meant that godot 4 is not 100% yet. Vulkan is already implemented and it is on the stage of testing and improving. You can get godot 4 and compile it yourself but there are some few bugs left.
I just came back to Game Dev, and I wanted to know if I wanted to do Godot or Unity so I did Unity VS Godot yesterday and you just uploaded this video! Thanks, I chose to go for Godot :)
Trying to open an empty project in Unity : * waits for 6 mins Opening a project I've already spent tens of hours on in Godot: * opens almost immediately
Godot seems really unclean in accessing a node/scene instanced after instancing. The best way I've found is to store each instanced scene in an array, then call whatever index you need
@@tuatarian6591 The instance method returns the scene you just instanced. The best way to access an instanced node depends on context (groups, relative path, etc.). However, I will say that Unity's export features work a lot better than Godot's. There is a feature proposal open to make Godot's a lot better.
@@tuatarian6591 Most of Godot's best practices boil down to applying object-oriented programming principles. It depends a lot on the context but if possible, you want to make the instanced nodes self-contained so they don't need something else to control them. If you need something to control them you can add them to the scene tree and their parent can access them through get_children(). You can also connect signals when instancing so you don't need to access properties or call methods on the instanced node. Again, it depends on the context, but there are ways to keep coupling low.
@@Gdquest agreed, and at that point you'd generally build state machines, but it is nice to be able to quickly bodge something inelegant together, especially for a project you have no intention of continuing. It's also really not super easy to access info from instanced scene's parents unless you know exactly what level of the scene tree you will be one Code generation capabilities are also somewhat limited. I am a nim user, I've gotten quite comfortable with the world of macros, templates, and metaprogramming, and losing that while it handy
@@natew4724 right, but let's say I need to access the 2nd or third last scene instanced. There's no clean way to do that. You can hack something together, but there's no easy way to do that
Did some game dev at University and tried picking it up over the years since using Unity, never really got past the first few tutorials before feeling uninterested. With Godot I have been sitting here for not even a single day and have an almost fully completed first level of a basic 2D platformer. I can really see myself putting together my own original game with Godot. It's so easy to use and understand.
Great video guys, loved your take on it (yes I'm a bit late to the party :) ). My only two cents as always when someone asks me which engine to use, it's the one you feel most comfortable with. Unity can be the best engine in the world but if you're not comfortable using it, you won't make a great game with it. The exact same goes for Godot. And that ultimately is 100% subjective and a different answer for each and any individual.
@Fırat For Godot? The wonderful thing is that Godot works equally well on both so the best OS is the OS you're most comfortable with. The only exception is for us VR developers because unfortunately only a handful of headsets are supported on Linux so depending on the headset you use you may not have a choice. But that is not a Godot limitation.
"I like Godot because it gaves the minimum tools to get my vision done" and "I like Unity because of the sheer amount of tools to get my vision done", ok, got it.
@@yalkn2073 Not necessarily. It's like when you see the minimum and recommended specs for a game. You can technically play with minimum specs but its not ideal
becoming a game developer has always been my dream since middle school, but i have only started a few weeks ago, the sole reason i am using Godot is because it is much much smaller than Unity also lighter. Well i might understand other things along the way.
For me, Godot feels like a better idea or a better workflow, whereas Unity feels more "finished". Which kind of makes sense, Unity is the older, bigger player, so of course its going to have more polish, but of course its also going to be held down by decisions of the past, with new workflows feeling more like they're bolted on than a core part of the engine (the biggest example of this is of course Godots scene system vs Unity's prefab system). As for which one provides more tools to developers, I dont really feel like either, and its actually a point of minor annoyance and confusion to me as very specific, and seemingly arbitrary things, are missed out by both engines (the examples that came to mind for me is sprite masking in godot, and camera smoothing in unity. Both are doable of course, but neither are just a standard, provided feature for both engines).
After watching this I feel like I awoke in a universe where C# is not even implemented for Godot. Very strange indeed. UPDATE: Unlike the interviewees I am well aware of the status of C# in Godot.
If I understand correctly, it's that C# is fairly new in Godot, so neither of the interviewees had much/any experience with it. I've seen devs say elsewhere that C#'s integration in Godot is now about ad good as GDscript's.
C# is not fully implemented in Godot, there are still lots of bugs and incomplete functionality. I've tried setting up Godot to use C# and VS about a dozen times and it still doesn't work...so...Unity it is!
@@user-og6hl6lv7p I have been using C# and Godot for well over a year having come from Unity. There is no problem in using C# with Godot if you accept this video does not give a clear picture of Godot and C#. If you download the latest Godot Mono build 3.2.3, there is no setup required other than Editor Settings > Mono > Editor > Visual Studio... and that's it! Nothing else to do. I have a fair amount of experience with Unity too. They are both good at what they do. I just need something more to the point like Godot for the types of home brew games I like to build.
They make it sound like C# is the lesser language to use in Godot, while I would call it the better of 2 options if you're coming from Unity to Godot or even in general C# as a language has more features and a much bigger ecosystem than GDscript Yes all the tutorials you find for Godot are written in GDscript but it's pretty much a 1 to 1 translation from GDscript to C# that no one with a bit of programming experience should have a problem with There are some QoL improvements in GDscript over C# like `$` and `onready` but those are easy to get over and don't outweigh the other benefits C# has I might be a bit biased though
It's true that development continues with C#, and it seems that recently its integration got up a notch. Also, Gamedev.TV is porting their complete Godot course to C#, which might help people who want to learn with that language.
@@Gdquest they do? last time i have seen there was a one game course for C# in godot and in last year ben was saying thay they will make a new course for C# with different games.
I have been a professional game developer for quite some time now. I have the most experience with Unreal Engine, but I have also had the chance to work seriously with Unity. Both are great tools, being a fanboy is harmful. Depending on the project I might select either of them. I recently started using Godot. I instantly fell in love with it. It has its charms, loved the ease of use. However, it's work in progress. I really felt the limitations of GDScript. It's simply not a mature language. I felt that it's hard to do things the "right way" with it.
@@Gdquest Will definetely do. Godot is wonderful. It's already a serious alternative. I bet with time it will become even better. Generally I'm not a fan of custom languages. I have had the chance to work for one of the biggest gaming companies (won't name it because I'm sure I'll be breaking NDA). We used a custom language build from scratch in addition to C++. It didn't end well. In the end, the custom language support was too costly and popular languages are just better. Now there is a dedicated team that ports everything written in it back to C++ because these systems are still used in new multibillion dollar franchises. My point is, custom languages are really hard to pull off. Another example is Epic Games, their Unreal Script (or whatever it was called) followed the same fate.
@@krisitak Totally agree. Custom languages are hard to support and just not the mainstream. Same reason why Unity dropped Boo (their own scripting language) years ago. Any game engine will highly profit if it supports well established languages like C++, C# or Java. Simply because many third party libraries and routines are available and can be integrated into the game.
Unreal gang here. Unreal just feels so polished and complete. Altough it can be very confusing a overwhelming at first. But once you get more confortable, It has all the features that you could ever want.
I'm a software engineer by profession and although I tried getting into gamedev in the past, I couldn't make it very far with Unity or UE4. I was a complete stranger to the domain, so getting bombarded with jargon and concepts practically paralyzed me. I kept fighting against the norm, trying to come up with my own solutions to each individual problem, and although I'm an avid functional programming fan I always found myself falling into the OOP trap, trying to handle everything with inheritance and generic programming. Also, abundance of information is a double edged sword; it's a life saver for sure, but you'll first have to get through countless tutorials that are either outdated, considered bad practice in a general programming sense, or just outright false and sent you off in the wrong direction. After a few years of break I met Godot, and it completely changed my perspective. The concise nature of the engine is reflected by the content creators themselves, so tutorials are much more refined and to the point. miziziziz and GDQuest themselves are great examples. Thanks to them I now find it way more easier to come up with solutions, and I can get much more work done in a much shorter amount of time. The scene system is a bliss, and quite frankly Godot's most powerful feature. With it, Godot is more than just a game engine; it's a platform for building any kind of interactive system, from apps to presentations and even modern art projects. That said, after about a few months of tinkering with Godot, I now find myself restrained by Godot's shortcomings, especially in 3D and physics. Once you go over a certain threshold in complexity, things start to get blurry; tools in the engine might be broken or operate in a counter-intuitive manner, tutorials and documentation may be lacking, the engine itself might be bugged, a necessary feature might be in the pipeline for the next release, etc. As a concrete example, I had a top-down 2D puzzle game where I bounced a ball around, but when I used the standard physics bodies and properties, all movement felt a bit odd. I then tweaked all properties, switched to kinematic physics, and everything was great until I had to calculate collisions and reflections. I really had to do a lot of digging around until I was able to achieve sphere casting in 2D space, and when I finally did it, I found out that physics system was bugged, and sometimes caused the collisions to never be detected, or go through obstacles and collision shapes in the tilemap itself. After a lot internal debate I decided to switch to 3D, remade a few assets, and met with the nightmare that is the Blender to Godot pipeline. I kept having to change import settings for each model and when I did a reimport, I had to manually tweak or redo scene setups or materials with the new model. Once I was able to achieve a working, albeit manual and cumbersome, asset work pipeline, I met my next nightmare that is mesh libraries and 3D tile maps. Though its 2D counterpart works reasonably well, the 3D tile map editor forced me countless times to delete entire grid maps and mesh libraries and redo them from scratch with different names because otherwise they somehow stayed broken, probably due to an outdated cache somewhere. If you've got the time and energy to deal with issues like these, then by all means, feel free to fix them for the greater good; with a little love and effort, Godot can become the perfect engine. But if not, you'll either have to wait, cut features from your game, or just switch to another engine. Since I can barely find the time to work on my game, I really need things to "just work", so I don't think I can continue like this any longer. I'm not sure if Unity will prove better, but I guess I'll have find that out.
Hello. I really admire you, and your tutorials have helped me through many problems. But I ran into a problem with a new 2D rpg that I am creating, where the menu has a parallax background with trees and clouds separate, and I was just wondering if you could make, or already have made, a video on how to make the parallax layers follow the mouse.
I've used both as a hobbyist. I personally prefer Unity. Unit testing is something very important for serious projects, Unity has it as a native feature. Godot not, but I think there are some packages you can download to set it up. Writing C# in Visual Studio with auto completion is very nice. You need Interfaces to follow some OOP principles, and Godot doesn't have interfaces. Godot encourages you to reference nodes by name. If you wish to change the node name to fix a typo, you brake your code. This is why it's a bad coding practice. Godot is free. Yes, but don't be cheap! If you make money with it, you should support Godot's development on Patreon. Unity simply makes you support them when you make $100k in one year (which, let's face it, you will never make). Paying for a product isn't the end of the world, I pay for stuff all the time.
I really like your bit especially about supporting Godot even if it's free. That's exactly why I try to use an open source workflow as much as possible, and if I start making money? I'll start contributing some of it towards those projects. Sure, all the "pros" use Maya, Substance, Photoshop, whatever...but sheesh if I'm not making any money from my work, I'd still be paying $100-something a month just to HAVE software. Yikes! It's for this reason I'm really glad FOSS exists, and even if it's a bit cludgier in places, I support it for that "underdog"ness and the community's sake. :)
When I read that GDScript doesn't have interfaces I assume that people doesn't understand DuckTyping. The transition between a static typed language to a dynamic typed language can be challenging but you don't need to have a declarate interface, you have an interface through DuckTyping
@@juanmanuelcostello9510 A lot of programmers want something that autocompletes in the editor so they have more of an assurance that the code won't break at runtime (that's what an interface gives you, an assurance that you'll get a compile-time error instead of runtime). It can be easy to accidentally forget to check that something exists with duck typing.
R_Rare that’s BS. There’s a bunch of good games that have that splash screen. Even if you don’t have that unity like splash screen in your godot game, if your game is shit, no one will play it. Some big indie dev like Klei entertainment has that splash screen one point on their dev time but people still enjoy their “Unity Personal edition” game maybe your game is just shit.
I usually look at end results and environment first, when choosing a software (engine). -Can it deploy to platform x -Can it run a project of a certain complexity y with a good performance -What are the file formats it can handle -Is it creating a standalone app for the end user (no wired external links to libraries needed) -What languages does it support Unity just wins here for me, especially due to C# and the good mobile support.
Godot has also first-class C# support and good mobile support. Mobile is one of the areas where it shines as you can target a much wider range of devices than with Unity. We've seen some mobile game studios trying to migrate from Unity to Godot recently.
Godot really needs to adopt Kotlin as it's official language. It has so much less overhead than C#. It was a dream changing from Java to Kotlin on my app dev gig.
i love unity ECS, Pure ECS with the minimum amount of GameObjects and i look for it even while coding stuff that are not a game. someday i might even code something that is not a game in unity to use ECS. its like a whole new language that forces you to write performant and also multi-thread safe code. i love how unity compiles most of my c# code as machine code and does some compiler tricks to make me write less while writing my systems in ecs.
They both more or less ignore the fact that C# can be used natively in Godot. Is it because they don't know or that C# is not there yet? Never tried C# in Godot so I have to idea in what state it is
First you lose performance. Second the godot way to work with c# is a worse in comparison with unity, and lack support of some functionalities that gdscript have.
@@Andre-Banana I think that's not true. Performance of C# should be faster. Pasting the official documentation here: "According to some preliminary benchmarks, the performance of C# in Godot - while generally in the same order of magnitude - is roughly ~4× that of GDScript in some naive cases. C++ is still a little faster; the specifics are going to vary according to your use case. GDScript is likely fast enough for most general scripting workloads. C# is faster, but requires some expensive marshalling when talking to Godot." So the performance is C++ fastest, then C# and slowest variant is GDScript. But yes, some convenience stuff is missing in the C# binding but that's just adding a few lines of code.
Both François and Ben know about C# in Godot very well. It's just that C# used to not be a first-class citizen in Godot, with some issues still present until recently. We'd have to make games in C# with Godot to assess its current state and support. It seems to be getting pretty good.
@@rightanglegames The point regarding C# not being faster is that you may mostly call functions on the engine, in which case c# or GDScript doesn't make much difference; accessing the ClassDB and calling the method is about the same speed in C# and GDScript. For instance, when you call move_and_slide, the code that runs is a lot of compiled C++. For logic implemented entirely in C# or GDScript, like a PCG algorithm, you may be able to get orders of magnitude faster with C# right now. It depends entirely on the context.
@@Gdquest That was my impression also from what I read that C# support is getting on par with GDScript. Of course it needs to be properly tested but I think that the video should acknowledge that, because it might turn some people away for no good reasons.
I started working on a 3d game a month ago, with little to no prior experience with game dev... sort of. I am a programmer, and I did fiddle with action script in highschool, but other than some very shallow dives here and there, I never really went in. I picked Godot, because... well, I guess, first and foremost because I'm a Linux user... and also because I coded in python a lot. I did briefly used Unity and Unreal, but never felt in control... with Godot, I am in control... sure, I had quite a few issues to figure out and work around certain limitations, but it's starting to look better and better by the day, and I'm gonna stick with it for the long run.
As an interface designer I've found Godot's interface nodes cumbersome to work with and how they handle simple things like alignment very unintuitive. Unfortunately every suggestion to improve the nodes and fix the problem is answered with: "write an interface plugin by yourself."
I disagree... the far less number of tutorials make learning godot a lot difficult for beginners... I use godot because my pc cannot run unity smoothly... otherwise i would never have used godot
@@anindyaroythetechmaster I tried both of them as beginner , and I feel godot much easier to understand. It is really similar to python , and both of them have small download size , and I think godot is really good to help people understand object oriented programming
I haven't used Godot other than downloading it and looking at it. I am a unity fanboy but as a beginner, Unity is deffo the best I think, the amount of tutorials and good documentation out there is amazing! Great way to start game dev.
@@neck-o if your a beginner start with unity I think. If your not, use whatever you like? Godot and unreal from my understand their main weakness is just less tutorials out there then unity has.
I am currently switching from unity to godot for 2d games cause the coding language is c# and it becomes too big while godot's gdScript is very good, easy to learn (it is easier than c#) and small. Thats my main reason to switching to godot for 2d. Maybe I will use UnrealEngine4 for 3d
Hi, I've been learning Unity and C# for 2D game dev. I have no background etc. Since Phyton is the most used language and very important, what I'm thinking is to learn Godot to learn Phyton too while experiencing a new game engine. Hope what I'm thinking is good and practicle.
Godot doesn't use Python, and Python, while a popular language in data science and machine learning (among others), is mostly used for asset pipelines in games; not in game programming itself.
For me the video felt pretty contradictory and not very useful. I see that some viewers felt similar. It sounds like the best advantages Godot has is that it's free and that it has less features so it is simpler. But Unity on the other hand seems to be better at almost every important thing a developer could need. Hard to believe that both of them are currently using Godot. I apreciate your content (and theirs) but I feel like the overall message wasn't totally fair with Godot.
I rather feel that some people tend to interpret things a bit too black-and-white. I personally see two persons who see pros and cons to each engine and who found Godot to be a good fit for them.
@@Gdquest I'm sorry if I am too critic, but "I feel that it wasn't totally fair" doesn't sound too black-and-white to me. Anyway, I think that these kind of videos are something very different to teaching that require a lot of experience and feedback, but I really think that your tutorials are excellent, don't take me for a hater.
@@AlvaroLand what I meant to reply to by black-and-white was that you can't believe they are using Godot. As if the video made the point that unity is the better option. I get a different vibe from the interviewees' answers, not so clearcut. And don't be afraid to be critical, I appreciate it. I certainly won't take offense and I'm taking good note of people's feedback. E.g. on c# among other things.
@@Gdquest I really apreciate that. I said that it was hard to believe because I feel like the overall message is that unity is better at most things, but of course different people will have different views on that. Just wanted to let you know that at least I got that impression, and maybe I am not the only one.
Here's a quick breakdown. I watched DevDucks vid on going from Unity to Godot with his 2d game. What took him six months to do in Unity he got up and running in Godot in about a week. Surprised that wasn't brought up.
Language does not matter so much as picking the right data structer. Regaurdless of languange speed that more important. It can speed up the code or take up less space on your computer. The best language in this case is the one you know the best.
imo godot would be perfect for new games that are quite popular but simle enough, like RPG's, godot allows so much flexibility in that matter, godot is probably (currently at least) not good for simulation games, the gdscript language just isn't fast enough to handle them, maybe as time goes either C# becomes main language, or gdscript becomes fully statically typed (which will make it easier to optimize, will make it run close to C#), or otherwise it remains the same, and the most expensive logic will run in native code.
Sometimes I think, I need to use godot for my games, but then after some research especially for mobile and its thirdparty sdk, I decide to use unity again. Will wait until godot have good support for 3rd party sdk I guess.
It's fine, it's like Python, but in some contexts it can be too slow. For example, for someone making a simulation game with many calculations, or a game that relies on procedural content generation with heavy algorithms, you may want to implement the performance-intensive algorithms in C++. We've had to do that for a heatmap algorithm, it ran 200 times faster with C++ and GDNative compared to GDScript. Most of the demo is in GDScript but that one class that calculates the heatmap is in C++.
GDscript is designed to get your (G)od (D)amn game done. It's better to have a COMPLETE, but less performant game that you can optimize later by switching heavy code to a C++ utility, than to have a NO GAME at all.
Advantage of godot I like the most is its not make large dependencies (or whatever) for a project. Unity already consume 3gb more or less for a new project, while for ue 6 gb more or less. Affecting the startup much faster for godot. Just hoping more plugin or tools to speed up project. Unity best because it has many plugin.. At first I think Godot is a joke, since only 34Mb. But the tools is very awesome, don't know how dev make the size so small. And its portable.
I appreciate that DevDuck confirmed that godot is better to learn for game developers who are starting off, as someone who is trying to get into general game development, I can now resist the peer pressure from unity being such a popular game engine a little better.
Ok here's my opinion...I don't know much about Godot (yet) but as a unity developer the instability of unity drives me crazy. You import an addon, unity breaks You delete an addon, unity breaks You use urp/hdrp all materials (including those from bought products) break You program, half of the built in functions don't work anymore You sneeze, unity breaks And oh did i mention the bugs? I didn't see any of that in godot. Even if it is less mature it is much more stable and 99% of unity games can be done with godot anyway. I wish i could quit unity
I have actually tried Unity before I've known about Godot. The main disadvantage with Unity was that it was really confusing to use. The 11 Unity "games" I made were very bug-filled and, apart from using original assets, were only 1 step up from being a stereotypical Asset Flip. And that's saying something when you consider that I actually tried to make at least half of them good. Meanwhile I have seldom encountered bugs with any of my 3 Godot games (1 joke game, 1 cancelled, 1 in development), and were easily fixed with maximally 1 day after getting the right forum answer. For me, Godot is actually easy and fun to use, even a bit in the harder times.
@Epoch plus5 I use GD script when using Godot but I'm very much at a beginner level with it. Construct is visual scripting which I find much more intuitive
Yup, actually François in the video contributed to it quite a bit, adding debugger support in VSCode. But the code completion comes from Godot's language server, and it's not as mature as some general purpose language like C# or Python.
You can handle your exceptions in your C# code. The Godot engine itself doesn't provide exception handling to the user; instead, it keeps the program running even when errors happen. In GDScript, you use duck typing. Methods like get(), has_*(), the is keyword, and more allow you to check if you can call a function or something. A common error people face is trying to access nodes or objects that were already freed. All objects have a signal that tells you when they are about to exit the scene tree (queued for deletion) and some notifications allow you to run code before an object's deletion. I personally haven't had trouble with the absence of exceptions. Even in Python, I actually don't use try: much, but tend to use duck typing instead (getattr, hasattr, etc.)
@@Gdquest yes those exception in which nodes are accessed is actually users fault but if your are creating levels from script there is problem of divide by zero exception which Godot of course reports but for this implementation logic has to be changed Anyway thanks for your time you guys are a great community and I appreciate all your help.The first tutorial for godot I saw was yours 😉
I guess it will affect your learning speed, they look pretty different (I'm going to switch to Godot therefore can't say much) but every game engines have basic similarities
If you are programmer prefer open source like Godot but in case you thinking you can without programming making games use unreal or unity.but Godot also have Visual scrpt.
I've been making games for a little less than a year with Godot and only made a couple of prototypes with Unity but I already have some thoughts about this topic: -I like Godot more in the codding side because I don't have a programming background, so I find GDscript to be more intuitive and user friendly. -Godot REALLY needs to work on the implementation of ads and third party api's, like Google Game Services. I know it is a thing about Godot politics not to have support for third party software that is not open sourced but having so many problems to work with in-app purchases or ads makes Godot a no-go engine for mobile games. -It is true that Unity works better with 3D but I don't know if you can make Godot work as well as Unity managing threads in code manually. -I think Godot is going to be huge soon since it's been popular for too little time compared to Unity (if we can consider Godot popular) but the fact that is this awesom this soon and has so many people collaborating in the evolution of the engine... Man, it is going to be a BEAST!
One point of correction from what both of these guys said; Unity is almost the same age as Godot, they were started within a few months of each other. So no, Unity does not have a massive head start on Godot in terms of maturity and age. Godot was a closed source in-house engine for quite a few years at a studio that focused mostly on mobile gaming before they decided to open source it. And now that it has been, and really picked up traction with a supportive community, it's growth rate is quite a bit faster than Unity's. If anything Unity will be the one struggling to keep up before long, as there are only so many engine devs they can onboard without it affecting their bottom dollar, while the volunteer community around Godot just keeps growing and growing, even if a lot of it is just people using the engine, who are helping to report/fix bugs. The big difference between their development, is that for the first several years Godot was mostly the work of 2 developers, while Unity had a larger team. But as soon as Godot went open source, the number of devs contributing to Godot started to grow at a pretty incredible rate. So while Unity probably seen some quicker growth early on, they will (or possibly even already have) plateaued far sooner than Godot will. In an MMO sense, Unity is like a warrior class that started out strong but struggles to hold it's own in the late game. While Godot is more of a wizard class, early on it was a bit of a struggle and took careful strategy to progress, but through the mid-game quickly ramps up and eventually ends up near god level in the late game. Our two heros are in the mid-game now, the warrior is starting to feel the struggle. While the wizard has established its stride and is starting to accelerate. lol
If you count the old engines Juan (and perhaps Ariel) made and count as part of Godot's history, Godot's actually older. That started around 2000 while Unity launched in 2005 I believe. Still, I think the point about maturity holds: it's about the technology. As you said, 2 devs for Godot, probably they worked part time as I know Juan had a company and did work for various game companies. Unity has had a head start in the sense they've been developing this engine with a good budget and larger team for a long time. Even as an advocate of Godot and contributor, I don't know that Unity will start to struggle. Time will tell, but they're still a billion-dollar company that can spend massive budgets in marketing, sales, training, and even technology. They have some excellent engineers working there. But I do think Godot has a bright future and brought sane competition in the game engine space. The model and team are working great and they're making gamedev accessible to more and more people (FOSS, runs on low-end computers, many in the community do open-source stuff...).
@@Gdquest To me, all the money and resource Unity keeps dumping into everything other than the engine is what makes me think they are kinda peaking. They are still adding stuff to the engine now and then, but so much of it ends up being a bit of a mess, there are a lot of stuff where they remade something 2 or 3 times and often left the old stuff in to avoid breaking compatibility, but ever release it seems they still end up breaking stuff anyhow. I don't bother with Unity at all, as it still has pretty half-assed support for Linux with no guarantees of continued support, since it is still just unofficial builds hidden away in the forums even now years after they started to release Linux builds of the editor. But I've got a fair few friends who went with it for their projects and many of them, especially those further along with their projects, seem to just complain about it a lot. Many of them have been considering switching to either Unreal or Godot, but doing so would mean losing months of progress in many cases, so they continue to stick with Unity for their current projects. Tossing money and more devs, who need to be slowly and quite expensively brought up to speed, at a code base will only get you so far. Especially if you don't have a good foundation to build upon and a clear direction and goals for everyone to work towards and solid leadership with minimal bureaucracy mucking up the works. And I can't help but feel that Godot is better off on just about all of those fronts, even without the same budget.
Hey, thanks for the comparison! I really needed it since my second game engine ever is Godot. What I like about Godot is that the editor is built in the engine, which lets you test your code without saving the script with CTRL+S, unlike the Atom editor I used to use in Ren'py, I had to save so my code is updated to test. The thing I hate about Godot's editor is that it's so slow to update. By "slow" I mean when I make a typo then correct it, it takes a few seconds to realize "Oh, the user corrected the typo, let's remove the error". Do you recommend any editor to use with Godot that let's you test the code without saving and update the code's state fast? I remember a video you did about an editor, but I don't know if it offers the desired features.
The slow thing you mention is the linter. It has an editor setting. Editor -> Settings, search for Idle time. By default, the editor waits for two seconds after you stopped typing to run the compiler on your code.
@@Gdquest Thanks, will surely try it. If you can adjust the idle time, then why not make it wait 0 seconds as a default from the start? I am assuming it will cause errors or require more rams or stuff?
@@salehodinie6615 When the compiler faces an error, you lose autocompletion at the moment. It would also run the compiler on the file continuously, using a lot of CPU, yes.
When you get too good at making games and you don't want to pay that 100 000$ ~> remember that godot exists someday godot will reach the peak just like blender
I'm a bit confused why dev duck is clearly much preferring c# over gdscript but still... using the gdscript godot version instead of the c# version. Hell you can even mix them. Why is "unity uses c#" a benefit at all? Godot does too. Sure, support is a little bit less for that if you're a complete beginner because a large part of the community uses gdscript but... his entire point is that he knows c# already so that's not an issue for him
I was expecting someone to point out that Godot's 3d part is very anemic and has bad performance (also packs filters and much of the post processing goodies unity and UE4 has)
There are few 3D games in dev with Godot, and fewer devs who have good experience with 3D in Godot and in Unity. I'd rather wait for Godot's 3D side to get a bit more polish before comparing it with Unity.
I like godot haven't tried unity so can't really tell although generics is not available but there is dynamic allocation where you can define what kind of object is the variant so I don't really understand what you're trying to say. Plus godot also have c++ support although its difficult to get it up and running but I think it should be faster. If you know more about it. Enlighten me;)
Actually, Godot officially supports C# so you have generics. In the video, François was just comparing GDScript to C#. Generics give you type safety in cases where you don't know the type of a collection in advance. The type checker validates the way your code uses instances for a generic at compile-time. In Godot 3.2, GDScript doesn't even have type checking for arrays, so you don't have an equivalent of that feature yet.
I use both the engines But I use Godot for 2d games and unity for 3d games. In my opinion Godot is better than unity in 2d games Godot is not that good at 3d games. So I use Unity for 3d games. I recommend Godot for 2d games and Unity for 3d games
The games made in Unity in 3D has slow performance and still not in pair for most advanced game engines such as Unreal Engine. If you are looking for an engine to make 3D Games with 2021 better graphics, Unreal Engine is the best choice.
@@rodrigopachaurivillafuerte9211 Using unreal isn't going to instantly makes your games look good. You need good art skills to make good looking games. Which game engine you use doesn't matter if you have trash art skills.
I will wait until gdscript becomes faster or it has a *proper* implementation of C#. Gdscript is 10x slower to execute the same code, and that's a huge deal breaker for me. It's funny how the developers are insisting that the engine is still capable of creating your "dream game". My dream game must run above 60fps, so that's no dice for me.
Seems the C# integration got up a notch over the coming months. I had some persons tell me they haven't had issues with C# since the last update. Might be worth giving another try. Regarding writing fast code, initially, Godot was built with a front-end language for gameplay programming, GDScript, and a back-end language for high-performance. Basically, you were supposed to write fast code as a C++ module, or now, with GDNative as a dynamically linked library. François used GDNative this for a Heatmap algorithm in one of our projects, and the performance is great. Anyway, just to say that for the few times you need to implement a heavy algorithm, you already have C and C++ as options since years ago. When calling functions on the C++ backend, like move_and_slide on kinematic bodies, there's no difference between GDScript and C#.
There is no black and white guys. You hear, listen, read, trial and error and make up your own mind. Don't expect a TH-cam video to take the decision for you. This is just an opinion of two developers who have tried both. Get used to different kinds of feedback and be open. That is what Open Source is all about.
No, there's a dedicated 3D engine, the renderer is getting a remake and performance optimizations for Godot 4. It's pretty nice to use, although at the moment, it probably works best for top-down views or if you're comfortable writing some simple optimization code, like doing portal culling (hiding rooms outside the view). There are some commercial 3D games made with Godot in dev right now, like Ben Hickling's lovely Ex-Zodiac, or TailsQuest, so you can definitely use it even professionally.
GDQuest I love your effort on trying to promote godot in 3d. I don’t want to be negative here but let’s be real here. Even though godot have 1000 contributors submitting their fixes, they will never beat those 3d game engines with billions of dollar in their pockets. Unreal engine 5 latest tech took thousands of people and phds over a decade just to make it possible. There’s a big difference between some random person in the community submitting fixes on something to someone who focused their entire lives in a certain research or technology (masters/phds).
@@화성-v4g Godot's not trying to compete with Unity or Unreal. It's fine if they don't make an engine tailored to AAA game studios. There are plenty of smaller teams that don't need anything like that. And in general, you only have some rendering experts working on an engine. Godot has 3 persons specialized in rendering now, including lead dev Juan with his ~20 years of experience writing engines.
For me Unity and Godot are like Coke and Pepsi. Of course one is more famous and everybody likes it because of the hype, but give the other one a chance
Actually Unity is one of the slowest game engine in video game dev history, so unless your game is too simple to charge your GPUs, 3D for Unity is not a good choice. most of games made with Unity3D suffer performance issue anyway. On the other hand, Godot is much faster if you us GDNative extensively, so for 3D games Godot is better choice than Unity (or choose Unreal instead) IMO Unity = 2D Godot = 3D is right in contrast of common belief.
You can do animation retargeting, that's just a matter of building your animations based off IK controls, and potentially scaling or repositioning the controls based on the character size. If you're looking for some GUI to do this for you, it does not exist, you have to code it. I assume no GUI is the real issue you have.
@@gamechannel1271 not being able to visual animations is a huge turn off. It's very, very time consuming to do it purely through code. They really need to step up their game.
If you're serious about game dev, I think you should really consider unity financial backing, thousands of employees & huge community , cross platform ability .... I hope Godot succeeds, however, I think unity is a much more viable option if you are not a hobbyist. do your own research & find what's best for you Good luck
![[Gegagedigedagedago] NEW Help Gegagedigedagedago Nugget escape from Nikocado Avocado Challenge](http://i.ytimg.com/vi/hJWnwRC2Fz8/mqdefault.jpg)
Note: Godot supports two gameplay scripting languages, C#, and its domain-specific language GDScript. You can also use C++ and C for high-performance code without having to recompile the engine via its GDNative technology. These are the four officially supported languages.
Both interviewees are aware of that. C# has only been available in Godot for several years and until recently, it had issues or limitations. It's now getting to the point where it's supported about as well as GDScript and used by many users. But since this state is recent, neither Ben nor François have extensive experience with C# in Godot.
If you code games with C# in Godot, please share your experience in the comments below, so people can get a sense for how it is right now.
Switching over to C# was a good experience and I have not encountered a single issue regarding compatibility or support of a specific feature yet.
I am using C# with Visual Studio Code for programming and debugging since it has a better support for the language. The editor can still be used for everything else without a problem.
The whole setup can be quite a ride tho, be warned. But if I could do it, you can do it too, it's not too bad.
I switched over to C# a few weeks ago because I was missing some tools that help me write clean and efficient code.
C# is a much more developed language with wayy more users and years on it's back.
With GDScript I am looking forward to functionalities like generics and lambda functions. These methods allow greater readability and make the overall experience of writing an algorithm much more swift and pleasant.
Also, I do not like defensive programming as a method to deal with undefined values like how it's done in GDScript.
C# is a strongly typed language, which not only makes the code clear and straight forward but also eliminates some code issues on its own and improves the helping capabilities of your IDE necessarily.
Nevertheless I am looking forward to the improvements of GDScript and I am ready to switch back when the time has come.
@@eliaszielke7764 Godot supports static typing.
docs.godotengine.org/en/stable/getting_started/scripting/gdscript/static_typing.html
e: added documentation URL
Here is an idea for a follow up video. Since 3.2.3 was released with Visual Studio support. Why not make a video explaining the current position of C# in the engine and why one may choose C# over GDScript?
I picked up Godot about 2 months ago, and directly took the risk of doing everything in C# without having to bother with gdscript. I just didn't like the way it felt and saw some preliminary stress tests that revealed a huge performance increase with C#. I knew that it was not supported fully yet and unstable (which even if I didn't know, Godot instantly told me when I first started the Mono Version) and was kinda expecting to get some Problems or even to get to a Point where gdscript inevitable but I've not run in to a single Problem ever since I started even though I got into Godot really hard really quickly.
Sure, most of the code available Online for godot is in gdscript, but it's really no effort to just rewrite it into C#. I've worked on a handful of 3D Games now and Performance seems really good. Unfortunately, I can't directly compare it to gdscript's Performance because I haven't really worked with it and I didn't take the Time yet to rewrite a Game in gdscript and Compare.
With a few tweaks I'm now able to use Godot with VS 2019 aswell and it works like a charm, really! There's an Extension for Godot Code Completion, Debugging, etc.. Support and it makes coding Godot Games with VS2019 super nice.
Yeah so, I have had no Problems at all with C# and you can also just use it in Combination with gdscript, so you could write Performance-heavy Scripts in C# and the rest in gdscript, I think the Loading Screen in one of my Games is written in gdscript still because I took the code from the internet and didnt bother to rewrite it yet because it doesn't actually affect ingame performance and it works just as you would expect it too in the gdscript Godot Version.
In unity we don't care programming language, all we need is burst compiler, IL2CPP, just one click solution!
I switched to Godot from Unity gradually over a course of time. For me the main pros of Godot are that the workflow is just so satisfying and enjoyable. I like how fast the editor is. I like the way scenes work in Godot, just makes the workflow so much cleaner and less overwhelming. And the fact, that the engine is open-source and MIT licensed. These are some of the pros of Godot for me.
But even with all that, for a long time I was hesitant that Godot's 3D functionality wasn't good enough. But as I tried Godot in my spare time from day to day. I realised that for my purpose, Godot was absolutely perfect. Though it's 3D capabilities are not on par with Unity at the moment, but for my 3D needs of creating simple basic games, Godot is enough. And as I said before, it just feels so fun to work in Godot, it's workflow, speed and user interface makes the experience a real charm.
As for Unity, though it's true it has many more features than Godot, but I often get a feeling that they are still very unpolished. I feel like Unity really needs to improve and polish some of their existing aspects of the engine. I still like it a lot and wish a bright future ahead for Unity.
The fact that Godot is compared with Unity is a big achievement in it self.
Espescialy since Godot is running on funds and support when Unity is a big multi millianare even billionare company
Godot deserve it 😊
Yes
I've made the same game in Unity and Godot, the 2D from Godot is far better than Unity, the collisions are more precise and your game take less storage, because It's not a "fake 2D environment", Godot has a dedicated system to it, and the best part it have the own code editor.
So, I prefer to use Godot for 2D and Unity for 3D. :)
Yeah, the amount of Godot advantages that weren't even mentioned is god damn high xD
I agree
thank you it helps
Can you explain this “fake 2d” in unity? I major in computer graphics and the only time I heard “fake x” was in wolfenstein era when they try to raycast and try to simulate 3d.
Oh you made a lot of games. More precise? Less storage? Would you mind sharing these games of yours.
@@화성-v4g With this word I mean 3D and 2D in Unity are basically camera switchs, Godot has a dedicated 2D workspace that turn it more lightweight for the games, and for begginers like me, with not much hardware acess by the way, it turn more useful, you can test the game more fast for example.
Alright, so I'm a software engineer that uses C# daily. And recently I started getting more into game development. A while back I installed Unity and tried getting some stuff to work, but the sheer amount of tools and how huge it was was quite intimidating. So a few weeks ago I tried Godot, this engine immediately felt easy to use. It had a very small learning curve and has a simple and straightforward UI. I personally love it in combination with C#. I'm not gonna switch anytime soon!
I wish I could switch to Godot for 3D work, but it's just not 100% there yet. :)
Wait for Godot 4
@@JVJF7 Looking forward to it. ^-^
@@_v_m_ Nope,he meant that godot 4 is not 100% yet. Vulkan is already implemented and it is on the stage of testing and improving. You can get godot 4 and compile it yourself but there are some few bugs left.
@@JVJF7 what's with godot 4?
@@sportsbluff4501 Occlusion Culling, Vulkan Renderer, GDScript 2.0, etc.
I just came back to Game Dev, and I wanted to know if I wanted to do
Godot or Unity so I did Unity VS Godot yesterday and you just uploaded this video!
Thanks, I chose to go for Godot :)
Animation retargeting is a huge timesaver in Unity, I really wish Godot has that
why dont you just code it into Godot, it's open source after all
What is that?
@@halobread or i can make my own engine
@@glassystudio It would be a lot easier to modify an existing engine than to create a new one
@@mirfan-2020 sorry but i was being sarcastic, i use unity btw
Trying to open an empty project in Unity : * waits for 6 mins
Opening a project I've already spent tens of hours on in Godot: * opens almost immediately
Both engines definetely have their hairy bits, it's just about where they are
Godot seems really unclean in accessing a node/scene instanced after instancing. The best way I've found is to store each instanced scene in an array, then call whatever index you need
@@tuatarian6591
The instance method returns the scene you just instanced. The best way to access an instanced node depends on context (groups, relative path, etc.).
However, I will say that Unity's export features work a lot better than Godot's. There is a feature proposal open to make Godot's a lot better.
@@tuatarian6591 Most of Godot's best practices boil down to applying object-oriented programming principles. It depends a lot on the context but if possible, you want to make the instanced nodes self-contained so they don't need something else to control them. If you need something to control them you can add them to the scene tree and their parent can access them through get_children(). You can also connect signals when instancing so you don't need to access properties or call methods on the instanced node.
Again, it depends on the context, but there are ways to keep coupling low.
@@Gdquest agreed, and at that point you'd generally build state machines, but it is nice to be able to quickly bodge something inelegant together, especially for a project you have no intention of continuing.
It's also really not super easy to access info from instanced scene's parents unless you know exactly what level of the scene tree you will be one
Code generation capabilities are also somewhat limited. I am a nim user, I've gotten quite comfortable with the world of macros, templates, and metaprogramming, and losing that while it handy
@@natew4724 right, but let's say I need to access the 2nd or third last scene instanced. There's no clean way to do that. You can hack something together, but there's no easy way to do that
Did some game dev at University and tried picking it up over the years since using Unity, never really got past the first few tutorials before feeling uninterested. With Godot I have been sitting here for not even a single day and have an almost fully completed first level of a basic 2D platformer. I can really see myself putting together my own original game with Godot. It's so easy to use and understand.
Great video guys, loved your take on it (yes I'm a bit late to the party :) ). My only two cents as always when someone asks me which engine to use, it's the one you feel most comfortable with. Unity can be the best engine in the world but if you're not comfortable using it, you won't make a great game with it. The exact same goes for Godot. And that ultimately is 100% subjective and a different answer for each and any individual.
@Fırat For Godot? The wonderful thing is that Godot works equally well on both so the best OS is the OS you're most comfortable with.
The only exception is for us VR developers because unfortunately only a handful of headsets are supported on Linux so depending on the headset you use you may not have a choice. But that is not a Godot limitation.
"I like Godot because it gaves the minimum tools to get my vision done" and "I like Unity because of the sheer amount of tools to get my vision done", ok, got it.
Note Ben didn't say minimum. He said Godot gives him "just the right amount" of tools, that is to say, it has everything he needs.
Hilarious🤣, but i believe he ment the tools are hidden away behind nodes unless he needs them
@@Gdquest just the right amount IS the same as minimum
@@yalkn2073 Not necessarily. It's like when you see the minimum and recommended specs for a game. You can technically play with minimum specs but its not ideal
LOL... 😂. It's hard to find any entertaining comment in any youtube video in any youtube channel
This was a fantastic video - very helpful and clear. thank you!! Appreciate you sharing this.
Great video!
This was refreshingly brilliant. Thank you :)
becoming a game developer has always been my dream since middle school, but i have only started a few weeks ago, the sole reason i am using Godot is because it is much much smaller than Unity also lighter. Well i might understand other things along the way.
8:05 utiny
Mutiny
1:47 Ok. That aged extremely well!
Can you guys do a tutorial on how to put Google play services in godot games?
The Monobehaviour-architecture of Unity is just cleaner than the oversimplified scene-node architecture of Godot. It promotes scaleable code.
For me, Godot feels like a better idea or a better workflow, whereas Unity feels more "finished". Which kind of makes sense, Unity is the older, bigger player, so of course its going to have more polish, but of course its also going to be held down by decisions of the past, with new workflows feeling more like they're bolted on than a core part of the engine (the biggest example of this is of course Godots scene system vs Unity's prefab system).
As for which one provides more tools to developers, I dont really feel like either, and its actually a point of minor annoyance and confusion to me as very specific, and seemingly arbitrary things, are missed out by both engines (the examples that came to mind for me is sprite masking in godot, and camera smoothing in unity. Both are doable of course, but neither are just a standard, provided feature for both engines).
Great explanation thank you!
After watching this I feel like I awoke in a universe where C# is not even implemented for Godot. Very strange indeed. UPDATE: Unlike the interviewees I am well aware of the status of C# in Godot.
You can use c# with godot, plus c++ besides gd script.
If I understand correctly, it's that C# is fairly new in Godot, so neither of the interviewees had much/any experience with it. I've seen devs say elsewhere that C#'s integration in Godot is now about ad good as GDscript's.
C# is not fully implemented in Godot, there are still lots of bugs and incomplete functionality. I've tried setting up Godot to use C# and VS about a dozen times and it still doesn't work...so...Unity it is!
@@user-og6hl6lv7p I have been using C# and Godot for well over a year having come from Unity. There is no problem in using C# with Godot if you accept this video does not give a clear picture of Godot and C#. If you download the latest Godot Mono build 3.2.3, there is no setup required other than Editor Settings > Mono > Editor > Visual Studio... and that's it! Nothing else to do. I have a fair amount of experience with Unity too. They are both good at what they do. I just need something more to the point like Godot for the types of home brew games I like to build.
This is the best unity vs godot comparison on the internet that I have seen to date.
They make it sound like C# is the lesser language to use in Godot, while I would call it the better of 2 options if you're coming from Unity to Godot or even in general
C# as a language has more features and a much bigger ecosystem than GDscript
Yes all the tutorials you find for Godot are written in GDscript but it's pretty much a 1 to 1 translation from GDscript to C# that no one with a bit of programming experience should have a problem with
There are some QoL improvements in GDscript over C# like `$` and `onready` but those are easy to get over and don't outweigh the other benefits C# has
I might be a bit biased though
Can you register a script as a class using c#?
@@PerroConChaleco Every C# script you add to a node is a separate C# class, so I guess the answer is "yes".
It's true that development continues with C#, and it seems that recently its integration got up a notch. Also, Gamedev.TV is porting their complete Godot course to C#, which might help people who want to learn with that language.
@@Gdquest they do? last time i have seen there was a one game course for C# in godot and in last year ben was saying thay they will make a new course for C# with different games.
Absolutely agree.
I have been a professional game developer for quite some time now. I have the most experience with Unreal Engine, but I have also had the chance to work seriously with Unity. Both are great tools, being a fanboy is harmful. Depending on the project I might select either of them. I recently started using Godot. I instantly fell in love with it. It has its charms, loved the ease of use. However, it's work in progress. I really felt the limitations of GDScript. It's simply not a mature language. I felt that it's hard to do things the "right way" with it.
It seems C# support is finally really robust in Godot, you may want to give it a try.
@@Gdquest Will definetely do. Godot is wonderful. It's already a serious alternative. I bet with time it will become even better. Generally I'm not a fan of custom languages. I have had the chance to work for one of the biggest gaming companies (won't name it because I'm sure I'll be breaking NDA). We used a custom language build from scratch in addition to C++. It didn't end well. In the end, the custom language support was too costly and popular languages are just better. Now there is a dedicated team that ports everything written in it back to C++ because these systems are still used in new multibillion dollar franchises. My point is, custom languages are really hard to pull off. Another example is Epic Games, their Unreal Script (or whatever it was called) followed the same fate.
@@krisitak Totally agree. Custom languages are hard to support and just not the mainstream. Same reason why Unity dropped Boo (their own scripting language) years ago. Any game engine will highly profit if it supports well established languages like C++, C# or Java. Simply because many third party libraries and routines are available and can be integrated into the game.
@@rightanglegames Not to mention that a powerful language takes decades to mature.
Unreal gang here. Unreal just feels so polished and complete. Altough it can be very confusing a overwhelming at first. But once you get more confortable, It has all the features that you could ever want.
Thx a lot for cool video!
I'm a software engineer by profession and although I tried getting into gamedev in the past, I couldn't make it very far with Unity or UE4. I was a complete stranger to the domain, so getting bombarded with jargon and concepts practically paralyzed me. I kept fighting against the norm, trying to come up with my own solutions to each individual problem, and although I'm an avid functional programming fan I always found myself falling into the OOP trap, trying to handle everything with inheritance and generic programming. Also, abundance of information is a double edged sword; it's a life saver for sure, but you'll first have to get through countless tutorials that are either outdated, considered bad practice in a general programming sense, or just outright false and sent you off in the wrong direction.
After a few years of break I met Godot, and it completely changed my perspective. The concise nature of the engine is reflected by the content creators themselves, so tutorials are much more refined and to the point. miziziziz and GDQuest themselves are great examples. Thanks to them I now find it way more easier to come up with solutions, and I can get much more work done in a much shorter amount of time. The scene system is a bliss, and quite frankly Godot's most powerful feature. With it, Godot is more than just a game engine; it's a platform for building any kind of interactive system, from apps to presentations and even modern art projects.
That said, after about a few months of tinkering with Godot, I now find myself restrained by Godot's shortcomings, especially in 3D and physics. Once you go over a certain threshold in complexity, things start to get blurry; tools in the engine might be broken or operate in a counter-intuitive manner, tutorials and documentation may be lacking, the engine itself might be bugged, a necessary feature might be in the pipeline for the next release, etc.
As a concrete example, I had a top-down 2D puzzle game where I bounced a ball around, but when I used the standard physics bodies and properties, all movement felt a bit odd. I then tweaked all properties, switched to kinematic physics, and everything was great until I had to calculate collisions and reflections. I really had to do a lot of digging around until I was able to achieve sphere casting in 2D space, and when I finally did it, I found out that physics system was bugged, and sometimes caused the collisions to never be detected, or go through obstacles and collision shapes in the tilemap itself.
After a lot internal debate I decided to switch to 3D, remade a few assets, and met with the nightmare that is the Blender to Godot pipeline. I kept having to change import settings for each model and when I did a reimport, I had to manually tweak or redo scene setups or materials with the new model.
Once I was able to achieve a working, albeit manual and cumbersome, asset work pipeline, I met my next nightmare that is mesh libraries and 3D tile maps. Though its 2D counterpart works reasonably well, the 3D tile map editor forced me countless times to delete entire grid maps and mesh libraries and redo them from scratch with different names because otherwise they somehow stayed broken, probably due to an outdated cache somewhere.
If you've got the time and energy to deal with issues like these, then by all means, feel free to fix them for the greater good; with a little love and effort, Godot can become the perfect engine. But if not, you'll either have to wait, cut features from your game, or just switch to another engine.
Since I can barely find the time to work on my game, I really need things to "just work", so I don't think I can continue like this any longer. I'm not sure if Unity will prove better, but I guess I'll have find that out.
Hello. I really admire you, and your tutorials have helped me through many problems. But I ran into a problem with a new 2D rpg that I am creating, where the menu has a parallax background with trees and clouds separate, and I was just wondering if you could make, or already have made, a video on how to make the parallax layers follow the mouse.
I've used both as a hobbyist. I personally prefer Unity.
Unit testing is something very important for serious projects, Unity has it as a native feature. Godot not, but I think there are some packages you can download to set it up.
Writing C# in Visual Studio with auto completion is very nice. You need Interfaces to follow some OOP principles, and Godot doesn't have interfaces.
Godot encourages you to reference nodes by name. If you wish to change the node name to fix a typo, you brake your code. This is why it's a bad coding practice.
Godot is free. Yes, but don't be cheap! If you make money with it, you should support Godot's development on Patreon. Unity simply makes you support them when you make $100k in one year (which, let's face it, you will never make). Paying for a product isn't the end of the world, I pay for stuff all the time.
The terrible "personal edition" splash screen destroys everything. Who wants "Unity Personal Edition" on their game?
I really like your bit especially about supporting Godot even if it's free. That's exactly why I try to use an open source workflow as much as possible, and if I start making money? I'll start contributing some of it towards those projects.
Sure, all the "pros" use Maya, Substance, Photoshop, whatever...but sheesh if I'm not making any money from my work, I'd still be paying $100-something a month just to HAVE software. Yikes! It's for this reason I'm really glad FOSS exists, and even if it's a bit cludgier in places, I support it for that "underdog"ness and the community's sake. :)
When I read that GDScript doesn't have interfaces I assume that people doesn't understand DuckTyping. The transition between a static typed language to a dynamic typed language can be challenging but you don't need to have a declarate interface, you have an interface through DuckTyping
@@juanmanuelcostello9510 A lot of programmers want something that autocompletes in the editor so they have more of an assurance that the code won't break at runtime (that's what an interface gives you, an assurance that you'll get a compile-time error instead of runtime). It can be easy to accidentally forget to check that something exists with duck typing.
R_Rare that’s BS. There’s a bunch of good games that have that splash screen. Even if you don’t have that unity like splash screen in your godot game, if your game is shit, no one will play it. Some big indie dev like Klei entertainment has that splash screen one point on their dev time but people still enjoy their “Unity Personal edition” game maybe your game is just shit.
I usually look at end results and environment first, when choosing a software (engine).
-Can it deploy to platform x
-Can it run a project of a certain complexity y with a good performance
-What are the file formats it can handle
-Is it creating a standalone app for the end user (no wired external links to libraries needed)
-What languages does it support
Unity just wins here for me, especially due to C# and the good mobile support.
Godot has also first-class C# support and good mobile support. Mobile is one of the areas where it shines as you can target a much wider range of devices than with Unity. We've seen some mobile game studios trying to migrate from Unity to Godot recently.
Godot has a lot of momentum and enthusiasm from my perception as a person who is just interested in software.
Godot really needs to adopt Kotlin as it's official language. It has so much less overhead than C#. It was a dream changing from Java to Kotlin on my app dev gig.
Thanks! Godot vs Unreal should be interesting to compare as well 👍
i love unity ECS, Pure ECS with the minimum amount of GameObjects
and i look for it even while coding stuff that are not a game.
someday i might even code something that is not a game in unity to use ECS.
its like a whole new language that forces you to write performant and also multi-thread safe code.
i love how unity compiles most of my c# code as machine code and does some compiler tricks to make me write less while writing my systems in ecs.
They both more or less ignore the fact that C# can be used natively in Godot. Is it because they don't know or that C# is not there yet? Never tried C# in Godot so I have to idea in what state it is
First you lose performance. Second the godot way to work with c# is a worse in comparison with unity, and lack support of some functionalities that gdscript have.
@@Andre-Banana I think that's not true. Performance of C# should be faster. Pasting the official documentation here:
"According to some preliminary benchmarks, the performance of C# in Godot - while generally in the same order of magnitude - is roughly ~4× that of GDScript in some naive cases. C++ is still a little faster; the specifics are going to vary according to your use case. GDScript is likely fast enough for most general scripting workloads. C# is faster, but requires some expensive marshalling when talking to Godot."
So the performance is C++ fastest, then C# and slowest variant is GDScript. But yes, some convenience stuff is missing in the C# binding but that's just adding a few lines of code.
Both François and Ben know about C# in Godot very well. It's just that C# used to not be a first-class citizen in Godot, with some issues still present until recently. We'd have to make games in C# with Godot to assess its current state and support. It seems to be getting pretty good.
@@rightanglegames The point regarding C# not being faster is that you may mostly call functions on the engine, in which case c# or GDScript doesn't make much difference; accessing the ClassDB and calling the method is about the same speed in C# and GDScript. For instance, when you call move_and_slide, the code that runs is a lot of compiled C++.
For logic implemented entirely in C# or GDScript, like a PCG algorithm, you may be able to get orders of magnitude faster with C# right now. It depends entirely on the context.
@@Gdquest That was my impression also from what I read that C# support is getting on par with GDScript. Of course it needs to be properly tested but I think that the video should acknowledge that, because it might turn some people away for no good reasons.
I started working on a 3d game a month ago, with little to no prior experience with game dev... sort of. I am a programmer, and I did fiddle with action script in highschool, but other than some very shallow dives here and there, I never really went in.
I picked Godot, because... well, I guess, first and foremost because I'm a Linux user... and also because I coded in python a lot.
I did briefly used Unity and Unreal, but never felt in control... with Godot, I am in control... sure, I had quite a few issues to figure out and work around certain limitations, but it's starting to look better and better by the day, and I'm gonna stick with it for the long run.
As an interface designer I've found Godot's interface nodes cumbersome to work with and how they handle simple things like alignment very unintuitive.
Unfortunately every suggestion to improve the nodes and fix the problem is answered with: "write an interface plugin by yourself."
I feel u the only thing what annoys me im godot
Can you make a video how to add in game purchases in Godot, please
As well as ads too
I think Godot for learning game development is similar to python for someone who want to learn programming , both are easy to understand for beginner
I disagree... the far less number of tutorials make learning godot a lot difficult for beginners... I use godot because my pc cannot run unity smoothly... otherwise i would never have used godot
@@anindyaroythetechmaster then get a better pc and run unity smh.
@@anindyaroythetechmaster I tried both of them as beginner , and I feel godot much easier to understand. It is really similar to python , and both of them have small download size , and I think godot is really good to help people understand object oriented programming
Great tutorial! Do you have any tutorial about calling external script or func in Godot ?
I think I'll stick with Unity for 3D and try Godot for 2D, thanks for the video!
Yay!
I haven't used Godot other than downloading it and looking at it. I am a unity fanboy but as a beginner, Unity is deffo the best I think, the amount of tutorials and good documentation out there is amazing! Great way to start game dev.
What are your honest opinions about Godot?
@@neck-o if your a beginner start with unity I think. If your not, use whatever you like? Godot and unreal from my understand their main weakness is just less tutorials out there then unity has.
Which is better for quality of rendering and graphic can you make
C# in Godot is great! GDNative isn't half-bad either!
@Arnav Vijaywargiya You should give godot-rust a shot. The docs are weird though
I am currently switching from unity to godot for 2d games cause the coding language is c# and it becomes too big while godot's gdScript is very good, easy to learn (it is easier than c#) and small. Thats my main reason to switching to godot for 2d. Maybe I will use UnrealEngine4 for 3d
Hi, I've been learning Unity and C# for 2D game dev. I have no background etc. Since Phyton is the most used language and very important, what I'm thinking is to learn Godot to learn Phyton too while experiencing a new game engine. Hope what I'm thinking is good and practicle.
Godot doesn't use Python, and Python, while a popular language in data science and machine learning (among others), is mostly used for asset pipelines in games; not in game programming itself.
For me the video felt pretty contradictory and not very useful. I see that some viewers felt similar. It sounds like the best advantages Godot has is that it's free and that it has less features so it is simpler. But Unity on the other hand seems to be better at almost every important thing a developer could need. Hard to believe that both of them are currently using Godot. I apreciate your content (and theirs) but I feel like the overall message wasn't totally fair with Godot.
I rather feel that some people tend to interpret things a bit too black-and-white. I personally see two persons who see pros and cons to each engine and who found Godot to be a good fit for them.
@@Gdquest I'm sorry if I am too critic, but "I feel that it wasn't totally fair" doesn't sound too black-and-white to me. Anyway, I think that these kind of videos are something very different to teaching that require a lot of experience and feedback, but I really think that your tutorials are excellent, don't take me for a hater.
@@AlvaroLand what I meant to reply to by black-and-white was that you can't believe they are using Godot. As if the video made the point that unity is the better option.
I get a different vibe from the interviewees' answers, not so clearcut.
And don't be afraid to be critical, I appreciate it. I certainly won't take offense and I'm taking good note of people's feedback. E.g. on c# among other things.
@@Gdquest I really apreciate that. I said that it was hard to believe because I feel like the overall message is that unity is better at most things, but of course different people will have different views on that. Just wanted to let you know that at least I got that impression, and maybe I am not the only one.
Here's a quick breakdown. I watched DevDucks vid on going from Unity to Godot with his 2d game. What took him six months to do in Unity he got up and running in Godot in about a week. Surprised that wasn't brought up.
Language does not matter so much as picking the right data structer. Regaurdless of languange speed that more important. It can speed up the code or take up less space on your computer. The best language in this case is the one you know the best.
imo godot would be perfect for new games that are quite popular but simle enough, like RPG's, godot allows so much flexibility in that matter, godot is probably (currently at least) not good for simulation games, the gdscript language just isn't fast enough to handle them, maybe as time goes either C# becomes main language, or gdscript becomes fully statically typed (which will make it easier to optimize, will make it run close to C#), or otherwise it remains the same, and the most expensive logic will run in native code.
hello can anyone help me in godot how to make a switch character or change the different character before running the game
Sometimes I think, I need to use godot for my games, but then after some research especially for mobile and its thirdparty sdk, I decide to use unity again. Will wait until godot have good support for 3rd party sdk I guess.
I don't feel the Gdscript performance slow
It's fine, it's like Python, but in some contexts it can be too slow. For example, for someone making a simulation game with many calculations, or a game that relies on procedural content generation with heavy algorithms, you may want to implement the performance-intensive algorithms in C++.
We've had to do that for a heatmap algorithm, it ran 200 times faster with C++ and GDNative compared to GDScript. Most of the demo is in GDScript but that one class that calculates the heatmap is in C++.
GDscript speed is fine unless you are processing large datasets
GDscript is designed to get your (G)od (D)amn game done. It's better to have a COMPLETE, but less performant game that you can optimize later by switching heavy code to a C++ utility, than to have a NO GAME at all.
Advantage of godot I like the most is its not make large dependencies (or whatever) for a project. Unity already consume 3gb more or less for a new project, while for ue 6 gb more or less. Affecting the startup much faster for godot. Just hoping more plugin or tools to speed up project. Unity best because it has many plugin..
At first I think Godot is a joke, since only 34Mb. But the tools is very awesome, don't know how dev make the size so small. And its portable.
I appreciate that DevDuck confirmed that godot is better to learn for game developers who are starting off, as someone who is trying to get into general game development, I can now resist the peer pressure from unity being such a popular game engine a little better.
You should do Unreal Engine vs Godot
Unreal engine is for ultimate 3d and godot for ultimate 2d you cant compire them
ram usage: UNITY > Godot
storage: UNITY > Godot
supported low quality PC/Lap : UNITY= no, Godot = yes
BEST: Godot!!!!!!!!!!
it looks like you're saying Godot uses more RAM but yes
I'm going to try making a game even though I don't know how to code.
Ok here's my opinion...I don't know much about Godot (yet) but as a unity developer the instability of unity drives me crazy.
You import an addon, unity breaks
You delete an addon, unity breaks
You use urp/hdrp all materials (including those from bought products) break
You program, half of the built in functions don't work anymore
You sneeze, unity breaks
And oh did i mention the bugs?
I didn't see any of that in godot. Even if it is less mature it is much more stable and 99% of unity games can be done with godot anyway. I wish i could quit unity
I have actually tried Unity before I've known about Godot.
The main disadvantage with Unity was that it was really confusing to use.
The 11 Unity "games" I made were very bug-filled and, apart from using original assets, were only 1 step up from being a stereotypical Asset Flip.
And that's saying something when you consider that I actually tried to make at least half of them good.
Meanwhile I have seldom encountered bugs with any of my 3 Godot games (1 joke game, 1 cancelled, 1 in development), and were easily fixed with maximally 1 day after getting the right forum answer.
For me, Godot is actually easy and fun to use, even a bit in the harder times.
I'm really liking the ease of construct 3. I find it so fast to work with 👍
@Epoch plus5 I use GD script when using Godot but I'm very much at a beginner level with it. Construct is visual scripting which I find much more intuitive
@Epoch plus5 it doesn't. Godot does 😁 I use both engines
Construct 3 now includes JavaScript for coding either in addition to visual scripting or just using JavaScript.
there is a gdscript plugin for IntelliJ (referring to 6:10)
Yup, actually François in the video contributed to it quite a bit, adding debugger support in VSCode. But the code completion comes from Godot's language server, and it's not as mature as some general purpose language like C# or Python.
"unity's particle system" - Dani
I want to see how far Godot can go until it can overtake Unity, Gamemaker and Unreal
How do you guys handle exceptions. I know it's designed to have exception free environment but that doesn't put ones mind to ease
You can handle your exceptions in your C# code. The Godot engine itself doesn't provide exception handling to the user; instead, it keeps the program running even when errors happen. In GDScript, you use duck typing. Methods like get(), has_*(), the is keyword, and more allow you to check if you can call a function or something.
A common error people face is trying to access nodes or objects that were already freed. All objects have a signal that tells you when they are about to exit the scene tree (queued for deletion) and some notifications allow you to run code before an object's deletion.
I personally haven't had trouble with the absence of exceptions. Even in Python, I actually don't use try: much, but tend to use duck typing instead (getattr, hasattr, etc.)
@@Gdquest yes those exception in which nodes are accessed is actually users fault but if your are creating levels from script there is problem of divide by zero exception which Godot of course reports but for this implementation logic has to be changed
Anyway thanks for your time you guys are a great community and I appreciate all your help.The first tutorial for godot I saw was yours 😉
Are skills that i got from godot transferable to Unity?
I guess it will affect your learning speed, they look pretty different (I'm going to switch to Godot therefore can't say much) but every game engines have basic similarities
Can you make more walkthrough tutorials instead of code review ?
If you are programmer prefer open source like Godot but in case you thinking you can without programming making games use unreal or unity.but Godot also have
Visual scrpt.
I've been making games for a little less than a year with Godot and only made a couple of prototypes with Unity but I already have some thoughts about this topic:
-I like Godot more in the codding side because I don't have a programming background, so I find GDscript to be more intuitive and user friendly.
-Godot REALLY needs to work on the implementation of ads and third party api's, like Google Game Services. I know it is a thing about Godot politics not to have support for third party software that is not open sourced but having so many problems to work with in-app purchases or ads makes Godot a no-go engine for mobile games.
-It is true that Unity works better with 3D but I don't know if you can make Godot work as well as Unity managing threads in code manually.
-I think Godot is going to be huge soon since it's been popular for too little time compared to Unity (if we can consider Godot popular) but the fact that is this awesom this soon and has so many people collaborating in the evolution of the engine... Man, it is going to be a BEAST!
9:46 discord message
One point of correction from what both of these guys said; Unity is almost the same age as Godot, they were started within a few months of each other. So no, Unity does not have a massive head start on Godot in terms of maturity and age.
Godot was a closed source in-house engine for quite a few years at a studio that focused mostly on mobile gaming before they decided to open source it. And now that it has been, and really picked up traction with a supportive community, it's growth rate is quite a bit faster than Unity's.
If anything Unity will be the one struggling to keep up before long, as there are only so many engine devs they can onboard without it affecting their bottom dollar, while the volunteer community around Godot just keeps growing and growing, even if a lot of it is just people using the engine, who are helping to report/fix bugs.
The big difference between their development, is that for the first several years Godot was mostly the work of 2 developers, while Unity had a larger team. But as soon as Godot went open source, the number of devs contributing to Godot started to grow at a pretty incredible rate. So while Unity probably seen some quicker growth early on, they will (or possibly even already have) plateaued far sooner than Godot will.
In an MMO sense, Unity is like a warrior class that started out strong but struggles to hold it's own in the late game. While Godot is more of a wizard class, early on it was a bit of a struggle and took careful strategy to progress, but through the mid-game quickly ramps up and eventually ends up near god level in the late game. Our two heros are in the mid-game now, the warrior is starting to feel the struggle. While the wizard has established its stride and is starting to accelerate. lol
If you count the old engines Juan (and perhaps Ariel) made and count as part of Godot's history, Godot's actually older. That started around 2000 while Unity launched in 2005 I believe.
Still, I think the point about maturity holds: it's about the technology. As you said, 2 devs for Godot, probably they worked part time as I know Juan had a company and did work for various game companies. Unity has had a head start in the sense they've been developing this engine with a good budget and larger team for a long time.
Even as an advocate of Godot and contributor, I don't know that Unity will start to struggle. Time will tell, but they're still a billion-dollar company that can spend massive budgets in marketing, sales, training, and even technology. They have some excellent engineers working there.
But I do think Godot has a bright future and brought sane competition in the game engine space. The model and team are working great and they're making gamedev accessible to more and more people (FOSS, runs on low-end computers, many in the community do open-source stuff...).
@@Gdquest To me, all the money and resource Unity keeps dumping into everything other than the engine is what makes me think they are kinda peaking. They are still adding stuff to the engine now and then, but so much of it ends up being a bit of a mess, there are a lot of stuff where they remade something 2 or 3 times and often left the old stuff in to avoid breaking compatibility, but ever release it seems they still end up breaking stuff anyhow.
I don't bother with Unity at all, as it still has pretty half-assed support for Linux with no guarantees of continued support, since it is still just unofficial builds hidden away in the forums even now years after they started to release Linux builds of the editor. But I've got a fair few friends who went with it for their projects and many of them, especially those further along with their projects, seem to just complain about it a lot. Many of them have been considering switching to either Unreal or Godot, but doing so would mean losing months of progress in many cases, so they continue to stick with Unity for their current projects.
Tossing money and more devs, who need to be slowly and quite expensively brought up to speed, at a code base will only get you so far. Especially if you don't have a good foundation to build upon and a clear direction and goals for everyone to work towards and solid leadership with minimal bureaucracy mucking up the works. And I can't help but feel that Godot is better off on just about all of those fronts, even without the same budget.
1:48 "Which means I never have to worry about making a successful game.."
lol
he meant if he did make a successful game, no one would take his money
@@meteor0id I'm surprised nobody said the woosh thing
@@Muhammed_English314 r/woooosh
I think it's four o's.
Love both engines however the fact that you can't publish your games to different systems is a bit let down.
Hey,
thanks for the comparison! I really needed it since my second game engine ever is Godot.
What I like about Godot is that the editor is built in the engine, which lets you test your code without saving the script with CTRL+S, unlike the Atom editor I used to use in Ren'py, I had to save so my code is updated to test.
The thing I hate about Godot's editor is that it's so slow to update. By "slow" I mean when I make a typo then correct it, it takes a few seconds to realize "Oh, the user corrected the typo, let's remove the error". Do you recommend any editor to use with Godot that let's you test the code without saving and update the code's state fast? I remember a video you did about an editor, but I don't know if it offers the desired features.
The slow thing you mention is the linter. It has an editor setting. Editor -> Settings, search for Idle time. By default, the editor waits for two seconds after you stopped typing to run the compiler on your code.
@@Gdquest Thanks, will surely try it.
If you can adjust the idle time, then why not make it wait 0 seconds as a default from the start?
I am assuming it will cause errors or require more rams or stuff?
@@salehodinie6615 When the compiler faces an error, you lose autocompletion at the moment. It would also run the compiler on the file continuously, using a lot of CPU, yes.
You can use C# in Godot
if you ask me
2D: Godot
3D: Unity
3D HQ: Unreal
When you get too good at making games and you don't want to pay that 100 000$ ~> remember that godot exists
someday godot will reach the peak just like blender
I'm a bit confused why dev duck is clearly much preferring c# over gdscript but still... using the gdscript godot version instead of the c# version. Hell you can even mix them. Why is "unity uses c#" a benefit at all? Godot does too. Sure, support is a little bit less for that if you're a complete beginner because a large part of the community uses gdscript but... his entire point is that he knows c# already so that's not an issue for him
I think this was before C# support was in.
I prefer Godot for 2D imo
I was expecting someone to point out that Godot's 3d part is very anemic and has bad performance (also packs filters and much of the post processing goodies unity and UE4 has)
There are few 3D games in dev with Godot, and fewer devs who have good experience with 3D in Godot and in Unity. I'd rather wait for Godot's 3D side to get a bit more polish before comparing it with Unity.
@@Gdquest then the title should be how they compare in 2d.
No, the video's not about 2D either. It just doesn't talk about 2D gamedev or 3D gamedev specifically. It's about two devs' personal experience.
I like godot haven't tried unity so can't really tell although generics is not available but there is dynamic allocation where you can define what kind of object is the variant so I don't really understand what you're trying to say. Plus godot also have c++ support although its difficult to get it up and running but I think it should be faster. If you know more about it. Enlighten me;)
Actually, Godot officially supports C# so you have generics. In the video, François was just comparing GDScript to C#.
Generics give you type safety in cases where you don't know the type of a collection in advance. The type checker validates the way your code uses instances for a generic at compile-time. In Godot 3.2, GDScript doesn't even have type checking for arrays, so you don't have an equivalent of that feature yet.
@@Gdquest yes it certain does have a disadvantage there. I understand thanks😊
Googling "Gadot game" instead of getting Gal Gadot 😂
what is the best java game engine?
edit: whether in or just a reply
Don't make games in Java. Horribly unoptimized.
@@beri4138 :| yeah... ive kinda given up on java... im writing them in c# now.
I use both the engines But I use Godot for 2d games and unity for 3d games. In my opinion Godot is better than unity in 2d games Godot is not that good at 3d games. So I use Unity for 3d games. I recommend Godot for 2d games and Unity for 3d games
The games made in Unity in 3D has slow performance and still not in pair for most advanced game engines such as Unreal Engine. If you are looking for an engine to make 3D Games with 2021 better graphics, Unreal Engine is the best choice.
@@rodrigopachaurivillafuerte9211 Using unreal isn't going to instantly makes your games look good. You need good art skills to make good looking games. Which game engine you use doesn't matter if you have trash art skills.
One major reason why I like Godot than Unity is that Godot is faster than Unity when opening the Game Engine.
😂yeah and prototypes are about 2-3 mb instead of 100+(I wonder even with null screen how unity can achieve this number).
godot vs unreal pleaseee
Well ?? which one is better? Unity or Godot ???
I started learn godot
I will wait until gdscript becomes faster or it has a *proper* implementation of C#. Gdscript is 10x slower to execute the same code, and that's a huge deal breaker for me. It's funny how the developers are insisting that the engine is still capable of creating your "dream game". My dream game must run above 60fps, so that's no dice for me.
Seems the C# integration got up a notch over the coming months. I had some persons tell me they haven't had issues with C# since the last update. Might be worth giving another try.
Regarding writing fast code, initially, Godot was built with a front-end language for gameplay programming, GDScript, and a back-end language for high-performance. Basically, you were supposed to write fast code as a C++ module, or now, with GDNative as a dynamically linked library. François used GDNative this for a Heatmap algorithm in one of our projects, and the performance is great.
Anyway, just to say that for the few times you need to implement a heavy algorithm, you already have C and C++ as options since years ago.
When calling functions on the C++ backend, like move_and_slide on kinematic bodies, there's no difference between GDScript and C#.
surprisingly neutral
There is no black and white guys. You hear, listen, read, trial and error and make up your own mind. Don't expect a TH-cam video to take the decision for you. This is just an opinion of two developers who have tried both. Get used to different kinds of feedback and be open. That is what Open Source is all about.
I'm getting the impression that Godot's 3D support is a sad afterthought.
No, there's a dedicated 3D engine, the renderer is getting a remake and performance optimizations for Godot 4. It's pretty nice to use, although at the moment, it probably works best for top-down views or if you're comfortable writing some simple optimization code, like doing portal culling (hiding rooms outside the view).
There are some commercial 3D games made with Godot in dev right now, like Ben Hickling's lovely Ex-Zodiac, or TailsQuest, so you can definitely use it even professionally.
GDQuest I love your effort on trying to promote godot in 3d. I don’t want to be negative here but let’s be real here. Even though godot have 1000 contributors submitting their fixes, they will never beat those 3d game engines with billions of dollar in their pockets. Unreal engine 5 latest tech took thousands of people and phds over a decade just to make it possible. There’s a big difference between some random person in the community submitting fixes on something to someone who focused their entire lives in a certain research or technology (masters/phds).
@@화성-v4g Godot's not trying to compete with Unity or Unreal. It's fine if they don't make an engine tailored to AAA game studios. There are plenty of smaller teams that don't need anything like that.
And in general, you only have some rendering experts working on an engine. Godot has 3 persons specialized in rendering now, including lead dev Juan with his ~20 years of experience writing engines.
@@화성-v4g why talking all about unreal engine 5? EPIC GAMES HAS MORE THAN 30 BILLION DOLLARS.
For me Unity and Godot are like Coke and Pepsi. Of course one is more famous and everybody likes it because of the hype, but give the other one a chance
Actually Unity is one of the slowest game engine in video game dev history, so unless your game is too simple to charge your GPUs, 3D for Unity is not a good choice. most of games made with Unity3D suffer performance issue anyway.
On the other hand, Godot is much faster if you us GDNative extensively, so for 3D games Godot is better choice than Unity (or choose Unreal instead)
IMO Unity = 2D Godot = 3D is right in contrast of common belief.
godot has a C# version doesnt it?
Yea, it does
I love Godot Engine and Gdscript 👍👍👍
Biggest drawback for godot for me, no animation retargeting for skeletons.
You can do animation retargeting, that's just a matter of building your animations based off IK controls, and potentially scaling or repositioning the controls based on the character size. If you're looking for some GUI to do this for you, it does not exist, you have to code it. I assume no GUI is the real issue you have.
@@gamechannel1271 not being able to visual animations is a huge turn off. It's very, very time consuming to do it purely through code. They really need to step up their game.
If you're serious about game dev, I think you should really consider unity financial backing, thousands of employees & huge community , cross platform ability ....
I hope Godot succeeds, however, I think unity is a much more viable option if you are not a hobbyist.
do your own research & find what's best for you
Good luck