Since more people are seeing this video as a result of Unity's recent pricing change, I would like to emphasize that these are my opinions on the engine pre-4.0 update which addresses and fixes a large majority of issues I had with the engine, and adds a number of valuable features. Second, many of my concerns or wishes were also addressed by more experienced users in the comments, and were a result of my lack of experience. I hope the comments can be a good resource for anyone struggling with the same things I was. Since this video released, I have continued to use Godot. I've made 3D games, I've made 2D games, I've made simple graphics, I've made more detailed graphics. I've made VR games. I have yet to try a game idea that I felt could not be achieved with Godot.
I am cackling irl at the fact that so many game makers changed engines because of the controversy that this video reached the youtube algorithm en masse hahahahah mannn
I am really concerned about the 3d capabilities of godot for making my dream project. I am still trying to wake up from the trauma that unity gave me and really thinking of shifting to unreal engine 5 but I am still considering godot as an option just that I doubt I can achieve the level of quality with godot's power so far. I am talking about Genshin level quality or something similar (I am talking about my dream project so don't think I am being arrogant and thinking that I can create something that). So I don't know, I heard that Godot's lighting system is not that great and since godot is mainly used for 2d games. I just can't make up my mind and will probably go for unreal engine.
I think Godot being 'durable' instead of 'fragile' is the thing that allowed me to actually dive into game development. The node system is just something that clicks with my brain, because when it came to other game engines/programming languages I'd struggle just to get buttons working; among other more simple concepts I'd struggle to grasp with. You know the typical problem of following a tutorial and at the end of it learned and understand nothing of what I did. With Godot on the other hand I can follow a tutorial and actually come out the other end with actual knowledge.
@tsary_8561 Brackeys has one out that I've been following and it's really good. Wayyy better than the old stuff imo. I have the same thing with Godot. I even have some prior programming classes under my belt and tooling around with minecraft modding. I've tried several engines and Godot has been the one that makes the most sense to me by far. It's so intuitive and, as someone who used to do graphic design as a hobby, the GUI just makes me so happy.
I love using Godot, because it feels like how I imagined game development would be when I was younger. Everything flows together nicely, and if I need something, I know where to look, and if I want to know what something does, I can easily look at the documentation. Unity however, feels like how I feared game development would be like when I first started. Everything is confusing, there 100 different ways to do x, but only one way actually works properly. Objects have dozens of different values, but you change one and suddenly nothing works. Unreal however, couldn't run on my high end gaming rig from 2010, so despite having a computer that could probably run it now, I've already grown too attached to Godot to even think of jumping ship.
" there 100 different ways to do x, but only one way actually works properly" thats a great point. For me with godot its like "you have 100 different ways to do X but only some are better performance" stuff works but maybe not most efficiently
@@Aereto All of that is so out of context it's not even funny. Don't believe every headline you read, nor what people told you they "read" without reading the article. A lot of click bait and misinformation came out and unless you read the original interview and looked into the company they acquired don't go around talking about stuff you know nothing about. First off, he did in a way diss developers but not in the way you think. If you make a game for art that's fine. But if you are making a game for profit (the key context) and you don't use the tools around for you to monetize the game then yeah your an idiot. (that's the funni tag line "devs are idiots") Unity is natively supporting monetization now. Second, the company they merged with IronSource (didn't buy, no cash traded hands just their stocks turning into unity) Never made malware. They made an install wizard that was open source. Much like how you can make malware with Unity. You could make malware with this (by attaching bloat or malicious products to the install wizard. If you remember like when you download 7 zip and the wizard asks you if you wanna download all this other shit? ) They got flak for what people did with their product. Not anything they did. They no longer support said software and haven't for 5 years now. The only thing they do now is targeted ads and mobile game ad software. This is mostly for the IOS market where if you were to use a 3rd party software the game would have to ask permission on your device to show ads. and yeah, if you were making mobile games for the sole reason of making money, or if your making a game and want to get paid for your work I kind of agree. You should use the tools given to you buy Unity to make that happen. Game development has changed, sure you can release your game on steam, itch.io. Apple store or google play randomly and do no promotion and hope it blows up and by proxy you make money. The old way. Or you can go with the future and get feed back on the way your monetize game while you build it. (More so in the mobile space) Making sure ad's don't interrupt the gameplay loop etc Personally i dislike mobile games and their ads so I won't be using it. But like a lot of advanced software in unity just because I don't want it doesn't mean other people don't.
"All game engines have their own special ways in which they work. Unity has MonoBehaviours. Unreal Engine has Blueprints. GameMaker has a 100 USD a year subscription fee. And Godot has nodes."
@@saverofthewo That's exactly how they get you. It's only 8$ a month but let's say you buy a perpetual license for 99$ that you can keep forever. If you use the software for a year on the subscription model you have already paid as much as you would have on the old model.
It actually blew my mind when instead of having to write a script to make the 2d camera follow the player, I could just make the camera a child node by dragging it underneath. I got all giddy about it lol
It's like how programming languages will first have a compiler in a different language, but then subsequent compilers will be made in the language itself.
There are a couple things about Godot's design I think you should know: 1) Single purpose principle - All nodes do one thing (ie handle themselves), there should be random nodes that only serve to have a script, and that script should only do one thing. 2) Tree Structure - Parents should know their children, but children shouldn't know their parents, otherwise use signals, using an autoload signal connector node is totally fine.
If a child needs to know it's parrent, in the multiple scripts excample, "export(NodePath) var myNodeToManipulate" will work well, you can then use the get_node(myNodeToManipulate) to get the node. This also promotes code reusability.
@@WizzardPowers because your parents are deprecated /j I think it has probably something to do with reusability. If u use signals then you're not relying on where your node is placed but if you reference your parent the node becomes tied to it and can't be used elsewhere as an instance for example. Keeping specificity low is often a good thing.
@@JebacPresretac101 Yeah, this is the approach I tend to use too, since it makes it sooooooo reusable like you said. I would love first class global signal support though!
My favorite thing about open source programs is that it's improved on and worked on by those that use it. They know exactly what users need and want, and the issues that have, because they are them
My personal favorite creators in the Godot community is DevDuck, just makes devlogs but he displays expert use of the engine, an amazing workflow, and an overall nice way to balance work and life
A huge tip if you're moving to godot: Go to the settings>text editor>behavior, and turn off the "Open dominant script on scene change." There's a similar option under the settings>text editor>files menu, DO NOT BE TRICKED. There's also a few other goodies like scrolling past the end of the file.
@@miadietrich7347 Because when this is on, if you have a lot of scenes you're going back and forth between, they'll always be silently clogging up your scripts panel, even when you aren't editing those scripts.
As I'm watching this video, I know you mentioned things will change in godot 4.0, so here's a list of things you mention that I know for a fact have already been changed in godot 4.0 - Physics have been completely rewritten from scratch, so they shouldn't feel nearly as janky - 3D audio and audio in general has been overhauled, so most of the issues/jank there will get much better - Shader compilation has been reworked so that, while performance will still drop a bit while they compile, the engine won't grind to a complete hault waiting for the job to finish - As you said, the options for 3d are already great, but it's getting even better, multiple options global illumination, deferred rendering, etc - Some things with the way ui options are displayed have been changed to be a little less confusing, mainly, the options displayed are based on the node's parent, so options that are overridden by a node's parent container won't be displayed - Also on ui, if I remember correctly the default ui theme is now based on the engine's ui theme, so it doesn't immediately look _as_ terrible, still not perfect and probably should be reskinned to match your game's theme anyway - Godot's search engine has improved significantly, which means that the intellisense in the code editor is significantly better than what it was, prioritizing commonly used methods/variables and showing results even if you make a typo I probably missed a lot, because I was typing this list very lazily as I watched and haven't exactly been glued to the development of the engine. Great video by the way, hope that more people get to see it 👍
@@woopslap it's coming out some time this year, no official release date from what I've seen. Recently it entered feature freeze (nothing new is being added, now focusing on bug fixing), and will be entering the beta phase soon™.
I don't use get_parent() at all when programming in godot. imo that is bad practice. Create a group for certain nodes and in the main node/top node in the hierarchy. Just call get_tree().get_nodes_in_group() and it returns all the nodes that you need in that specific group as an array. Like the spawners that you showed. Higher up nodes should connect lower nodes in the hierarchy, so they aren't dependent on higher nodes being there. This will prevent your game from crashing. Lower nodes should never connect themselves to higher nodes. I used to do the same thing you did with singletons and storing nodes. But then, I read a godot design pattern somewhere that made my workflow much easier and faster. You could also get_children() and check to see what group the children are in as well.
@@saul8510 Even if it's expensive get_child/get_children is still worth it because you'll only be using it once usually in _ready(). If you create a instance later on. You'll already have all the information you need to make the proper connections. Appreciate it!
exactly, when splitting up nodes to be modular and self-contained, get_parent() has no place in the code. it was never meant to be used heavily in any godot project.
It's crazy how far Godot has become in all these years. Especially 3D and its performance got improved by Godot 4.0 by a lot which just makes it so much more fun, motivating and promising to work in 3D using our lovely engine. I am very excited about how Godot will evolve from here on, since it is also getting the recognition it definitely deserves. Great video and great channel. 🙂
I have used Unity for years, gamemaker, XNA c# etc and honestly Godot is the only engine that i ENJOY using, alot of the issues LazyAlarm had I was like "oh but I know an easy fix for that!" or an option that was missed. One thing I find really odd about Godot is the community, it's so lovely and I've had nothing but positive people, I have no doubt there are awful people everywhere.. but I've never had that horrible elite nerdy hate for not knowing something that was "DUUH so easy duuuhhh" easy. lol
i don't have a ton of experience with godot and its community but what you describe seems like the same vibe i always get from the blender community; i guess it's an open source thing - people want the project to succeed and one of the ways they can help bring that about is to help other users if they can
Intellisense in godot I agree it is not the best, but a really handy feature that I like, is that you can ctrl + click on a method/variable you just wrote, and it will open a tab in godot explaining what that method does, and it is really helpful and it saves you a lot of time, instead of going into your browser and manually searching for that method in the documentation!
While it's by no means bad to praise good features, this is a thing that has existed in most decent code editors and IDEs for years, it's nothing specific to Godot.
@@RenderingUser Yes, the specific Ctrl+click binding is usually to go to the definition or usages, the feature is just invoked differently. Heck, even my fairly vanilla Neovim can instantly get me the documentation of anything from a Rust package I have imported by just pressing Shift+k.
12:50 It should be noted that anything in yellow is not an error. It's like an IDE making an unused variable grey, except slightly more obnoxious. And with regards to autocompletion of nodes, Godot basically treats scripts as an anonymous class by default; you can kind of remedy this by using `class_name` on your scripts to give them a proper name, but that requires instance checking and such. GDScript in the past has been more oriented towards duck-typing, but they did start moving towards more static typing in later 3.0 releases.
Would be great to get a refresh on this topic with Godot 4.1. I also really appreciated the more niche memes, seeing that Aperture and Black Mesa chart was something else!
This video fires me up. As someone who just doesn't know where to look for solid basics on maneuvering Godot, this made exploring and what to look for soo much better. Thanks for the fantastic vid!
My biggest criticisms with godot that are still valid having worked with 4 is just how annoying the actual project architecture is. When you get into larger projects it starts feeling like I spend as much time contriving ways for nodes to communicate with eachother properly than I was writing new nodes. Groups are a godsend but signals start feeling pretty limited imo. Its just a sideeffect of their node structure vs entity-component
5:02 Godot has "Update Continuously" in Editor > Editor Settings > Interface > Editor and turn on Update Continuously. It works for moving stuff around like you described, however I've found that it doesn't work if you're updating properties on materials. It's definitely not an apparent feature and certainly located in a place most beginners would never look but it is there
The autocompletion sucks but you can somewhat improve it with class_name and typed vars. So making "class_name Player" in the player script and "var player : Player" in Ref. If you want to know about some function you can just Ctrl+Klick an it opens the offline documentation on the right page and line. (works better than lookup symbol for me for some reason) Instead of many get_parent you can use get_node("../../../../node") or the short form $"../../../../node" or use find_parent(). Or like the tooltip suggested at 11:40 Use "/root/" to get all the way to the top of the scene tree. The NodePath export can be restricted but it is some complicated stuff with _get_property_list() so that is too complicated I agree. 12:04 hurts to look at. Use a group or search for them in _ready(). Ex: var gate := [] func _ready(): for c in get_children(): if c.name.begins_with("EnemieSpawner"): gate.push_back(c) I hope I could help.
I started using godot because it looked like a good all round engine, easy to understand and mostly because it was open source and Free :) Having a blast of an experience with godot, I'm really glad that I started making games.
I know this is older now, but Godot Docs specifically state if you need to access up a tree more than a few levels, you're proooobably doing something wrong. @11:30
You can improve the autocomplete settings (idle parse and code complete delays, type hints) in the Editor > Editor settings > General tab > Text editor section > Completion. Type hints will show you the types each code complete entry is :) . It's just not on by default, no idea why. You can shorten/lengthen the suggestion delays to your liking as well.
11:46 You can use get_node("../../../../path/from/there") instead of calling get_parent a lot, but in general, parent should no about children but not the other way around. We often say "Call down, Signal up" which means, connect the signal that your child will emit to the function the parent or other nodes will call each time that child is emitting that signal. That allow to reuse the child a lot more easily, or even swap it out later for another with a similar signal setup without too much of a hassle.
11:43 use relative nodepaths 12:17 The thing is, these issues come up when you try to fight godots design philosophy, you almost never actually need public references if you're using signals correctly. Scope is very important here and it should not pose any problems when approaching it the right way. I had the same issues, coming from unity and trying to force godot to work as unity does. Good video overall tho!
Like many others suggested, hitting Ctrl+Space to force autocompletion can help ease the headaches, and adding type hints, class_name statements, using the colon equals operator (e.g. := which basically tries to infer the type) when getting onready references to child nodes can help Godot figure out what it can fill in a lot. But there's a catch to using the class_name statement in Godot 3.x and it's circular dependencies. If you have two scripts A.gd and B.gd with class_name statements (e.g. class_name A, class_name B), and try to get cross references against each other (e.g. "var a: A = ..." in B.gd and "var b: B = ..." in A.gd) you won't be able to compile/build the game; in which case you'll have to forego the corresponding type hints from one of the scripts. Fortunately this is fixed in Godot 4 which is fast approaching beta.
26:05 For UI you want to mainly use Containers, which automatically position things. It'll ignore all those margins/anchor properties, and the only thing that'll matter are size flags (for stretching, centering, etc). There was even a recent proposal to just flat out remove anchors margins & grow direction and just have containers instead. Probably won't happen but it's a good indicator of how much better Containers are
I just started learning game dev, I'm a total beginner and I chose Unity, but this video really made me realize how complicated Unity is, maybe I'll try out Godot
As someone who was always curious about making games but was completely overwhelmed and felt pushed away by engine's like Unity & Unreal because there is hundreds of different things going on all over, Godot has finally been my breath of fresh air from the very first step of opening an example project. Everything is so digestible and easy to understand, even the scripting language. For the first time ever I was able to make my own changes and play around without needing to be lead or follow a tutorial. 110% recommend trying out Godot for a beginner and beyond
Unity isn't as complicated as he makes it out to be, people just like to complain about Unity3D. Unity does have its issues especially with the price change recently, but for making games it's a great game engine. Pokemon go, hearthstone, Cup head all great games made using Unity. Saying all that I do think Godot is a great engine just they both have their pros and cons
Really great video! As someone who knows nothing about Godot this gave me a pretty good intro to what’s it’s like using it and what you have to look out for later on
it's over a year later... but ".call" could also do this! it basically works like this: some_node.call("myMethodName", ["argument1", "argument2"]) you could even call a method in the same script with "self.call(method_name)"
Are you aware you can synchronise scene and script changes from the "Debug" menu? Not sure if this would do everything you may want it to, but it should cover most of it. And people? Well, I noticed Jakefriend, Miziziziz and the PlayWithFurcifer couple, but there's also Jotson (Gravity Ace), Jitspoe (a former AAA dev who's now using Godot to make Fist of the Forgotten). There's MrEliptik (Dashpong), Lentsius and ValiantCheese (Hive Time, Bat Egg, Bonesweeper), and Tim Krief. It's a growing community out there!
Setting up VSCode as the default Godot script editor was an extremely good decision. Also, intellisense / smart completion works better if you explicitly set the type of your variables, i.e. write "counter : int = 0" instead of "counter = 0".
I completely agree with you and I taught Godot just like you. Fortunately, most of the problems will be solved in Godot 4.0, but we still have to wait until the release :) I tried Unreal more than Unity, so Godot was in some ways very similar to Unreal and learning Godot was very easy for me. I still love and maybe even adore Godot. Yes, he has a lot of problems and sometimes few tools, but I really have complete control over my game and I can do things that I can't do anywhere else. Also, I always feel that my ideas for improving Godot are really being listened to, and some are even being implemented. How can this not please? :) I feel like I'm growing up in GameDev with Godot and I'm learning a lot of new things and my interest in it is higher. I don't know why, but it's cool :) To sum up, I may praise Godot, but it was convenient for me and it does not mean that everyone should take and use it. Each person will have their own tool and their own engine, which may seem simple and intuitive. Welcome to the world of Godot if anyone decides to give it a try;)
If you're not working on a serious project you can already start using Godot 4. It's in alpha but I personally haven't experience any serious bugs while working on a project.
@@hero3bash unfortunately my project at first for web, so I can’t change right now. But thanks for advice. I also tested Godot 4.0 alpha every time and yes, it becomes more stable and more feature reach
Interesting video! We are also working with Godot on the Mechanic 8230 project. Welcome to everyone who decided to switch to this wonderful engine and good luck with your projects! ;)
I always found that Unity is very slow for 3D at least on Linux. Godot is as good if not surely better in my book. I could never imagine using software that isn't FOSS today, anything that's corporate and centralized I simply don't feel I own and can rely on. So glad this beautiful engine is here.
For debugging, I find it immensely useful (and straightforward) to display text within the game window every frame. That way I can always see the current value of something, without spamming the output log or scrolling through thousands of lines. I make an autoload scene which is a CanvasLayer (set up so it always draws above other stuff), I add a Label to it, and I make a tiny script that lets other nodes write text to it. You made a lot of valid criticisms of Godot, and as a seasoned user I've run into most of the same issues myself! I like your balanced takes, and I'm sure many of us in the community feel the same, as complaints turn into GitHub issues, which then turn into pull requests with fixes and improvements.
4:52 They added that option in Godot 4, if run your scene you will see there is a little camera icon called 'project camera override' click on it and will let you move your editor camera inside the game :)
@@ShVanesMusic I think it will going to be released early next year as they Godot have not release any type of statement that it is going to be released this year.
When it comes to shader compilation lags. Lookup ubershader in next Godot update (3.5 that is on release candidate stage), it is meant to fix that exact problem
A lot of the problems/annoyances you had here can be solved in godot. For instance you could just use C# as your language (full debugging support for that), support for C# was always ok and have gotten even better. And for example the scripts switching on you can be disabled if you go into editor settings, just search for "script" and you will find "Open dominant script on scene change" which when disabled it will no longer switch around. Hopefully if someone else has similar annoyances with godot they see this comment and check the editor settings, if you can't find something i recommend r/godot, while it may take a day all questions are usually answered there.
I have no prior experience in coding in general, and as such I have no context for any other game engines. The limited experience I've had with Godot so far has been really really good. I love how it feels to interact with. The nodes are really fun to work with so far.
It's always interesting to see the issues people have with Godot and knowing that it already has an easier way to do it. The thing is, you need to have read the documentation to know about it. For example, the collision mesh generation problem (where you have to manually generate them when the mesh is changed) can actually be automated pretty easily. The simplest way is to add '-col' or '-colonly' to the mesh that should have collisions, and boom Godot creates collisions at import automatically. Godot's documentation in my experience is very good in many places, but is still a bit lacking sometimes and can occasionally be hard to find what you need. Like you said as well, I've been using Godot for a while and have a lot of experience, but there's still new stuff I find out about and play with, and to me that's kinda part of the fun.
Great video. For those curious, the negative axis thing is a standard in computer graphics and OpenGL. If we fix x and y to grow larger as you move right and up, then when finding than orthogonal basis vector using a right handed system you end up with a z that grows larger as it moves towards us, meaning we look down the z axis in a negative direction. Long winded way of saying, the name derives from the linear algebra and math
Currently studying Linear Algebra and find that interesting lol. I am finally getting a Comp Sci degree and looking into Godot (over Unity in which I have many years of experience) for game projects.
For your first point, the workflow, what I found to make an awesome difference for me was when I discovered that when clicking on the thre dots in the upper right corner, you can layer your optionwindows differently. Takes a bit of fiddeling, but I always use it to make the signals-tab appear above instead of behing the node.config-tab. Nothing bug, but it GREATLY improved my own workflow, maybe it will work for you too. Otherwise keep up the great work haha!
Man you used the song from NSMBW, World 7 Sky Land, that's amazing! I love it and it's so nostalgic, thanks for that! I didn't remember that beautiful song.
I was afraid of changing to C# on godot but is not that hard. You got the typing, brackets, etc and the documentation is really good. After some time you get used to see a GDScript code on a tutorial and see how it will be in C#.
Very comprehensive review. I can relate to a lot you've said, not everything, but enough to generally agree with you. To tell you what I disagreed with in particular, I would have to rewatch the whole video to find all those things, because I simply can't remember (I didn't watch the video in one session, my video experience was interrupted by real life 😅 So I had to watch the second half later and only God knows what happened in the first half). But I absolutely endorse the conclusion about Godot overall and with the community. I really love the engine and the tool and the people behind it. Oh, and yes, the reason for your problems with HTML exports is GLES2 vs. GLES3. The latter one makes problems with web exports.
Also, adding to what SgtChilli said about SinglePurposePrinciple and TreeStructure: if you have some spare time and cash, get your hands on "Code Complete, 2nd edition". It's a big book about programming that is language agnostic, and everything Godot-related will suddenly make a whole lot more sense. Godot is built on OOP (Object Oriented Programming), with polymorphism, decoupling, etc. in mind. Once you read that book, you'll be able to apply the mindset to both your Godot hobby and almost any job. Very distant example: SinglePurposePrinciple is great in workshops where low cost tools keep getting misplaced and lead to expensive wasted time searching for it, so by multiplier the number of low cost tools to "1 per work station, w/ only 1 purpose", you get to eliminate the employees' time sinks and confusion for the cost of a single low cost tool (a quick math check will let you know how much time saved is needed to recup the tool's purchasing cost).
The unity world axes (Z forward, Y up) makes much more sense, and comes from the early days of GL rendering. Where the rendered image can be constructed in a 2D manner with x/y coordinates like a graph, and optionally with a z coordinate using a depth value and showing a 3D scene using perspective rendering. The whole "z buffer" thing shows that in classic graphics rendering z is "forward", eg into the scene.
😀 Nice. I started with Godot 3 and invested 2000 hours in my first game. 3D, Cam System, Landscape, Menu, Animation, Sound, Dialogues etc. Godot is a top engine... you just have to invest time and learn and try and ask... I have published 3 games and am now building my first app... all the best...
Recent news involving Unity Industries had lead me to try Godot. Like you, Godot has been on my back-burner for a while, and now I have the push to finally go for it. Hopefully I can maintain my C# roots with the mono-version.
11:26 To get the player variables to appear in the autofill, you have to have the scene with the object you're editing open in it. For example, if you want the player variables to appear in it, you have to have a scene with the object you're editing and the player as a child of it. Outside of that it will not know what sorcery you're talking about when you want to know the player's health.
Something I would recommend getting a good grasp on is how to build custom resource types. If you create a script that inherits from Resource and then give it a class_name you can then RClick in your file system browser add New Resource... using their wizard, search for your custom name and then you can create a kind of prefab of a class that you've created that can be adjusted in the editor even at runtime via export variables. This is especially great if you are working with a team and want people to test adjustments without touching the code. To give an example suppose you have an enemy class that you set up as a resource. With export variables for the stat blocks of the enemy, a set of exports for different scripts like movement, combat-class etc, a set of exports for the model used and colors to modulate them with. You could then set up an editor layout that had the filesystem browser and the Inspector as the only things on screen and a team member who has no coding experience could drag and drop the scripts, models from the filesystem browser and adjust the stat block and colors with the interface in the inspector and create and save/test 100's of variations of enemy designs. This is especially great when building a game like a tactics, sidescroll or jrpg game where you plan to reuse assets and just adjust color and stats to denote a different strength or Eliteness of an enemy.
I loved this video essay. About the lack of tutorials, I feel as if I was compelled to make my own just so new people did not have to end up like I did!
Thank you so much! I wondered what game engine I should start learning first to engage in game development and not be stunned and eventually burned out because of engine overloaded by features, unwanted by newbie game developer like myself. You've just opened my eyes and made me want to start learning Godot. Really look forward to further development of the platform!
The way I usually update meshes is Close all scenes that use the object Go to the glb file in the import tab click on reimport Then open the glb file (you don't need to inherit that time just click open anyway) Then when you open the scene that derives from it it should already be updated. That works most of the time
Such a great video! I hope you continue to make content like this the amount of love you put into it really shines! I learned a lot from this video I had no idea Godot treated 2d and 3d so differently. That makes me even more excited to use it tbh
Can't wait for Godot to reach critical mass regarding users and features. I really wonder what the first game will be that I really wanna play that is made in Godot :)
A few things: Very nice video, have been using godot for a couple of years now (as a hobby) and always liked the program and it's community. Here are two things I noticed: - While running the game, you can actually move things in the editor, and they will update their position in the game. - In 4.0 the script editor (as well as most other parts of godot) can be in a separate window. Maybe that helps, have a nice day everyone
I picked up godot when i was in college while i was exploring my career options. I didn't become a game designer but i do enjoy playing around with the engine from time to time to see what i can create. However I have seen godot's development over the years and it went from a little game engine with promise to a strong contender in the open source arena. I am glad i stuck around to watch it evolve to what it is today. Godot 4 hype!
/wow/, just seeing color coded groups of tools and buttons makes them SO much more distinct. illustrator/photoshop/indesign have this nice clean single color palette for all their tools icons, but when those icons are tiny, shapes just start blurring together after a while. I started out on photoshop elements (basically photoshop lite) ages ago, and thought the slightly larger color coded tool icons looked terrible. But you know what? 15 years later and I WANT THEM BACK lmao 😂 I may have to check out godot after this, it looks a lot better than I expected
As for regenerating collision shapes on reimport: If you use a file format that preserves the internal mesh names then you can use hints to tell godot what to do with the mesh. For example you can let the name end in "-col" in blender so that godot will generate collision data for it. There is a lot of such hints, for example "-rigid" for rigid bodies and "-navmesh" to generate navigation data.
I'm like 5 hours into Godot and this video was a exactly what I needed to see for someone with almost zero experience in using an engine. It lets me know what challenges I should expect to go through for the next bit - maybe you've helped speedrun the experience. So Thanks!
The mention of support coming from discord is something that resonates with me as me moding my games alot they've been nice patient people that inspire me and help solve my problems
Maybe due to video run time restrictions you didn't put this in the video but my favourite fun fact about godot is that godot runs on godot, the whole interface you use to make games is made with those control nodes. So technically you could make godot using godot which uses godot.
32:40 about the console ports issue: godot just released that some of the original founders are making a non open source project to run alongside godot and this allows them to handle console publishing for you. Last I heard they said they’d have something out(the company(w4) is making other things, so idk what they’d be releasing) in a couple weeks, but we’ll see. Overall very happy I switched to godot! I started on ue4(not knowing anything) then I decided to try unity and just learn code, then back to ue4 for awhile, then back to unity, then finally godot. I tried switching from godot to stride in hopes of getting better graphics, but overall they were the same and I like the godot workflow much more.
I want to get into game creation myself and you've summed up every fear I have when I opened Unity and looking up Guides for Unity neatly, and also the reason why Godot seems much more appealing and friendly to new comers. I can't wait to fully engage with the community.
You don't get suggestions sometimes because the engine doesn't know what type of node you're dealing with, the result of get_node is a Node so it only suggest functions for the Node class, even if that Node could be your Player with it's own function. So to get suggestions you can actually static type in Godot using colons like in Kotlin. "var thing : Timer = get_node("Timer")" and now you can get specific functions of the Timer class suggested
I ended up going the other way as I just like C# that much more, but fantastic and fair video. I loved Godot when I used it, and may return at some point when I'm comfortable with Unity. Looking forward seeing what you make!
On the autocomplete side of things it has an icon to the side telling you if its a function, an object etc. If its a function the icon will be the ".f()" thing.
Excellent, excellent, excellent. You got a few technical things wrong, some things you clearly haven't yet grasped well (understandable, you're fairly new and in general you've picked it up very well) but I'm far too lazy to itemise them with long technical explanations. Anyway, that's all beside the point, you got the essence of it spot on. That was very fair. You allured to it yourself numerous times but so many of the things you mention are being fixed in G4 which is available in increasingly stable alphas. You also mentioned the community which made me smile as given all the time I've spent answering questions I answered in the forum. :halo: You didn't mention the biggest 3d drawback; the 3d renderer looks dull and washed pretty much no matter what you do in the shader... I was doing a solar system sim and I had to give up on night and day shadows in 3.x and redo it in G4. But my god does G4, look great. It just takes three times as long because I don't know it backwards... Anyway, excellent stuff as i say.
I once tried making a RTS in godot, it didn't go at all well 😂 I am a programmer on the other hand, and mainly just found the lack of a good coding environment a big loss. I also wanted to procedurally generate terrain which appeared to be a nightmare... I feel a large portion of that was due to my inexperience at the time, and possibly lack of motivation to put the time into fixing the issues though.
@@Sancarn Honestly, anything that's missing in the engine can be solved with dlls, buffers, and extending the engine yourself. It seems like a lot has improved with the engine honestly though.
@@Sancarn right right. But at the same time. A build process is a more minor thing and only really requires you to get it right once before you develop and automate the script for it. Multi-platform is definitely an issue that needs to be taken account for. But even so, its more of a one time logistical issue that can definitely be fixed. As long as you design the architecture for it well. You should in theory have minimal problems. Oh and also, there's no shame in using other tools too. Such as blender for terrain generation. You don't have to do everything in godot. Hope my reply isn't annoying
yeah borncg was the only one that explained what he was typing and made me understand the fundemantals, unlike other tutorials that give you the code but you just don't understand a thing.
Unity currently made a lot of awful decisions that only made my decision to switch to Godot even better. I like that I don't have to install package this and package that and package everywhere and URP or HDRP or this and that setting in Godot at all. Godot is just complete right at the start without needed to be added together manually. It also has a lot of comfort features both UI and programming wise that make the necessary code way smaller in comparison to Unity. I don't have to code up a ray cast function for a wall climb mechanic in Godot at all, but just can say something like "on wall" for the If part, and it understands what I want it to do. My second indie game is being made with Godot. Hopefully this time It will be a success. It's also great that a lot of nodes are specialized for all sorts of different, often needed features. I don't have to code up a scoreboard manually, but can just use the dedicated score label node and a bit of code for that.
About scripting: you get used to writing code without auto completion over time, it's not a big deal. In my opinion, writing without fully statically analyzed auto completion forces the coder to be aware of parameters of the functions he's calling and what they do. Yes, it's more troublesome to write code, but it forces you to understand your code more thoroughly
I disagree with the idea it forces you to understand code better. It's a time-saver ultimately, and when you have hundreds or thousands of lines or code, that simple time saver can shave off a considerable amount of extra work. Having a good autocomplete that works as it's supposed to is just a basic quality of life at this point. If you're only making small projects, you might never notice it's gone, but with larger projects and more scripts it's a nightmare to be without it.
@@Crystan No it's not easier. Auto completion doesn't work with dynamic languages very well due to the dynamic nature of those languages. For example, just look at documentation of jQuery, you can see many different ways to call the same function. It's very difficult for auto completion programs to hint those many different ways to structure function parameters. The best it can do is link the man made documentation for you, but you still need to read much more than you could have if you were using a static language.
Since more people are seeing this video as a result of Unity's recent pricing change, I would like to emphasize that these are my opinions on the engine pre-4.0 update which addresses and fixes a large majority of issues I had with the engine, and adds a number of valuable features.
Second, many of my concerns or wishes were also addressed by more experienced users in the comments, and were a result of my lack of experience. I hope the comments can be a good resource for anyone struggling with the same things I was.
Since this video released, I have continued to use Godot. I've made 3D games, I've made 2D games, I've made simple graphics, I've made more detailed graphics. I've made VR games. I have yet to try a game idea that I felt could not be achieved with Godot.
Would be great to see an updated video with the solution to some of those problems maybe xD
@ModernCopy? Godot is an easy 3D game engine relatively speaking
Yep that's why I'm here too! Maybe it's time for a 'used Godot for 200 hours' update?
I am cackling irl at the fact that so many game makers changed engines because of the controversy that this video reached the youtube algorithm en masse hahahahah mannn
I am really concerned about the 3d capabilities of godot for making my dream project. I am still trying to wake up from the trauma that unity gave me and really thinking of shifting to unreal engine 5 but I am still considering godot as an option just that I doubt I can achieve the level of quality with godot's power so far. I am talking about Genshin level quality or something similar (I am talking about my dream project so don't think I am being arrogant and thinking that I can create something that). So I don't know, I heard that Godot's lighting system is not that great and since godot is mainly used for 2d games. I just can't make up my mind and will probably go for unreal engine.
I think Godot being 'durable' instead of 'fragile' is the thing that allowed me to actually dive into game development. The node system is just something that clicks with my brain, because when it came to other game engines/programming languages I'd struggle just to get buttons working; among other more simple concepts I'd struggle to grasp with. You know the typical problem of following a tutorial and at the end of it learned and understand nothing of what I did. With Godot on the other hand I can follow a tutorial and actually come out the other end with actual knowledge.
Hey man, I would like to start using Godot too, can I ask you which tutorials did you followed? Thanks
holy... i thought i was the only one!
@@MisterPineTreeI hope this will let OP see your comment, because I’d also like to know who they watched.
@tsary_8561 Brackeys has one out that I've been following and it's really good. Wayyy better than the old stuff imo.
I have the same thing with Godot. I even have some prior programming classes under my belt and tooling around with minecraft modding. I've tried several engines and Godot has been the one that makes the most sense to me by far. It's so intuitive and, as someone who used to do graphic design as a hobby, the GUI just makes me so happy.
I love using Godot, because it feels like how I imagined game development would be when I was younger.
Everything flows together nicely, and if I need something, I know where to look, and if I want to know what something does, I can easily look at the documentation.
Unity however, feels like how I feared game development would be like when I first started. Everything is confusing, there 100 different ways to do x, but only one way actually works properly. Objects have dozens of different values, but you change one and suddenly nothing works.
Unreal however, couldn't run on my high end gaming rig from 2010, so despite having a computer that could probably run it now, I've already grown too attached to Godot to even think of jumping ship.
as someone who started with unity i have exactly the same feeling towards godot as you have towards unity
" there 100 different ways to do x, but only one way actually works properly" thats a great point.
For me with godot its like "you have 100 different ways to do X but only some are better performance" stuff works but maybe not most efficiently
As a unity Dev this hurt
And now with Unity dissing developers and getting talents from an adware company, all the more reason to go to Unity.
@@Aereto All of that is so out of context it's not even funny. Don't believe every headline you read, nor what people told you they "read" without reading the article.
A lot of click bait and misinformation came out and unless you read the original interview and looked into the company they acquired don't go around talking about stuff you know nothing about.
First off, he did in a way diss developers but not in the way you think. If you make a game for art that's fine.
But if you are making a game for profit (the key context) and you don't use the tools around for you to monetize the game then yeah your an idiot. (that's the funni tag line "devs are idiots") Unity is natively supporting monetization now.
Second, the company they merged with IronSource (didn't buy, no cash traded hands just their stocks turning into unity) Never made malware.
They made an install wizard that was open source. Much like how you can make malware with Unity. You could make malware with this (by attaching bloat or malicious products to the install wizard. If you remember like when you download 7 zip and the wizard asks you if you wanna download all this other shit? ) They got flak for what people did with their product. Not anything they did. They no longer support said software and haven't for 5 years now.
The only thing they do now is targeted ads and mobile game ad software.
This is mostly for the IOS market where if you were to use a 3rd party software the game would have to ask permission on your device to show ads.
and yeah, if you were making mobile games for the sole reason of making money, or if your making a game and want to get paid for your work I kind of agree. You should use the tools given to you buy Unity to make that happen.
Game development has changed, sure you can release your game on steam, itch.io. Apple store or google play randomly and do no promotion and hope it blows up and by proxy you make money. The old way.
Or you can go with the future and get feed back on the way your monetize game while you build it. (More so in the mobile space) Making sure ad's don't interrupt the gameplay loop etc
Personally i dislike mobile games and their ads so I won't be using it. But like a lot of advanced software in unity just because I don't want it doesn't mean other people don't.
"All game engines have their own special ways in which they work. Unity has MonoBehaviours. Unreal Engine has Blueprints. GameMaker has a 100 USD a year subscription fee. And Godot has nodes."
LOL
Member when the subscription model "wouldn't kill the engine"? I member
i just realised that seems like shit but thats only $8 a month
@@saverofthewo That's exactly how they get you. It's only 8$ a month but let's say you buy a perpetual license for 99$ that you can keep forever. If you use the software for a year on the subscription model you have already paid as much as you would have on the old model.
Source Engine has Vscript
Two things that make me use this engine:
- cylinder collision shapes
- the node family system is absolutely bonkers and I adore it to no end
Never got deep into game development but that node system description gave me a throbbing brainer.
@@ThatPianoNoobhaha it is awsome though
It actually blew my mind when instead of having to write a script to make the 2d camera follow the player, I could just make the camera a child node by dragging it underneath. I got all giddy about it lol
One of the reasons Godot's UI tools are so powerful, is because Godot's Editor is powered by Godot. It's built with those nodes.
They build the editor using itself? What a flex.
Unreal does the same, its weird!
It's like how programming languages will first have a compiler in a different language, but then subsequent compilers will be made in the language itself.
@@swordofstabbingold Yeah that's a real trip, so cool!
@@swordofstabbingold That is a process called bootstrapping and it is really nifty
There are a couple things about Godot's design I think you should know:
1) Single purpose principle - All nodes do one thing (ie handle themselves), there should be random nodes that only serve to have a script, and that script should only do one thing.
2) Tree Structure - Parents should know their children, but children shouldn't know their parents, otherwise use signals, using an autoload signal connector node is totally fine.
If a child needs to know it's parrent, in the multiple scripts excample, "export(NodePath) var myNodeToManipulate" will work well, you can then use the get_node(myNodeToManipulate) to get the node. This also promotes code reusability.
Um.. wot?
Why children shouldn't know their parents?
A famous saying in Godot: "Call down, Signal up."
@@WizzardPowers because your parents are deprecated /j
I think it has probably something to do with reusability. If u use signals then you're not relying on where your node is placed but if you reference your parent the node becomes tied to it and can't be used elsewhere as an instance for example. Keeping specificity low is often a good thing.
@@JebacPresretac101 Yeah, this is the approach I tend to use too, since it makes it sooooooo reusable like you said.
I would love first class global signal support though!
My favorite thing about open source programs is that it's improved on and worked on by those that use it. They know exactly what users need and want, and the issues that have, because they are them
Aaaaaand I just got to the party where you said the exact same thing
My personal favorite creators in the Godot community is DevDuck, just makes devlogs but he displays expert use of the engine, an amazing workflow, and an overall nice way to balance work and life
DevDuck is great
A nice way to balance work and life. That’s the hardest part and he’s got it so right…. !
You mean creator creators means 2 and you only mentioned one so it’s creator not creators
I havent seen devduck but garbaj is also gread
Great
A huge tip if you're moving to godot:
Go to the settings>text editor>behavior, and turn off the "Open dominant script on scene change." There's a similar option under the settings>text editor>files menu, DO NOT BE TRICKED.
There's also a few other goodies like scrolling past the end of the file.
thanks, this was getting me mad
Awww your pic is so cute!
What's the reason for this?
@@miadietrich7347 Because when this is on, if you have a lot of scenes you're going back and forth between, they'll always be silently clogging up your scripts panel, even when you aren't editing those scripts.
Thanks!!
As I'm watching this video, I know you mentioned things will change in godot 4.0, so here's a list of things you mention that I know for a fact have already been changed in godot 4.0
- Physics have been completely rewritten from scratch, so they shouldn't feel nearly as janky
- 3D audio and audio in general has been overhauled, so most of the issues/jank there will get much better
- Shader compilation has been reworked so that, while performance will still drop a bit while they compile, the engine won't grind to a complete hault waiting for the job to finish
- As you said, the options for 3d are already great, but it's getting even better, multiple options global illumination, deferred rendering, etc
- Some things with the way ui options are displayed have been changed to be a little less confusing, mainly, the options displayed are based on the node's parent, so options that are overridden by a node's parent container won't be displayed
- Also on ui, if I remember correctly the default ui theme is now based on the engine's ui theme, so it doesn't immediately look _as_ terrible, still not perfect and probably should be reskinned to match your game's theme anyway
- Godot's search engine has improved significantly, which means that the intellisense in the code editor is significantly better than what it was, prioritizing commonly used methods/variables and showing results even if you make a typo
I probably missed a lot, because I was typing this list very lazily as I watched and haven't exactly been glued to the development of the engine. Great video by the way, hope that more people get to see it 👍
also dont forget the engine being able to make more than one window instead of fake overlays
thats the best ui thing that happened to godot in a while
So pretty much every issue discussed in this video is fixed.
whens it coming out
@@woopslap it's coming out some time this year, no official release date from what I've seen. Recently it entered feature freeze (nothing new is being added, now focusing on bug fixing), and will be entering the beta phase soon™.
@@jarbarsi Hi, any idea if anything else notable from this list specifically is being backported to 3.5?
You really need to make a sequel to this video
I don't use get_parent() at all when programming in godot. imo that is bad practice. Create a group for certain nodes and in the main node/top node in the hierarchy. Just call get_tree().get_nodes_in_group() and it returns all the nodes that you need in that specific group as an array. Like the spawners that you showed. Higher up nodes should connect lower nodes in the hierarchy, so they aren't dependent on higher nodes being there. This will prevent your game from crashing. Lower nodes should never connect themselves to higher nodes. I used to do the same thing you did with singletons and storing nodes. But then, I read a godot design pattern somewhere that made my workflow much easier and faster. You could also get_children() and check to see what group the children are in as well.
smart thinking, get_child or parent is expensive as you have to find that node, in a group it already knows who is the group because there not much..
@@saul8510 Even if it's expensive get_child/get_children is still worth it because you'll only be using it once usually in _ready(). If you create a instance later on. You'll already have all the information you need to make the proper connections. Appreciate it!
But we're lucky we got groups. Makes things a whole lot easier.
exactly, when splitting up nodes to be modular and self-contained, get_parent() has no place in the code. it was never meant to be used heavily in any godot project.
Thank you
It's crazy how far Godot has become in all these years. Especially 3D and its performance got improved by Godot 4.0 by a lot which just makes it so much more fun, motivating and promising to work in 3D using our lovely engine. I am very excited about how Godot will evolve from here on, since it is also getting the recognition it definitely deserves.
Great video and great channel. 🙂
I have used Unity for years, gamemaker, XNA c# etc and honestly Godot is the only engine that i ENJOY using, alot of the issues LazyAlarm had I was like "oh but I know an easy fix for that!" or an option that was missed.
One thing I find really odd about Godot is the community, it's so lovely and I've had nothing but positive people, I have no doubt there are awful people everywhere.. but I've never had that horrible elite nerdy hate for not knowing something that was "DUUH so easy duuuhhh" easy. lol
Eh, there are a few bad apples out there, seen some of them. But the community is definitely a good one.
@@sslaxx oh I have no doubt. I wonder as it gets more popular the bad voices are always the loudest.
i don't have a ton of experience with godot and its community but what you describe seems like the same vibe i always get from the blender community; i guess it's an open source thing - people want the project to succeed and one of the ways they can help bring that about is to help other users if they can
@@rungeon83 Human nature, it seems alas.
Damn i been missing out i used eeverything else for years now hadnt even heard of godot till now something tells me im gonna finally be stoked lol
I appreciate how often godot updates and how the devs actually listen to their community.
Partially because the community are the devs :)
And the Community became the Devs so they can improve their own Game. Basically a healthy Relationship.
Intellisense in godot I agree it is not the best, but a really handy feature that I like, is that you can ctrl + click on a method/variable you just wrote, and it will open a tab in godot explaining what that method does, and it is really helpful and it saves you a lot of time, instead of going into your browser and manually searching for that method in the documentation!
While it's by no means bad to praise good features, this is a thing that has existed in most decent code editors and IDEs for years, it's nothing specific to Godot.
@@HoloTheDrunk normally clicking that in an ide takes you to the definition of that method in my experience
but godot goes to documentation
@@RenderingUser Yes, the specific Ctrl+click binding is usually to go to the definition or usages, the feature is just invoked differently. Heck, even my fairly vanilla Neovim can instantly get me the documentation of anything from a Rust package I have imported by just pressing Shift+k.
@@HoloTheDrunk wait
can i hav ur nvim config?
Never know that, thanks!
12:50 It should be noted that anything in yellow is not an error. It's like an IDE making an unused variable grey, except slightly more obnoxious. And with regards to autocompletion of nodes, Godot basically treats scripts as an anonymous class by default; you can kind of remedy this by using `class_name` on your scripts to give them a proper name, but that requires instance checking and such. GDScript in the past has been more oriented towards duck-typing, but they did start moving towards more static typing in later 3.0 releases.
Would be great to get a refresh on this topic with Godot 4.1.
I also really appreciated the more niche memes, seeing that Aperture and Black Mesa chart was something else!
This video fires me up. As someone who just doesn't know where to look for solid basics on maneuvering Godot, this made exploring and what to look for soo much better. Thanks for the fantastic vid!
My biggest criticisms with godot that are still valid having worked with 4 is just how annoying the actual project architecture is. When you get into larger projects it starts feeling like I spend as much time contriving ways for nodes to communicate with eachother properly than I was writing new nodes. Groups are a godsend but signals start feeling pretty limited imo. Its just a sideeffect of their node structure vs entity-component
5:02 Godot has "Update Continuously" in Editor > Editor Settings > Interface > Editor and turn on Update Continuously. It works for moving stuff around like you described, however I've found that it doesn't work if you're updating properties on materials. It's definitely not an apparent feature and certainly located in a place most beginners would never look but it is there
The autocompletion sucks but you can somewhat improve it with class_name and typed vars.
So making "class_name Player" in the player script and "var player : Player" in Ref.
If you want to know about some function you can just Ctrl+Klick an it opens the offline documentation on the right page and line. (works better than lookup symbol for me for some reason)
Instead of many get_parent you can use get_node("../../../../node") or the short form $"../../../../node"
or use find_parent(). Or like the tooltip suggested at 11:40 Use "/root/" to get all the way to the top of the scene tree.
The NodePath export can be restricted but it is some complicated stuff with _get_property_list() so that is too complicated I agree.
12:04 hurts to look at. Use a group or search for them in _ready(). Ex:
var gate := []
func _ready():
for c in get_children():
if c.name.begins_with("EnemieSpawner"):
gate.push_back(c)
I hope I could help.
I know when my code is bad, but I don’t always know how to fix it. This comment is very helpful! Thank you.
sus
@@spiceywolf though I think it doesn't work on multithreaded code.
Or at least didn't work a year ago (not sure about right now).
Just use vscode for programming godot
Unity recently committing sudoku might benefit the godot community quite a bit
Sudoku the game
I started using godot because it looked like a good all round engine, easy to understand and mostly because it was open source and Free :)
Having a blast of an experience with godot, I'm really glad that I started making games.
a bug caused my audio to tear when you were complaining about the audio tearing and i briefly thought you made a 500 iq joke
I know this is older now, but Godot Docs specifically state if you need to access up a tree more than a few levels, you're proooobably doing something wrong. @11:30
You can improve the autocomplete settings (idle parse and code complete delays, type hints) in the Editor > Editor settings > General tab > Text editor section > Completion. Type hints will show you the types each code complete entry is :) . It's just not on by default, no idea why. You can shorten/lengthen the suggestion delays to your liking as well.
Not gonna lie. Felt a touch surreal seeing my videos thumbnail in this tutorial when im trying to learn godot XD
11:46 You can use get_node("../../../../path/from/there") instead of calling get_parent a lot, but in general, parent should no about children but not the other way around. We often say "Call down, Signal up" which means, connect the signal that your child will emit to the function the parent or other nodes will call each time that child is emitting that signal. That allow to reuse the child a lot more easily, or even swap it out later for another with a similar signal setup without too much of a hassle.
11:43 use relative nodepaths
12:17 The thing is, these issues come up when you try to fight godots design philosophy, you almost never actually need public references if you're using signals correctly. Scope is very important here and it should not pose any problems when approaching it the right way. I had the same issues, coming from unity and trying to force godot to work as unity does.
Good video overall tho!
Like many others suggested, hitting Ctrl+Space to force autocompletion can help ease the headaches, and adding type hints, class_name statements, using the colon equals operator (e.g. := which basically tries to infer the type) when getting onready references to child nodes can help Godot figure out what it can fill in a lot.
But there's a catch to using the class_name statement in Godot 3.x and it's circular dependencies. If you have two scripts A.gd and B.gd with class_name statements (e.g. class_name A, class_name B), and try to get cross references against each other (e.g. "var a: A = ..." in B.gd and "var b: B = ..." in A.gd) you won't be able to compile/build the game; in which case you'll have to forego the corresponding type hints from one of the scripts.
Fortunately this is fixed in Godot 4 which is fast approaching beta.
26:05 For UI you want to mainly use Containers, which automatically position things. It'll ignore all those margins/anchor properties, and the only thing that'll matter are size flags (for stretching, centering, etc).
There was even a recent proposal to just flat out remove anchors margins & grow direction and just have containers instead. Probably won't happen but it's a good indicator of how much better Containers are
Great time for a second part trying Godot 4, it could really help people making the jump from Unity.
Funny how suddenly this is all being recommended to me now.
UA-cam fueling the fire....
I just started learning game dev, I'm a total beginner and I chose Unity, but this video really made me realize how complicated Unity is, maybe I'll try out Godot
As someone who was always curious about making games but was completely overwhelmed and felt pushed away by engine's like Unity & Unreal because there is hundreds of different things going on all over, Godot has finally been my breath of fresh air from the very first step of opening an example project. Everything is so digestible and easy to understand, even the scripting language. For the first time ever I was able to make my own changes and play around without needing to be lead or follow a tutorial. 110% recommend trying out Godot for a beginner and beyond
Unity isn't as complicated as he makes it out to be, people just like to complain about Unity3D. Unity does have its issues especially with the price change recently, but for making games it's a great game engine. Pokemon go, hearthstone, Cup head all great games made using Unity. Saying all that I do think Godot is a great engine just they both have their pros and cons
Really great video! As someone who knows nothing about Godot this gave me a pretty good intro to what’s it’s like using it and what you have to look out for later on
What you are trying to do at Minute 29:08 is actually possible. There is a Func Type which you can use like a variable and Invoke it.
it's over a year later... but ".call" could also do this! it basically works like this:
some_node.call("myMethodName", ["argument1", "argument2"])
you could even call a method in the same script with "self.call(method_name)"
Are you aware you can synchronise scene and script changes from the "Debug" menu? Not sure if this would do everything you may want it to, but it should cover most of it.
And people? Well, I noticed Jakefriend, Miziziziz and the PlayWithFurcifer couple, but there's also Jotson (Gravity Ace), Jitspoe (a former AAA dev who's now using Godot to make Fist of the Forgotten). There's MrEliptik (Dashpong), Lentsius and ValiantCheese (Hive Time, Bat Egg, Bonesweeper), and Tim Krief. It's a growing community out there!
Setting up VSCode as the default Godot script editor was an extremely good decision. Also, intellisense / smart completion works better if you explicitly set the type of your variables, i.e. write "counter : int = 0" instead of "counter = 0".
when you like python but the rest of the entire freaking world wants a strong typed language.
Thank goodness you can use c# with godot
I completely agree with you and I taught Godot just like you. Fortunately, most of the problems will be solved in Godot 4.0, but we still have to wait until the release :)
I tried Unreal more than Unity, so Godot was in some ways very similar to Unreal and learning Godot was very easy for me. I still love and maybe even adore Godot. Yes, he has a lot of problems and sometimes few tools, but I really have complete control over my game and I can do things that I can't do anywhere else. Also, I always feel that my ideas for improving Godot are really being listened to, and some are even being implemented. How can this not please? :) I feel like I'm growing up in GameDev with Godot and I'm learning a lot of new things and my interest in it is higher. I don't know why, but it's cool :)
To sum up, I may praise Godot, but it was convenient for me and it does not mean that everyone should take and use it. Each person will have their own tool and their own engine, which may seem simple and intuitive. Welcome to the world of Godot if anyone decides to give it a try;)
If you're not working on a serious project you can already start using Godot 4. It's in alpha but I personally haven't experience any serious bugs while working on a project.
@@hero3bash unfortunately my project at first for web, so I can’t change right now. But thanks for advice. I also tested Godot 4.0 alpha every time and yes, it becomes more stable and more feature reach
Interesting video! We are also working with Godot on the Mechanic 8230 project. Welcome to everyone who decided to switch to this wonderful engine and good luck with your projects! ;)
I always found that Unity is very slow for 3D at least on Linux. Godot is as good if not surely better in my book. I could never imagine using software that isn't FOSS today, anything that's corporate and centralized I simply don't feel I own and can rely on. So glad this beautiful engine is here.
For debugging, I find it immensely useful (and straightforward) to display text within the game window every frame. That way I can always see the current value of something, without spamming the output log or scrolling through thousands of lines. I make an autoload scene which is a CanvasLayer (set up so it always draws above other stuff), I add a Label to it, and I make a tiny script that lets other nodes write text to it.
You made a lot of valid criticisms of Godot, and as a seasoned user I've run into most of the same issues myself! I like your balanced takes, and I'm sure many of us in the community feel the same, as complaints turn into GitHub issues, which then turn into pull requests with fixes and improvements.
4:52 They added that option in Godot 4, if run your scene you will see there is a little camera icon called 'project camera override' click on it and will let you move your editor camera inside the game :)
When Godot 4 is releasing through?
@@daniishere1009
I hope this second half of year
@@ShVanesMusic I think it will going to be released early next year as they Godot have not release any type of statement that it is going to be released this year.
It’s already in Godot 3.
When it comes to shader compilation lags. Lookup ubershader in next Godot update (3.5 that is on release candidate stage), it is meant to fix that exact problem
A lot of the problems/annoyances you had here can be solved in godot. For instance you could just use C# as your language (full debugging support for that), support for C# was always ok and have gotten even better. And for example the scripts switching on you can be disabled if you go into editor settings, just search for "script" and you will find "Open dominant script on scene change" which when disabled it will no longer switch around.
Hopefully if someone else has similar annoyances with godot they see this comment and check the editor settings, if you can't find something i recommend r/godot, while it may take a day all questions are usually answered there.
I have no prior experience in coding in general, and as such I have no context for any other game engines. The limited experience I've had with Godot so far has been really really good. I love how it feels to interact with. The nodes are really fun to work with so far.
i like how even tho im not a game dev yet this still ended up in my recommendation, truly says alot about the current situation.
It's always interesting to see the issues people have with Godot and knowing that it already has an easier way to do it. The thing is, you need to have read the documentation to know about it. For example, the collision mesh generation problem (where you have to manually generate them when the mesh is changed) can actually be automated pretty easily. The simplest way is to add '-col' or '-colonly' to the mesh that should have collisions, and boom Godot creates collisions at import automatically. Godot's documentation in my experience is very good in many places, but is still a bit lacking sometimes and can occasionally be hard to find what you need. Like you said as well, I've been using Godot for a while and have a lot of experience, but there's still new stuff I find out about and play with, and to me that's kinda part of the fun.
Great video.
For those curious, the negative axis thing is a standard in computer graphics and OpenGL.
If we fix x and y to grow larger as you move right and up, then when finding than orthogonal basis vector using a right handed system you end up with a z that grows larger as it moves towards us, meaning we look down the z axis in a negative direction.
Long winded way of saying, the name derives from the linear algebra and math
Currently studying Linear Algebra and find that interesting lol. I am finally getting a Comp Sci degree and looking into Godot (over Unity in which I have many years of experience) for game projects.
For your first point, the workflow, what I found to make an awesome difference for me was when I discovered that when clicking on the thre dots in the upper right corner, you can layer your optionwindows differently. Takes a bit of fiddeling, but I always use it to make the signals-tab appear above instead of behing the node.config-tab.
Nothing bug, but it GREATLY improved my own workflow, maybe it will work for you too.
Otherwise keep up the great work haha!
Man you used the song from NSMBW, World 7 Sky Land, that's amazing! I love it and it's so nostalgic, thanks for that! I didn't remember that beautiful song.
Welcome back everyone, we all know why we are here
I was afraid of changing to C# on godot but is not that hard.
You got the typing, brackets, etc and the documentation is really good.
After some time you get used to see a GDScript code on a tutorial and see how it will be in C#.
Wow this video is so relevant now
Very comprehensive review. I can relate to a lot you've said, not everything, but enough to generally agree with you.
To tell you what I disagreed with in particular, I would have to rewatch the whole video to find all those things, because I simply can't remember (I didn't watch the video in one session, my video experience was interrupted by real life 😅 So I had to watch the second half later and only God knows what happened in the first half).
But I absolutely endorse the conclusion about Godot overall and with the community. I really love the engine and the tool and the people behind it.
Oh, and yes, the reason for your problems with HTML exports is GLES2 vs. GLES3. The latter one makes problems with web exports.
This video came perfectly after Unity new terms and conditions
Also, adding to what SgtChilli said about SinglePurposePrinciple and TreeStructure: if you have some spare time and cash, get your hands on "Code Complete, 2nd edition". It's a big book about programming that is language agnostic, and everything Godot-related will suddenly make a whole lot more sense.
Godot is built on OOP (Object Oriented Programming), with polymorphism, decoupling, etc. in mind. Once you read that book, you'll be able to apply the mindset to both your Godot hobby and almost any job.
Very distant example: SinglePurposePrinciple is great in workshops where low cost tools keep getting misplaced and lead to expensive wasted time searching for it, so by multiplier the number of low cost tools to "1 per work station, w/ only 1 purpose", you get to eliminate the employees' time sinks and confusion for the cost of a single low cost tool (a quick math check will let you know how much time saved is needed to recup the tool's purchasing cost).
The unity world axes (Z forward, Y up) makes much more sense, and comes from the early days of GL rendering. Where the rendered image can be constructed in a 2D manner with x/y coordinates like a graph, and optionally with a z coordinate using a depth value and showing a 3D scene using perspective rendering.
The whole "z buffer" thing shows that in classic graphics rendering z is "forward", eg into the scene.
Loved the vídeo bro. Really fun, probably was hell to edit it all together lol. Subbed, keep up the amazing work.
I am here after the stunt Unity3d pull a few days ago about the installs.✌️
😀 Nice. I started with Godot 3 and invested 2000 hours in my first game. 3D, Cam System, Landscape, Menu, Animation, Sound, Dialogues etc. Godot is a top engine... you just have to invest time and learn and try and ask... I have published 3 games and am now building my first app... all the best...
Not me over here finding this video now knowing Godot exists and now low-key want to try it
Bro this is me 7 months later looking at this like... 👀👀
ive been watching every video of yours all day, the quality of your content is amazing. please keep making more videos
Recent news involving Unity Industries had lead me to try Godot. Like you, Godot has been on my back-burner for a while, and now I have the push to finally go for it. Hopefully I can maintain my C# roots with the mono-version.
11:26 To get the player variables to appear in the autofill, you have to have the scene with the object you're editing open in it. For example, if you want the player variables to appear in it, you have to have a scene with the object you're editing and the player as a child of it. Outside of that it will not know what sorcery you're talking about when you want to know the player's health.
Something I would recommend getting a good grasp on is how to build custom resource types. If you create a script that inherits from Resource and then give it a class_name you can then RClick in your file system browser add New Resource... using their wizard, search for your custom name and then you can create a kind of prefab of a class that you've created that can be adjusted in the editor even at runtime via export variables.
This is especially great if you are working with a team and want people to test adjustments without touching the code.
To give an example suppose you have an enemy class that you set up as a resource. With export variables for the stat blocks of the enemy, a set of exports for different scripts like movement, combat-class etc, a set of exports for the model used and colors to modulate them with.
You could then set up an editor layout that had the filesystem browser and the Inspector as the only things on screen and a team member who has no coding experience could drag and drop the scripts, models from the filesystem browser and adjust the stat block and colors with the interface in the inspector and create and save/test 100's of variations of enemy designs.
This is especially great when building a game like a tactics, sidescroll or jrpg game where you plan to reuse assets and just adjust color and stats to denote a different strength or Eliteness of an enemy.
This is a great video, I really enjoyed how you delicered all of this too. I then watched some more of your videos, and you now have a new subscriber.
I loved this video essay. About the lack of tutorials, I feel as if I was compelled to make my own just so new people did not have to end up like I did!
Thank you so much! I wondered what game engine I should start learning first to engage in game development and not be stunned and eventually burned out because of engine overloaded by features, unwanted by newbie game developer like myself. You've just opened my eyes and made me want to start learning Godot. Really look forward to further development of the platform!
this video is very interesting based on what Unity is going through right now
Great video, great editing, watched till the end! Keep it up!
The way I usually update meshes is
Close all scenes that use the object
Go to the glb file in the import tab click on reimport
Then open the glb file (you don't need to inherit that time just click open anyway)
Then when you open the scene that derives from it it should already be updated.
That works most of the time
Such a great video! I hope you continue to make content like this the amount of love you put into it really shines! I learned a lot from this video I had no idea Godot treated 2d and 3d so differently. That makes me even more excited to use it tbh
Can't wait for Godot to reach critical mass regarding users and features. I really wonder what the first game will be that I really wanna play that is made in Godot :)
I don't make games just yet, but I just wanted to say this video was super well made!I loved the editing, it was fun but not too meme-focused
A few things:
Very nice video, have been using godot for a couple of years now (as a hobby) and always liked the program and it's community.
Here are two things I noticed:
- While running the game, you can actually move things in the editor, and they will update their position in the game.
- In 4.0 the script editor (as well as most other parts of godot) can be in a separate window.
Maybe that helps, have a nice day everyone
I picked up godot when i was in college while i was exploring my career options. I didn't become a game designer but i do enjoy playing around with the engine from time to time to see what i can create. However I have seen godot's development over the years and it went from a little game engine with promise to a strong contender in the open source arena. I am glad i stuck around to watch it evolve to what it is today.
Godot 4 hype!
/wow/, just seeing color coded groups of tools and buttons makes them SO much more distinct. illustrator/photoshop/indesign have this nice clean single color palette for all their tools icons, but when those icons are tiny, shapes just start blurring together after a while. I started out on photoshop elements (basically photoshop lite) ages ago, and thought the slightly larger color coded tool icons looked terrible. But you know what? 15 years later and I WANT THEM BACK lmao 😂
I may have to check out godot after this, it looks a lot better than I expected
I still use Photoshop Elements 😅
great video, very grounded and not from the perspective of a pro who knows everything already, thyanks!
As for regenerating collision shapes on reimport: If you use a file format that preserves the internal mesh names then you can use hints to tell godot what to do with the mesh. For example you can let the name end in "-col" in blender so that godot will generate collision data for it. There is a lot of such hints, for example "-rigid" for rigid bodies and "-navmesh" to generate navigation data.
It's hilarious to me that you predicted Brackeys coming back because of Godot in a throwaway gag
I'm like 5 hours into Godot and this video was a exactly what I needed to see for someone with almost zero experience in using an engine. It lets me know what challenges I should expect to go through for the next bit - maybe you've helped speedrun the experience.
So Thanks!
25:30 Playing in Ping-Pong by changing window size is so funny xD
The mention of support coming from discord is something that resonates with me as me moding my games alot they've been nice patient people that inspire me and help solve my problems
Maybe due to video run time restrictions you didn't put this in the video but my favourite fun fact about godot is that godot runs on godot, the whole interface you use to make games is made with those control nodes. So technically you could make godot using godot which uses godot.
32:40 about the console ports issue: godot just released that some of the original founders are making a non open source project to run alongside godot and this allows them to handle console publishing for you. Last I heard they said they’d have something out(the company(w4) is making other things, so idk what they’d be releasing) in a couple weeks, but we’ll see. Overall very happy I switched to godot! I started on ue4(not knowing anything) then I decided to try unity and just learn code, then back to ue4 for awhile, then back to unity, then finally godot. I tried switching from godot to stride in hopes of getting better graphics, but overall they were the same and I like the godot workflow much more.
Well this video aged in an interesting way.
How so?
I want to get into game creation myself and you've summed up every fear I have when I opened Unity and looking up Guides for Unity neatly, and also the reason why Godot seems much more appealing and friendly to new comers. I can't wait to fully engage with the community.
You don't get suggestions sometimes because the engine doesn't know what type of node you're dealing with, the result of get_node is a Node so it only suggest functions for the Node class, even if that Node could be your Player with it's own function.
So to get suggestions you can actually static type in Godot using colons like in Kotlin. "var thing : Timer = get_node("Timer")" and now you can get specific functions of the Timer class suggested
I ended up going the other way as I just like C# that much more, but fantastic and fair video. I loved Godot when I used it, and may return at some point when I'm comfortable with Unity. Looking forward seeing what you make!
i hope you know godot supports c# too
On the autocomplete side of things it has an icon to the side telling you if its a function, an object etc. If its a function the icon will be the ".f()" thing.
Excellent, excellent, excellent. You got a few technical things wrong, some things you clearly haven't yet grasped well (understandable, you're fairly new and in general you've picked it up very well) but I'm far too lazy to itemise them with long technical explanations. Anyway, that's all beside the point, you got the essence of it spot on. That was very fair.
You allured to it yourself numerous times but so many of the things you mention are being fixed in G4 which is available in increasingly stable alphas. You also mentioned the community which made me smile as given all the time I've spent answering questions I answered in the forum. :halo:
You didn't mention the biggest 3d drawback; the 3d renderer looks dull and washed pretty much no matter what you do in the shader... I was doing a solar system sim and I had to give up on night and day shadows in 3.x and redo it in G4. But my god does G4, look great. It just takes three times as long because I don't know it backwards...
Anyway, excellent stuff as i say.
I once tried making a RTS in godot, it didn't go at all well 😂 I am a programmer on the other hand, and mainly just found the lack of a good coding environment a big loss. I also wanted to procedurally generate terrain which appeared to be a nightmare... I feel a large portion of that was due to my inexperience at the time, and possibly lack of motivation to put the time into fixing the issues though.
what do you think about godot today ?
@@neolordie honestly, haven't explored much since. I mainly develop automation and data solutions, not games
@@Sancarn Honestly, anything that's missing in the engine can be solved with dlls, buffers, and extending the engine yourself. It seems like a lot has improved with the engine honestly though.
@@Faunarr Probably yeah, does complicate the build process of course, especially if you're building for multi-platform.
@@Sancarn right right. But at the same time. A build process is a more minor thing and only really requires you to get it right once before you develop and automate the script for it.
Multi-platform is definitely an issue that needs to be taken account for. But even so, its more of a one time logistical issue that can definitely be fixed. As long as you design the architecture for it well. You should in theory have minimal problems.
Oh and also, there's no shame in using other tools too. Such as blender for terrain generation. You don't have to do everything in godot. Hope my reply isn't annoying
There's this guy that's also really helpful with Godot called BornCG. He was my savior when it came to the Blender Game Engine years ago
Hey same here
relatable
yeah borncg was the only one that explained what he was typing and made me understand the fundemantals, unlike other tutorials that give you the code but you just don't understand a thing.
Eloquent and articulate. Impeccable delivery my friend. Truly
Unity currently made a lot of awful decisions that only made my decision to switch to Godot even better. I like that I don't have to install package this and package that and package everywhere and URP or HDRP or this and that setting in Godot at all. Godot is just complete right at the start without needed to be added together manually. It also has a lot of comfort features both UI and programming wise that make the necessary code way smaller in comparison to Unity. I don't have to code up a ray cast function for a wall climb mechanic in Godot at all, but just can say something like "on wall" for the If part, and it understands what I want it to do. My second indie game is being made with Godot. Hopefully this time It will be a success. It's also great that a lot of nodes are specialized for all sorts of different, often needed features. I don't have to code up a scoreboard manually, but can just use the dedicated score label node and a bit of code for that.
Lifting a rotting log.... THE best description for changing Unity prefabs.
About scripting: you get used to writing code without auto completion over time, it's not a big deal. In my opinion, writing without fully statically analyzed auto completion forces the coder to be aware of parameters of the functions he's calling and what they do. Yes, it's more troublesome to write code, but it forces you to understand your code more thoroughly
I disagree with the idea it forces you to understand code better. It's a time-saver ultimately, and when you have hundreds or thousands of lines or code, that simple time saver can shave off a considerable amount of extra work. Having a good autocomplete that works as it's supposed to is just a basic quality of life at this point. If you're only making small projects, you might never notice it's gone, but with larger projects and more scripts it's a nightmare to be without it.
@@Crystan No it's not easier. Auto completion doesn't work with dynamic languages very well due to the dynamic nature of those languages. For example, just look at documentation of jQuery, you can see many different ways to call the same function. It's very difficult for auto completion programs to hint those many different ways to structure function parameters. The best it can do is link the man made documentation for you, but you still need to read much more than you could have if you were using a static language.