I used Unity in the past and now use Godot and I appreciate your video a lot. Basically everything you went through I too ran into, ultimately I made the switch and feel better for it but Engines are more preference based. Hope you enjoyed Godot and remember it's always here if you wanna try again!
6:52 this is true for Node, but Node2D and Node3D do hold position information. The only difference between Position2D and Node2D is that Position2D is visible in the editor viewport
Fun fact about the name: It’s a MAJOR split and a major topic of debate with the community using both pronunciations interchangeably. The developers and founders themselves don’t help because they too apparently interchange the pronunciation. For me, I will always say Guh-doh because it’s like the Waiting for Godot play, but the strongest arguments I’ve seen for the latter is that the founder isn’t actually French, and the logo is a literal robot head, so it sounds more like robot. But it’s still constantly debated
Just wanted to make a note that the build-in editor does have full autocomplete for GDScript and is (in my opinion) quite good! It just doesn't have built-in support for the other languages as that would be pretty out of scope considering that most would prefer an external editor anyway since they are known languages with great tooling already available
You could also develop in C#, by using the official Godot plugin by JetBrains for Rider and enable network debugger in the Godot project's settings. That's what I've been doing, which gives you access to the entire C# ecosystem of packages.
@@Prajwal____ lol, imagine needing autocomplete so bad you quit if it's not quite there. btw godot 4 even generates documentation for your own code like what?? You can now learn about the snippets you copy paste your game together from.
5:40 the actual game does exactly this though, don't know why you eluded to it being different. the game would have several issues past a certain score if the camera was genuinely scrolling several thousand units. even games like The Outer Wilds and No Man's Sky implement player oriented coordinate centering in some sort of fashion. any time you use a float with a value larger than 32k ish, calculation precision is going to plumment and collisions are going to start to bug. The Outer Wilds always has the player at 0, 0 in the world. No Man's Sky chunk bases everything and makes target distant objects either disappear or show a fake (planets are actually a giant floating sphere and not the actual world object). then on the planet surfaces, it chunk splits them, so every time the player or object crosses a chunk boundary, its float coordinate resets but an integer value representing chunk number changes. same methodology for changing star systems and what have you
@@BrunodeSouzaLino Local vs. global coordinates don't inherently solve this, you can still run into floating point draw issues if you take something far enough unless you organize the game correctly, which as far as I know requires that you actively move the world in relation to the player still, as long as you don't use absolute positions to set the player's position (which in a game with infinite terrain is not usually a smart idea anyway) you will never notice the difference.
That's true - the first thing that you would like to do as Unity dev starting with Godot is to use c# and this is a mistake IMO. I mean c# is good if you need fast calculations, or maybe you want to use Linq or MySQL, etc. But in most cases, Gdscript is a way to go. The node system at first seems strange but later you will realize the true power of this system where everything is a node. Your code will be well organized by design. And is so reusable. You will start making separate folders for every node tree (scene), where everything needed for this scene will be included in this folder, like all nodes, sprites, scripts, etc. Then all you have to do, to reuse this in another project is just copy-paste this folder and everything will work. Not to mention the size of the projects. 1000 Godot projects (before exporting modules) will take less space than one Unity project. In 2D Godot is already better than Unity. For 3D we have to wait for Godot 4 with Vulcan and for some missing features like a good modern terrain generator plugin. And yes... everything is free and open source, including all assets in the Godot asset (plugins) library so you can learn how exactly they were made. Let's hope that after Godot 4 there will be more 3D tutorials because as for now Godot is lacking here. Unity is great, used it for years, but year after year it's getting worse. New features are added when basics are still missing or are buggy and nobody cares. Can you imagine that you can have dictionaries in the inspector in Godot? xD Or working HighLevel multiplayer server-client solutions out of the box? The last moves from Unity are shady and Unity is going in a strange direction. And remember to monetize as a Unity dev, otherwise, you are f***g id**t according to Unity's CEO (from EA)
@@woopslap I didn't say that you can't or should not. I wanted to say that nodes system in Godot is suited for duck-typing language like gdscript and c# is adding complexity that Godot doesn't need with the nodes approach. But sure you can use c#, I'm doing this myself from time to time, to use Linq or MySQL libraries for example. In gdscript you don't need abstract classes or interfaces as this is duck-typing language so you just call the void and even if this void doesn't exist this will not generate an error so gdscript doesn't need this. But as I said, you can for sure use c# if you want but is not needed really in most cases.
Didn't Unity start with its own Unityscript then it got scrapped in favor of c#. What if that happens with Gdscript then it's a waste of time learning.
@@woopslap DogTurtle is right, but I can give a more concrete example. Right now, I'm implementing in Godot an infinite 2d world map that can be scrolled in real time, at first based on opensimplexnoise. I started my code in shaders, then I ported it in GDScript. When it was finally working, with acceptable performance (there was an initial big drop), I started to port my gdscript to C# (so I can use other noise generators), and it's way more complicated and filled with boilerplate than in GDScript. Especially, all operations with vectors are a chore. In GDScript, you can add and multiply vectors with scalars and others vectors just like that. In C#, either you must write your own little vector toolbox or you must treat the vector like an array and iterate on it. Nodes aren't that easy to access, neither are their attributes. When I access to a shader material parameter, the code is way more complicated in C# than in GDScript. Another thing is the editor plus debugger. I use VSCode with Godot Mono, but it's still unstable. Right now, I lost autocompletion and inline debug without understanding why. With GDScript, the editor is inside Godot, including the debugger and a benchmark profiler, and it all works out of the box. No installation needed, no special version of .net needed, no incompatibility whatsoever. It just works. And those are reasons why I also think the GDScript would be a much better starting point for a beginner to discover and learn Godot.
I appreciate the learning value of this video, and the transitions being fairly smooth. My only points to bring to attention, and probably my personal opinion on it, is that this video asks a question in its thumbnail: "Should You Switch?" By the end of the video that question was not answered at all, partly because you didn't delve further into the Godot engine than the paper-thin surface of a 2D, non-rng generation tiles, and partly because half of it felt like it was trying to be a tutorial when it's not geared up to be one. Individually the info in the video is good and not saying the exploration you had was bad or pointless, etc, but it's basically what's in the packet is not what the packet said. I understand your title is different to the thumbnail, but many people would click this video for the purpose of the answering the question asked in the thumbnail and, like myself, be disappointed. Essentially click-bait.
I actually prefer Godot now. Unity became very bloated over time. They are finally trying to fix this, but it will take years to turn it back into a lean engine like it was back Unity 3. Godot really is the equivalent of Blender now. It is growing faster than the competition, but it still has some catching up to do.
I've started using Godot even for things like building forms or little apps (like DnD digital tabletop character sheets) because it's so lightweight and simple. I still sometimes wonder some basic things like which node in my game is the first event consumer, but so far everything's working fine.
I tried unity a few years ago, it was so messy and confusing I gave up. Recently I started studying godot and I didn't have this problem, and ended up learning well enough to make 2D games.
5:53 for 2D games this is actually really easy. Like, stupidly easy. Like you'd think it's cheating easy. What you do, is you add the camera node as a child of the player node, set the camera to current, and then in the camera options there is a dropdown called smoothing. That can be enabled and you can change the speed and this automatically does a basic following effect where the camera lags behind it's new position slightly. For a game like this where you have the player staying still, you could fake the effect by using the camera offset values, they don't change the cameras position but do offset the camera, so you can have it fake being lagged behind without much worry.
Great video. You picked up the basics of Godot Engine very quickly. It's probably better for most people to use GDScript for productivity reasons and code completion, and it is easy to learn: something like LUA or simplified Python.
@@alcidesneto6415 The most important thing with game dev is to get a MVP (minimum viable product), something that basically works. Then think about ways to optimize it if necessary. So start with GDScript which calls the built in C++ code anyway.
@@GDScriptDude The issue there is you're basically re-learning a new language from scratch. If you've already got significant experience in C# you want to get in and actually develop something rather than spend a while fiddling with a system with a totally different syntax. It's not so bad if you're experienced with Python, since they share a lot of similarities, but for people without that experience it's like starting from the ground up. That can make things even harder since you're stuck figuring out if its your code that's the issue, or the way it's implemented in Godot.
@@Crystan I think his choice fits in well with the "so you're moving to Godot...". If it was a "so you're starting with..." the choice would have been different because there would be little baggage. Especially important with the "so you're escaping Unity..." push going on by the community.
OOOH I thought that was odd, because I use Godot with GDScript (Python is my "native" language, I learned to program in Python, and GDScript is like Python with a sexy Australian accent or something so) and it does offer code completion there. I guess it doesn't in C#?
Any chance you could make tutorials with your way of explanation? I have just realized that to understand things, I need to: see them, read them, hear them - so your graphical as well as text and voice explanation of the structure of scenes and nodes is very easy to understand and remember for me, I will watch this video over and over again to understand that a scene is a pack of nodes which together as a whole create an object, and to make a game you make scenes with packed contents, aka nodes. (and scripts and etc.)
I use Godot for my project because it's open source and friendly to all levels of all experiences. Yeah, it has some drawbacks but it's overall good to me and the community is friendly as well. :D
the only thing i needed to know about godot was the scene/objects system that is the nodes. this is the only video that explains the concept properly. thanks!
Also just about every node has a position that can be used by looking at its position. You could also use the Godot animate player, you can use it to animate just about any property on the nodes. Something I don't think many of the other game engines can do, including unity and unreal.
Wow thanks, no one ever explained Godot's Node system in a way that I actually understood until now. Nice job! Also ya I'm the same. I'm already working on a game in Unity, so even though Godot interests me idk for sure if I wanna make the change or not lol
5:32 Regardless, the infinite terrain generation system isn’t the approach you’d want to take, at least with Unity. Once you get far enough from the origin, the position of the objects will begin to suffer from noticeable rounding imprecisions and it’ll look kinda glitchy. You’ll have experienced this if you ever saw those videos of people launching themselves on the go-karts in VRChat around 2017 if anyone remembers those
Thanks for sharing your experience diving into Godot. I've not tried it yet, I use Unity too. It's neat to hear how this engine works differently and seeing your journey.
I still prefer Unity because I'm very much a manual guy and like to code everything myself (Whereas Godot does a lot for you). But I like what you said at the end. Switching engines won't make you a AAA Game Developer. I find that everyone that shuns you for the engine you use are normally pretty bad at game dev in any case and get hung up on technicalities instead of learning how to make something good
What are you saying? Both Godot and Unity do a lot for you. They are called game engines for a reason. Coding everthing yourself would mean you pick up SDL or something and implement things you need from scratch. Can you give an example of what you do manually in Unity that Godot does for you instead? Personally I found Unity to be more constraining in what way I needed to design my code whereas Godot feels much more open ended and programmer friendly.
@@WyMustIGo I thought you said he said it sucks, which he didn't say, so you started off with a lie. Not a good thing if you want to talk and also have credibility later. It doesn't matter if you are a grandpa, age doesn't equal knowledge. If you know so much you could actually say something I guess, but I assume you default to lying so not sure I want to hear ya.
You are a Fucking genius... I've watched loads of these videos now and I am crying with laughter each time. Keep doing what you're doing I haven't laughed this much since I was in high school. Just totally hilarious keep them coming
You have said "No camera controller" but the camera seems like following when a player jumps. Also player jumps which means there's a player controller. Or are you just pushing down the ground? I'm confused a bit.
I'm learning game dev with unity for a couple of months now. I like the possibility to use more than just 2 languages (in Godot). Mb I am going to change engines. And btw. Thx for the video. Keep it up!
I never felt comfortable with Unity even when it was almost free. But I have a good feeling about Godot. I could try many different things. Thanks community.
Awesome video ! Sorry for the very random question, but what font do you use in the intro/chapters clips ? It looks very clean and exactly what I'm looking for
I think that an exercise like this one can be beneficial, specializing in one workflow, but occasionally taking a tour in another workflow to see what it's like. For instance, French class in high school was mostly useful for me by giving me something to compare English to; I didn't take enough French to gain any kind of proficiency, I don't speak French, but it gave me some context to compare English rules to. I bet a Unity dev who builds a simple little project like this in Godot will come away with some useful insights about Unity, and vice versa for Godot devs who try out Unity.
Wonderful video and I really like the simplicity of your solution to implement your first Godot game! A bit bummed about your decision to not move but perhaps sometimes in future.
Indeed one of the things that can be a bit confusing at first is that a game level in Godot is exactly the same thing as a game object or anything else = everything in Godot whatever it is is either a scene or individual nodes.
@@EnderElohim TBH since i mostly want to make games that will work on as any computers as possible, Unreal isn't an option (like really, never saw an Unreal game that can run on my current computer)
I'd say that slowly learning Godot is a good idea, but it's not necessary to switch completely right here and now. It's not like Unity is unusable now.
@@notanenglishperson9865 Oh my bad. It seems like I did actually implement the camera follow system (and forgot to remove it - it wasn't intentional to be honest). From what I remember, I think I just attached the camera as a child of the player scene and enabled "smoothing". I actually no longer have the project files (I reset my PC without making a backup...). But again, even with the camera follow system, the player doesn't actually go forward as I addressed in the video.
The best way to switch engines it's by GRADUALLY doing so. Like, if you have an unfinished game that you can't afford to port to Godot, finish the games first, then, you can switch to godot Edit: Haven't noticed that this video was uploaded in 2022
I used to use Unity but it just won't work for me when I switched to Linux so I made the jump to Godot. Been loving it, I feel like I am actually learning something for once.
ill still pronounce it as Godot rhyming with Robot, because the icon looks like a Robot. makes a lot of sense to me. ill start calling it guhdoh, when people start calling robot as ruhboh.
It makes more sense to you because you are uneducated in European literature. It's ok, noone cares how you pronounce it. You can call it the "green robo engineee" because you like green better than blue and we will still love you.
@@zigrakudo4092 I haven't educated you, just pointed out where your reasoning for the pronounciation might stem from. Europe includes 44 countries most of which have their own language and pronounciations of words so I can't provide you with a definite answer. Where I currently live people pronounce "robot" kinda like "roaboat" but with shorter vowels.
@@terryriley6410 notrly. Your comment just hits me the wrong way. Using terms like "uneducated" and using the green vs blue analogy. Sir/maam, not knowing european literature is not the same as being insistently idiotic. Most people know blue is blue, but not most people know european literature, europeans included. The first line of your first comment was a good point, but what followed was offensive. If that was your intention, congrats you succeeded. Well, that's all i have left to say. Have a good day!
@@zigrakudo4092 I did mean to be a bit offensive but only playfully, after all it really doesn't matter how you say "Godot". Sorry if it came off as anything more serious. However, Samuel Beckett who wrote the play was a cool dude imo, so maybe I'm a bit hurt if someone ignores or misses this rare occasion (in the software space at least) to have a chance to remember him and his work, and instead focuses on the robot logo which is pretty much the only part I don't like about this engine. So you see, your comment is like a personal attack on me. :) To my defense I didn't mean the color analogy as "being so idiotic you don't know which colors are which" more like "since you like green better you are just gonna willfully ignore the blueness of something". As a interesting sidenote, distinguishing blue from green might not be that far from being educated in certain cultures. For example the ancient Greek had no word for blue, and apparently many ancient civilizations lacked a word for it as well. Then there is Japan where green is traditionally treated as a shade of blue, then some tribes can have many separate words for all sorts of shades of green but few or none for other colors. In this sense colors (or at least the concepts of them) are also a question of locations, cultures and education.
@@terryriley6410 But Godot is, like Unity, written in C++ and it is hard to interact efficiently with the engine core. Stride is C# from tip to toe so it is one homogenous technology. This is an enormous advantage compared to both Unity and Godot. Unless you are not a coder and exclusively use the engine UI, of course.
@@tonfilm To each his own. Personally I don't want to touch c# ever again let alone use an engine that was built entirely on it. However I didn't find efficiency to be a big problem for most scripting needs and if something really needs a performance boost in Godot you can always write c++ that can run circles around c# (given you know how to write optimized c++). What scripting needs more imo is efficiency of writing the scripts themselves. I found scripting in gdscript to be way a faster and smoother experience than in c# (which I did for unity, might be better in Stride idk) because the gdscript language is built for this single purpose and engine specifically whereas c# tries to be a general programming language with a ton of bloat and unnecessary typing.
Godot 4b dropped with support for .NET core 6. The API is very well documented. I don't see me every go back to Unity even though I spent a fair amount on Unity assets. I am a full convert.
Godot is fine if you want to make a really simplistic game, probably. However even though I'm a 1-man team, there are too many technologies I use in Unity that Godot will never offer. I would never make the blanket statement however that a Unity developer should "switch" to Godot. If a Unity developer said "should I use Godot for... this simplistic platformer?" then I might say, sure.
What technologies does Unity offer that Godot does not? I'm curious because I'm in the process of choosing between Unity and Godot and I would love to hear what you find to be a limitation in the system! I currently like Godot more, but that's just because I like the fact that Godot is very stable when it comes to updates.
you can do any game you want in every engine you choose, the statement you made can be applied to every engine, Unreal has "technologies" that Unity will never offer, and o Godot also has things that Unity can't offer neither. But what you say about godot being an engine for simplistic games is not true, it's just that Unity and Unreal has a lot more years in their life and accumulated a more experience user base. Give the time, godot (with it's version 4 or whatever) will be more used and you'll see more and more games with AA or AAA techniques, architecture and assets.
@@rustyshackleford634 I do not agree with this comment, the only limitation of godot is slower 3d and a bit slower phyics which should never be a problem unless you do something pretty silly to get the engine to the point of slowing down. Also godot has an infinite amount of tools with its community made plugins!
@@nemene8585 The godot 3d has many limitations are constant crashes in its engine, I used it myself, and a headache, has no graphics tools, has a bad particle system, it is almost impossible to edit animations without receiving faults, import of shameful models, if you want something like 3d drive that is good equal to 3d drive, it is much better to use step 4 than godot 3d
@@rustyshackleford634 Godot is currently less than ideal for 3D games. Great if you're working in a 2D space, but for 3D Unity blows it out of the water by comparison. Hopefully Godot 4 will offer some major improvements in that area, but at present it's a lot slower than other engines. The upgrade to Vulkan should help that along though.
Always good to Check Out Others Tools from time to time... But yes in the end its all Personal Interests, Workflow, preferences and ultimativly the Skill Not the engine that makes a Game good or Not...
Well said, although good skills paired with good tools often result in better products and better experience making them. Of course you can continue building castles from a pile of turd, if you are a true artist it will look good none the less but it is better to use bricks or concrete or something that doesn't stink imo.
Switching to Godot is safe unless you want to have your game on consoles. Then you're screwed. You have to hire people to port your game, which can end up fairly expensive.
"Switching to another engine won't make me a better developer" Couldn't say it better, i don't get why people get so worked on the idea of which engine to use.. it's simple, learning an engine isn't hard when you have the knowledge of another's, so don't worry much, plus, transfering entire games to another engine proved to be 10× faster than developing from scratch so it won't be a disaster if a multimillion company like unity decided they don't want money no more and ditched it.
@@breh2716 I meant, if unity and godot are as good, why ever use unity in the first place (which is proprietary). Unless unity is significantly better for some task?
@@12kenbutsuri Ah, Unity (at the meantime) is really better in my oppinion, due to the lack of tutorials for godot, it makes the beginner's experience much worse.. The way i see it, a company working for money is safer than a company that is not, money is the motiv and the lock that keeps the product sustainable and improving.
The idea that Godot's Node system is inherently set up to be building blocks, is so much better than Unity. The fact that a blank node doesn't have a Transform, makes for a potentially more efficient use of active objects in the scene.
I have been developing on Godot for 2 years and now 2 years on Unity, I am developing NFT MOBA with my team and I can say that Godot still has a lot of development before it will be on equal terms with Unity. I consider the arguments against the Unity Engine in the video to be unfounded hysteria. Unity's only competitor is Unreal, and they both have advantages and disadvantages over each other. You can develop the same prototype or finished game on Unity ten times faster! At the same time, they will not differ visually and in quality. Compare Genshin Impact (Unity) and Tower Of Fantasy (Unreal). Optimization, skills, art, effects, all of this will have a much greater impact on the game the difference between these engines. In 99% of cases, for those who watch this video, Unity will be the best choice.
If you want to use C# then Unity is the best choice in my opinion. Godot has a lot less learning material than Unity and only ~20% of it is in C#. Pair that with the majority of good beginner tutorials for both engines being for 2D and the learning curve is getting steep if you want to develop 3D games in C# in Godot. People also mostly assume that you're using GDScript, so they don't tag their videos etc. with GDScript. You'll waste a lot of time checking out tutorials only to find that they are in the wrong language for you. It's too bad. I would have much preferred to use Godot but despite the engine being good the community is too small to support the different languages for beginners. This is especially true as new versions come out and plugins and videos become outdated. Even their own docs are slow to get updated.
I used Unity in the past and now use Godot and I appreciate your video a lot. Basically everything you went through I too ran into, ultimately I made the switch and feel better for it but Engines are more preference based. Hope you enjoyed Godot and remember it's always here if you wanna try again!
He probably will when Godot 4 gets out and stable! Let's wait and see ;)
6:52 this is true for Node, but Node2D and Node3D do hold position information. The only difference between Position2D and Node2D is that Position2D is visible in the editor viewport
Isn't Node3D actually called Spatial?
@@Poldovico In Godot 3 yes, in Godot 4 it was renamed Node3D
@@LightOffArchives Oh! I like that change!
@@Poldovico more Uniform huh,i like it
Fun fact about the name:
It’s a MAJOR split and a major topic of debate with the community using both pronunciations interchangeably.
The developers and founders themselves don’t help because they too apparently interchange the pronunciation.
For me, I will always say Guh-doh because it’s like the Waiting for Godot play, but the strongest arguments I’ve seen for the latter is that the founder isn’t actually French, and the logo is a literal robot head, so it sounds more like robot.
But it’s still constantly debated
Imagine not pronouncing every letter
- this comment has been made by the "Go-dot" team
People being bothered by pronunciation like this are the kinds of people who hunt you down in the grocery store for "stealing their parking spot".
@@swishfish8858 there's 2 types of people :
"You stole my parking spot!"
"You stole my parking spo !"
@@Dark_Peace 🤣🤣
They actually added info on the website saying they officially recommend saying it like "GOD-oh"
This video aged well.
Just wanted to make a note that the build-in editor does have full autocomplete for GDScript and is (in my opinion) quite good! It just doesn't have built-in support for the other languages as that would be pretty out of scope considering that most would prefer an external editor anyway since they are known languages with great tooling already available
It doesn't have a complete autocomplete, many functions never show up, lol, that is why i quit it
You could also develop in C#, by using the official Godot plugin by JetBrains for Rider and enable network debugger in the Godot project's settings. That's what I've been doing, which gives you access to the entire C# ecosystem of packages.
@@Prajwal____ lol, imagine needing autocomplete so bad you quit if it's not quite there. btw godot 4 even generates documentation for your own code like what?? You can now learn about the snippets you copy paste your game together from.
5:40 the actual game does exactly this though, don't know why you eluded to it being different. the game would have several issues past a certain score if the camera was genuinely scrolling several thousand units.
even games like The Outer Wilds and No Man's Sky implement player oriented coordinate centering in some sort of fashion. any time you use a float with a value larger than 32k ish, calculation precision is going to plumment and collisions are going to start to bug.
The Outer Wilds always has the player at 0, 0 in the world. No Man's Sky chunk bases everything and makes target distant objects either disappear or show a fake (planets are actually a giant floating sphere and not the actual world object). then on the planet surfaces, it chunk splits them, so every time the player or object crosses a chunk boundary, its float coordinate resets but an integer value representing chunk number changes. same methodology for changing star systems and what have you
For this reason, Godot has local and global coordinates.
@@BrunodeSouzaLino Local vs. global coordinates don't inherently solve this, you can still run into floating point draw issues if you take something far enough unless you organize the game correctly, which as far as I know requires that you actively move the world in relation to the player still, as long as you don't use absolute positions to set the player's position (which in a game with infinite terrain is not usually a smart idea anyway) you will never notice the difference.
I’ve been around since 3.0, back when the main complaint was about the documentation. So happy to see they’re better for newbies :) nice video!
That's true - the first thing that you would like to do as Unity dev starting with Godot is to use c# and this is a mistake IMO.
I mean c# is good if you need fast calculations, or maybe you want to use Linq or MySQL, etc. But in most cases, Gdscript is a way to go.
The node system at first seems strange but later you will realize the true power of this system where everything is a node. Your code will be well organized by design.
And is so reusable. You will start making separate folders for every node tree (scene), where everything needed for this scene will be included in this folder, like all nodes, sprites, scripts, etc.
Then all you have to do, to reuse this in another project is just copy-paste this folder and everything will work.
Not to mention the size of the projects. 1000 Godot projects (before exporting modules) will take less space than one Unity project.
In 2D Godot is already better than Unity. For 3D we have to wait for Godot 4 with Vulcan and for some missing features like a good modern terrain generator plugin.
And yes... everything is free and open source, including all assets in the Godot asset (plugins) library so you can learn how exactly they were made.
Let's hope that after Godot 4 there will be more 3D tutorials because as for now Godot is lacking here.
Unity is great, used it for years, but year after year it's getting worse. New features are added when basics are still missing or are buggy and nobody cares.
Can you imagine that you can have dictionaries in the inspector in Godot? xD Or working HighLevel multiplayer server-client solutions out of the box?
The last moves from Unity are shady and Unity is going in a strange direction. And remember to monetize as a Unity dev, otherwise, you are f***g id**t according to Unity's CEO (from EA)
why not use c#?
@@woopslap because GDscript is built specifically for godot which makes it a lot simpler and easy to write
@@woopslap I didn't say that you can't or should not. I wanted to say that nodes system in Godot is suited for duck-typing language like gdscript and c# is adding complexity that Godot doesn't need with the nodes approach. But sure you can use c#, I'm doing this myself from time to time, to use Linq or MySQL libraries for example. In gdscript you don't need abstract classes or interfaces as this is duck-typing language so you just call the void and even if this void doesn't exist this will not generate an error so gdscript doesn't need this. But as I said, you can for sure use c# if you want but is not needed really in most cases.
Didn't Unity start with its own Unityscript then it got scrapped in favor of c#. What if that happens with Gdscript then it's a waste of time learning.
@@woopslap DogTurtle is right, but I can give a more concrete example. Right now, I'm implementing in Godot an infinite 2d world map that can be scrolled in real time, at first based on opensimplexnoise. I started my code in shaders, then I ported it in GDScript. When it was finally working, with acceptable performance (there was an initial big drop), I started to port my gdscript to C# (so I can use other noise generators), and it's way more complicated and filled with boilerplate than in GDScript. Especially, all operations with vectors are a chore. In GDScript, you can add and multiply vectors with scalars and others vectors just like that. In C#, either you must write your own little vector toolbox or you must treat the vector like an array and iterate on it. Nodes aren't that easy to access, neither are their attributes. When I access to a shader material parameter, the code is way more complicated in C# than in GDScript. Another thing is the editor plus debugger. I use VSCode with Godot Mono, but it's still unstable. Right now, I lost autocompletion and inline debug without understanding why. With GDScript, the editor is inside Godot, including the debugger and a benchmark profiler, and it all works out of the box. No installation needed, no special version of .net needed, no incompatibility whatsoever. It just works. And those are reasons why I also think the GDScript would be a much better starting point for a beginner to discover and learn Godot.
Great to see more people checking Godot, it's quite a capable game engine and it'll only get better! Godot 4 beta is around the corner already.
I appreciate the learning value of this video, and the transitions being fairly smooth.
My only points to bring to attention, and probably my personal opinion on it, is that this video asks a question in its thumbnail: "Should You Switch?" By the end of the video that question was not answered at all, partly because you didn't delve further into the Godot engine than the paper-thin surface of a 2D, non-rng generation tiles, and partly because half of it felt like it was trying to be a tutorial when it's not geared up to be one.
Individually the info in the video is good and not saying the exploration you had was bad or pointless, etc, but it's basically what's in the packet is not what the packet said. I understand your title is different to the thumbnail, but many people would click this video for the purpose of the answering the question asked in the thumbnail and, like myself, be disappointed.
Essentially click-bait.
I actually prefer Godot now. Unity became very bloated over time.
They are finally trying to fix this, but it will take years to turn it back into a lean engine like it was back Unity 3.
Godot really is the equivalent of Blender now. It is growing faster than the competition, but it still has some catching up to do.
Using Linux and Unity as your main engine? you sir is a warrior
Man was ahead of his time
I've started using Godot even for things like building forms or little apps (like DnD digital tabletop character sheets) because it's so lightweight and simple. I still sometimes wonder some basic things like which node in my game is the first event consumer, but so far everything's working fine.
(I definitely don’t know nothing about either godot or unity, but the video was still fun to watch)
I tried unity a few years ago, it was so messy and confusing I gave up. Recently I started studying godot and I didn't have this problem, and ended up learning well enough to make 2D games.
Software development isn't for you.
@@WyMustIGo I'm already a software developer. I think it's not for you since you think it's just one small subject.
@@12kenbutsuri You can't even develop a cold, kid.
@@WyMustIGo okay boomer
@@WyMustIGo lol why are you trolling 😂
5:53 for 2D games this is actually really easy. Like, stupidly easy. Like you'd think it's cheating easy. What you do, is you add the camera node as a child of the player node, set the camera to current, and then in the camera options there is a dropdown called smoothing. That can be enabled and you can change the speed and this automatically does a basic following effect where the camera lags behind it's new position slightly.
For a game like this where you have the player staying still, you could fake the effect by using the camera offset values, they don't change the cameras position but do offset the camera, so you can have it fake being lagged behind without much worry.
guys it gets worse, the time to switch to Godot was a year ago when this was posted
Great video. You picked up the basics of Godot Engine very quickly. It's probably better for most people to use GDScript for productivity reasons and code completion, and it is easy to learn: something like LUA or simplified Python.
Using GDScript or another language like C# or C++ changes anything about the game's performance, or does it not matter?
@@alcidesneto6415 The most important thing with game dev is to get a MVP (minimum viable product), something that basically works. Then think about ways to optimize it if necessary. So start with GDScript which calls the built in C++ code anyway.
@@GDScriptDude The issue there is you're basically re-learning a new language from scratch. If you've already got significant experience in C# you want to get in and actually develop something rather than spend a while fiddling with a system with a totally different syntax. It's not so bad if you're experienced with Python, since they share a lot of similarities, but for people without that experience it's like starting from the ground up. That can make things even harder since you're stuck figuring out if its your code that's the issue, or the way it's implemented in Godot.
@@Crystan I think his choice fits in well with the "so you're moving to Godot...". If it was a "so you're starting with..." the choice would have been different because there would be little baggage. Especially important with the "so you're escaping Unity..." push going on by the community.
OOOH I thought that was odd, because I use Godot with GDScript (Python is my "native" language, I learned to program in Python, and GDScript is like Python with a sexy Australian accent or something so) and it does offer code completion there. I guess it doesn't in C#?
Any chance you could make tutorials with your way of explanation? I have just realized that to understand things, I need to: see them, read them, hear them - so your graphical as well as text and voice explanation of the structure of scenes and nodes is very easy to understand and remember for me, I will watch this video over and over again to understand that a scene is a pack of nodes which together as a whole create an object, and to make a game you make scenes with packed contents, aka nodes. (and scripts and etc.)
I use Godot for my project because it's open source and friendly to all levels of all experiences. Yeah, it has some drawbacks but it's overall good to me and the community is friendly as well. :D
Even though you had that whole disclaimer, i think this is a really nice video about godot :)👍
the only thing i needed to know about godot was the scene/objects system that is the nodes.
this is the only video that explains the concept properly.
thanks!
Also just about every node has a position that can be used by looking at its position. You could also use the Godot animate player, you can use it to animate just about any property on the nodes. Something I don't think many of the other game engines can do, including unity and unreal.
Wow thanks, no one ever explained Godot's Node system in a way that I actually understood until now. Nice job!
Also ya I'm the same. I'm already working on a game in Unity, so even though Godot interests me idk for sure if I wanna make the change or not lol
5:32 Regardless, the infinite terrain generation system isn’t the approach you’d want to take, at least with Unity. Once you get far enough from the origin, the position of the objects will begin to suffer from noticeable rounding imprecisions and it’ll look kinda glitchy. You’ll have experienced this if you ever saw those videos of people launching themselves on the go-karts in VRChat around 2017 if anyone remembers those
Thanks for sharing your experience diving into Godot. I've not tried it yet, I use Unity too. It's neat to hear how this engine works differently and seeing your journey.
You had a nice childhood without having to learn "Waiting for Godot". I envy you.
godot 4 : hold my beer
godot 4: are you sure about that
Hey man, nice video, where did you get the sound effects, like at 03:16? You rock!
I, no joke, sometimes turn off my internet to play the dino game for a hour.
This channel is going places
I still prefer Unity because I'm very much a manual guy and like to code everything myself (Whereas Godot does a lot for you). But I like what you said at the end. Switching engines won't make you a AAA Game Developer. I find that everyone that shuns you for the engine you use are normally pretty bad at game dev in any case and get hung up on technicalities instead of learning how to make something good
What are you saying? Both Godot and Unity do a lot for you. They are called game engines for a reason. Coding everthing yourself would mean you pick up SDL or something and implement things you need from scratch.
Can you give an example of what you do manually in Unity that Godot does for you instead? Personally I found Unity to be more constraining in what way I needed to design my code whereas Godot feels much more open ended and programmer friendly.
@@terryriley6410 He is saying Godot sucks, and he is right.
@@WyMustIGo You're saying you have nothing to say yet you still talk, fascinating.
@@terryriley6410 I said it sucks, and I know much more than you ever will son.
@@WyMustIGo I thought you said he said it sucks, which he didn't say, so you started off with a lie. Not a good thing if you want to talk and also have credibility later.
It doesn't matter if you are a grandpa, age doesn't equal knowledge. If you know so much you could actually say something I guess, but I assume you default to lying so not sure I want to hear ya.
How do you have this many subs? You deserve way more!
You are a Fucking genius... I've watched loads of these videos now and I am crying with laughter each time. Keep doing what you're doing I haven't laughed this much since I was in high school. Just totally hilarious keep them coming
You have said "No camera controller" but the camera seems like following when a player jumps. Also player jumps which means there's a player controller. Or are you just pushing down the ground? I'm confused a bit.
He probably added a camera2D to the player and wrote a simple jump script for the player
What font did you use for those title cards? Really like it.
The font is called Party Confetti
Few days for that? Sounds like 1hr tutorial project.
I'm learning game dev with unity for a couple of months now.
I like the possibility to use more than just 2 languages (in Godot). Mb I am going to change engines.
And btw. Thx for the video. Keep it up!
0:56 it is "go dot"
I never felt comfortable with Unity even when it was almost free. But I have a good feeling about Godot. I could try many different things. Thanks community.
Awesome video ! Sorry for the very random question, but what font do you use in the intro/chapters clips ? It looks very clean and exactly what I'm looking for
Thanks, the font is called Party Confetti.
That last point is what a lot of new devs(myself included). Pick and engine and learn it. One specific one won't just make you successful
I think that an exercise like this one can be beneficial, specializing in one workflow, but occasionally taking a tour in another workflow to see what it's like.
For instance, French class in high school was mostly useful for me by giving me something to compare English to; I didn't take enough French to gain any kind of proficiency, I don't speak French, but it gave me some context to compare English rules to.
I bet a Unity dev who builds a simple little project like this in Godot will come away with some useful insights about Unity, and vice versa for Godot devs who try out Unity.
Nice video, it maybe out of topic but I really love the font you used in your video at the beginning. Can you please tell me the name of that font?
Thanks, the font is called Party Confetti.
Wonderful video and I really like the simplicity of your solution to implement your first Godot game! A bit bummed about your decision to not move but perhaps sometimes in future.
Indeed one of the things that can be a bit confusing at first is that a game level in Godot is exactly the same thing as a game object or anything else = everything in Godot whatever it is is either a scene or individual nodes.
I will never unsee Go-Dot. Damn you...
Wow you really called their sketchy business decisions early.
Fyi to get the camera to follow the player you simply attach the camera to the player node. Then you have your camera follow system
Appreciate your honesty. What do you think about UE5?
I haven’t tried UE5 intensively so I can’t say much about the workflow, but regarding its features, I’m definitely impressed with Lumen and Nanite.
@@semikoder as a unity game developer i can safely say if i stop unity it would be for unreal engine 5. Damn 5 is super good
@@EnderElohim Really pushes your GPU to its limit though, made my normally cool system overheat!
@@SomeRandomPiggo i have laptop yet i saw no problem but my experience with ue5 is limited. I have nvidia rtx 2060
@@EnderElohim TBH since i mostly want to make games that will work on as any computers as possible, Unreal isn't an option (like really, never saw an Unreal game that can run on my current computer)
Hey, i saw you use linux. Which video editor do you use?
I actually edited all of my videos on Windows. I use Sony Vegas, but I recently switched to Final Cut Pro
I'd say that slowly learning Godot is a good idea, but it's not necessary to switch completely right here and now. It's not like Unity is unusable now.
- which godot is famous?
- gal godot.
aged well
Can you share your source code somewhere? I'm particularly interested, how did you manage to make that bouncy camera
The camera is static (does not move at all). It's only the player that goes up and down.
@@notanenglishperson9865 Oh my bad. It seems like I did actually implement the camera follow system (and forgot to remove it - it wasn't intentional to be honest). From what I remember, I think I just attached the camera as a child of the player scene and enabled "smoothing". I actually no longer have the project files (I reset my PC without making a backup...). But again, even with the camera follow system, the player doesn't actually go forward as I addressed in the video.
You are so underatted
The best way to switch engines it's by GRADUALLY doing so.
Like, if you have an unfinished game that you can't afford to port to Godot, finish the games first, then, you can switch to godot
Edit: Haven't noticed that this video was uploaded in 2022
I used to use Unity but it just won't work for me when I switched to Linux so I made the jump to Godot. Been loving it, I feel like I am actually learning something for once.
where a have to work on.
ill still pronounce it as Godot rhyming with Robot, because the icon looks like a Robot. makes a lot of sense to me. ill start calling it guhdoh, when people start calling robot as ruhboh.
It makes more sense to you because you are uneducated in European literature. It's ok, noone cares how you pronounce it. You can call it the "green robo engineee" because you like green better than blue and we will still love you.
@@terryriley6410 aah, so you do pronounce it ruhboh in europe? i didnt know. thanks for educating me.
@@zigrakudo4092 I haven't educated you, just pointed out where your reasoning for the pronounciation might stem from. Europe includes 44 countries most of which have their own language and pronounciations of words so I can't provide you with a definite answer. Where I currently live people pronounce "robot" kinda like "roaboat" but with shorter vowels.
@@terryriley6410 notrly. Your comment just hits me the wrong way. Using terms like "uneducated" and using the green vs blue analogy. Sir/maam, not knowing european literature is not the same as being insistently idiotic. Most people know blue is blue, but not most people know european literature, europeans included. The first line of your first comment was a good point, but what followed was offensive. If that was your intention, congrats you succeeded.
Well, that's all i have left to say. Have a good day!
@@zigrakudo4092 I did mean to be a bit offensive but only playfully, after all it really doesn't matter how you say "Godot". Sorry if it came off as anything more serious.
However, Samuel Beckett who wrote the play was a cool dude imo, so maybe I'm a bit hurt if someone ignores or misses this rare occasion (in the software space at least) to have a chance to remember him and his work, and instead focuses on the robot logo which is pretty much the only part I don't like about this engine. So you see, your comment is like a personal attack on me. :)
To my defense I didn't mean the color analogy as "being so idiotic you don't know which colors are which" more like "since you like green better you are just gonna willfully ignore the blueness of something".
As a interesting sidenote, distinguishing blue from green might not be that far from being educated in certain cultures. For example the ancient Greek had no word for blue, and apparently many ancient civilizations lacked a word for it as well. Then there is Japan where green is traditionally treated as a shade of blue, then some tribes can have many separate words for all sorts of shades of green but few or none for other colors. In this sense colors (or at least the concepts of them) are also a question of locations, cultures and education.
I'll be back for more Godot content!
Great video! I will try godot as well 😁
If you choose GDscript the editor will actually help you 2:58
If you switch, then to Stride it is much more similar to Unity and also free and open source.
Nah, Godot is better precisely because it is less similar to Unity. Everyone knows this who made the switch.
@@terryriley6410 But Godot is, like Unity, written in C++ and it is hard to interact efficiently with the engine core. Stride is C# from tip to toe so it is one homogenous technology. This is an enormous advantage compared to both Unity and Godot. Unless you are not a coder and exclusively use the engine UI, of course.
@@tonfilm To each his own. Personally I don't want to touch c# ever again let alone use an engine that was built entirely on it.
However I didn't find efficiency to be a big problem for most scripting needs and if something really needs a performance boost in Godot you can always write c++ that can run circles around c# (given you know how to write optimized c++).
What scripting needs more imo is efficiency of writing the scripts themselves. I found scripting in gdscript to be way a faster and smoother experience than in c# (which I did for unity, might be better in Stride idk) because the gdscript language is built for this single purpose and engine specifically whereas c# tries to be a general programming language with a ton of bloat and unnecessary typing.
@@rytif Could you point to something specific that makes the source a "hellhole" in your opinion?
Amazing video
Godot 4b dropped with support for .NET core 6. The API is very well documented. I don't see me every go back to Unity even though I spent a fair amount on Unity assets. I am a full convert.
What CPU you gonna run Godot on?
I was using i7-8700 in this video.
@@semikoder good luck in trying to buy i7 in the Future.
Godot is fine if you want to make a really simplistic game, probably. However even though I'm a 1-man team, there are too many technologies I use in Unity that Godot will never offer. I would never make the blanket statement however that a Unity developer should "switch" to Godot. If a Unity developer said "should I use Godot for... this simplistic platformer?" then I might say, sure.
What technologies does Unity offer that Godot does not? I'm curious because I'm in the process of choosing between Unity and Godot and I would love to hear what you find to be a limitation in the system! I currently like Godot more, but that's just because I like the fact that Godot is very stable when it comes to updates.
you can do any game you want in every engine you choose, the statement you made can be applied to every engine, Unreal has "technologies" that Unity will never offer, and o Godot also has things that Unity can't offer neither. But what you say about godot being an engine for simplistic games is not true, it's just that Unity and Unreal has a lot more years in their life and accumulated a more experience user base. Give the time, godot (with it's version 4 or whatever) will be more used and you'll see more and more games with AA or AAA techniques, architecture and assets.
@@rustyshackleford634 I do not agree with this comment, the only limitation of godot is slower 3d and a bit slower phyics which should never be a problem unless you do something pretty silly to get the engine to the point of slowing down. Also godot has an infinite amount of tools with its community made plugins!
@@nemene8585 The godot 3d has many limitations are constant crashes in its engine, I used it myself, and a headache, has no graphics tools, has a bad particle system, it is almost impossible to edit animations without receiving faults, import of shameful models, if you want something like 3d drive that is good equal to 3d drive, it is much better to use step 4 than godot 3d
@@rustyshackleford634 Godot is currently less than ideal for 3D games. Great if you're working in a 2D space, but for 3D Unity blows it out of the water by comparison. Hopefully Godot 4 will offer some major improvements in that area, but at present it's a lot slower than other engines. The upgrade to Vulkan should help that along though.
Always good to Check Out Others Tools from time to time... But yes in the end its all Personal Interests, Workflow, preferences and ultimativly the Skill Not the engine that makes a Game good or Not...
Well said, although good skills paired with good tools often result in better products and better experience making them. Of course you can continue building castles from a pile of turd, if you are a true artist it will look good none the less but it is better to use bricks or concrete or something that doesn't stink imo.
That's what I'm doing now I wanted to try Godot because everyone says it is easy to make games learning GD script not that hard pretty much python
I dunno if there's anything on Godot that can compare to Unity's Burst Job system which I love.
Godot has GDNative so you can bring your own "burst job" system. I built one in Rust for example
Phaser FTW
i've been using chrome for a couple of years and i never saw the game
You seem to be pretty new to talk about it
I am using Godot over Unity. Its much cleaner and much more structured and all feels more stable and in control.
I switched to Godot because I wanted to spend more time debugging games code and less time debugging the unity editor.
I also thought that it was pronounced go-dot lmao
The more you dig the more you realize that Godot is more powerful than most people think
Switching to Godot is safe unless you want to have your game on consoles. Then you're screwed. You have to hire people to port your game, which can end up fairly expensive.
tbh after reading that title, I thought you were actually on the Unity team
if he knows whats good for him, he wuld be.
"Switching to another engine won't make me a better developer"
Couldn't say it better, i don't get why people get so worked on the idea of which engine to use.. it's simple, learning an engine isn't hard when you have the knowledge of another's, so don't worry much, plus, transfering entire games to another engine proved to be 10× faster than developing from scratch so it won't be a disaster if a multimillion company like unity decided they don't want money no more and ditched it.
But if you start out a 2D game from scratch, why would anyone use a proprietary game engine, unless it is mind blowingly better?
@@12kenbutsuri i don't get what you mean here, why use a game engine at all or a specefic one?
@@breh2716 I meant, if unity and godot are as good, why ever use unity in the first place (which is proprietary). Unless unity is significantly better for some task?
@@12kenbutsuri Ah, Unity (at the meantime) is really better in my oppinion, due to the lack of tutorials for godot, it makes the beginner's experience much worse..
The way i see it, a company working for money is safer than a company that is not, money is the motiv and the lock that keeps the product sustainable and improving.
@@breh2716 I see
i thought it was go dot at first as well
now you should
SPOILER: Should you switch? - No
The idea that Godot's Node system is inherently set up to be building blocks, is so much better than Unity. The fact that a blank node doesn't have a Transform, makes for a potentially more efficient use of active objects in the scene.
I kind of know how to code 🤣
Thats when I hit that sub-button. You are very likeable :)
You committed the ultimate sin by changing from Dark mode to "WTF my eyes!" mode.
You’re the best!
Ahora Unity acaba de invitarnos, no muy gentilmente, a irnos a Godot.
re/ the Nodes system - as a wise dumb guy once put it, everything small is just a small version of something big
I have been developing on Godot for 2 years and now 2 years on Unity, I am developing NFT MOBA with my team and I can say that Godot still has a lot of development before it will be on equal terms with Unity. I consider the arguments against the Unity Engine in the video to be unfounded hysteria. Unity's only competitor is Unreal, and they both have advantages and disadvantages over each other. You can develop the same prototype or finished game on Unity ten times faster! At the same time, they will not differ visually and in quality. Compare Genshin Impact (Unity) and Tower Of Fantasy (Unreal). Optimization, skills, art, effects, all of this will have a much greater impact on the game the difference between these engines. In 99% of cases, for those who watch this video, Unity will be the best choice.
Good lord invert the black and white >
7:08 my eyes, my fucking eyes.
If you want to use C# then Unity is the best choice in my opinion. Godot has a lot less learning material than Unity and only ~20% of it is in C#. Pair that with the majority of good beginner tutorials for both engines being for 2D and the learning curve is getting steep if you want to develop 3D games in C# in Godot. People also mostly assume that you're using GDScript, so they don't tag their videos etc. with GDScript. You'll waste a lot of time checking out tutorials only to find that they are in the wrong language for you.
It's too bad. I would have much preferred to use Godot but despite the engine being good the community is too small to support the different languages for beginners. This is especially true as new versions come out and plugins and videos become outdated. Even their own docs are slow to get updated.
Nice man ty
Still gonna use unity to make games cuz I'm more familiar with it and comfortable with it but it seems Godot is a great engine too
Yeah with unity I feel like I’m on a sinking ship, looking up at a cruise full of everyone who has switched to Godot but I’m too lazy to move 😂
i though he was a developer at unity.. still a great video
I was and will pronounce it as Go-Dot for the rest of my life
Cool, we at the Godot community still love you even if you ignore the greats of European literature.
sir, that would be 6,67
if i have to change from unity to a other game engine i will go for unreal