Excellent lesson, because this is way past a tutorial. You don't say "Don't do that, do this instead" you take the audience on a journey to improve overall understanding that's easy to extrapolate to other aspects of the engine. This is far more valuable than tutorials alone. They are important too and help to quickly to vault a wall but they seldom resolve the underlying issue of "WTF, why not working" Please keep up the dedication to this style. I really appreciate the effort and I'm certain others do too.
I'm a retired engineer and do Godot just for fun. But having worked as an IT Architect I do appreciate a structured approach and I think there are not enough videos about that aspect. So thank your for the work you put in in creating this very helpful video. Subscribed!
As a developper, this is what boggers me in other tutorials : spaghetti code and global variables that works for a couple scenes, but are unrealistic for a middle sized project. It's nice to see tutorials like this one !
@@andteam_lune A regular architect designs buildings and on a larger scale then subdivisions and the including infrastructure (water, electricity, sewer, etc.) connected to those buildings. An IT architect does essentially the same, designing standard hard- and software configurations, how those are installed and supplied to the end-user (incl. processes around it, e.g. how does and end-user apply for hard- and software tools, how does he get them, what happens if something doesn't work, ...). This is of course more important in larger companies, e.g. I used to work for Siemens and Nokia and the IT infrastructure needed to be designed and maintained globally in many countries for about 100,000 end-users. There it also becomes important, how it all connects to each other (sites within a country, then country to country), account management, security, VPN access (for those working from home), global services like a company-wide email system, etc. It's a big area and typically you specialise in one area and work together with many others. A very interesting job with challenging projects. Hope this explains it a little bit, I probably could write pages about it :-)
@andteam_lune like for buildings, an architect in software considers the structure of an application. If code directly references other code, then it's very difficult to move or remove parts of the code. Code that has these properties is often called spaghetti code because it's a tangled mess. It is also the responsibility of the programmer to avoid writing such code but an architect is responsible for the structure of the entire application, often by applying patterns that fit the needs of the application. A basic principle could be separation between horizontal layers e.g. frontend, backend and data provider, so implementation details from one layer doesn't restrict another. Maybe you want to use another database without having to change a lot in the backend. You can also have vertical slices to allow for a modular approach or to scale your application horizontally, meaning you can scale up functionality that has a high load, without scaling up everything else. These were just some quick examples, there is a lot of complexity in the details. Almost all patterns have benefits and drawbacks so it's important to fit your architecture to your needs. You don't need to complicate e.g. a personal blog website with a lot of patterns but if you're building a site like RU-vid, you need to be able to handle all the users without your hosting becoming too expensive. While architects spend most of their time considering these things, it's good for programmers to have an understanding of these concepts as well. Well structured code is easier to maintain. Poorly structured code gets more difficult and time consuming to work with over time. I hope this was helpful.
Probably one of the most comprehensible tutorials out there. There is a reason, a rationale behind everything: What is the problem? What is a solution? What are the limits of the previous implementation? How can we make it better? Everything is just super clear. You are a great teacher.
I know we live in a wonderful time, where we take for granted the internet is a thing, and information is "free"...but it's not. You spent your time to teach me how to do something that I've always wanted to do. I want to say thank you so much bro. Your time spent has changed someone else's path in life. ✌❤
I was thinking of starting a youtube channel just to explain these concepts since there really aren't any videos discussing these topics in a clear and "correct" way. But to be honest, the amount of work these kind of videos take, and my limited amount of time aren't really a good combination haha. Big congrats to you! This really is extra good quality content, and it is indeed much needed. No shade to the other content creators, but I do need to empathize the lack of good tutorials about Godot, and how much they are needed. thanks for the amazing content! Edit: I would even add that videos like these, are SO important, but take SO much effort, and the creator doesn't even really gain anything, that some money from the Godot crow-founding, should go into helping the creation of such videos. Again, congratulation! Amazing work!
I'm glad that this is useful. You are right these videos take an ungodly amount of time to make, currently it's about 1 hour of work for each minute of finished video. Which also explains why I cannot crank them out every week or so. I hope it gets better over time as I get more experience, but in the end if you want a good end result there are not a lot of shortcuts you can take.
We should have more Godot tutorials like this, that really explains how to make the structure of your game better in a more conceptual way, bumping first into a problem and then the solution for it. I would like to see paid courses with teaching style like this.
I just want to say I've learned more watching this than I did in 12 hours of paid-for tutorials. Thank you for not talking down to a newbie and clearly explaining concepts!
I really love your Teaching Style, the (I guess) AI Art is charming too! Please don't be disheartened by Views or anything, the Algorithm of RU-vid is said to even start really considering your videos after (I believe it was) 39 Uploads. I know that's a lot of Videos now but damn, I will watch every single one of these and like and comment on them too! This is the stuff I want to support where I can because it's what we most desperately need in the Godot Community now. We can't have more successful Indie games coming from Game Maker (Of all things...) than coming from Godot! Videos like this really help with this in my Opinion. The hardest problem to tackle with Game Engineering is softening the blow of the "Hard Brick Walls" of Game Development. There are so many hack tutorials for any given Engine out there but only so little Quality content that really shows you the way to think around Problems. Also there is so little Intermediate or even Advanced info out there. I'm usually not an Advocate of "Advanced Level Tutorials" as by the time one should use it, they should be able to gather the info by themselves. However offering that bridge, giving good practices and ways of thinking about problems will really go a long way. And this is exactly why we need you! You are probably even more important to this community than you may realize. You might potentially be more important than the People advancing the damn engine, as crazy as that might sound. Sometimes, it's all a butterfly effect.
Thanks a lot for this! I'm really happy that these videos work so well for you. I've spent an ungodly amount of time on this components video, re-doing it 3 times with different approaches until I felt it was somewhat coherent and it wasn't over 2 hours long anymore, so reading this really makes me feel it was worth it. Thank you! As for doing more advanced/bridge videos, I think the reason why there is so little about this is that they both require quite a bit of background knowledge from the viewer and are usually somewhat niche, so there may not be a lot of incentive to make those. I have a few things in my queue that would qualify as "definitely not basic" but I have not yet found a nice approach to ease someone into the topic who may be new to it that doesn't take 3 hours of explaining things first or alternatively just throwing the viewer into the deep end of the pool and leaving them with little value from watching. But over time as I get more experience in making these videos something surely will come up.
I can fully understand the incentive part. It's everywhere in Game Dev Tutorials too. If you've seen a Tutorial Series, the more episodes in you go, the more viewer-counts disappear, sadly. I, myself, wouldn't even know where to start with this, but I suppose teaching someone how to teach themselves could be a potential solution to this. How to get the most from Docs for example, assuming you don't really know what you are looking for is something I struggled with personally. These always lead me to google, sometimes to not satisfactory results. I'm glad to hear you got the message though, it was well worth it to me but knowing the amount of time it took also deepened my respect! Did you write a script for the whole Video? I've found, while a hassle at first, they compound into sparing a lot of extra work. But I'm guessing you already do that and hey, if not, this might mitigate some of the problems.@@godotneers
@@hiiambarney4489 yes i wrote a script for the video, actually i wrote three. after the first one was written, i started filming and doing the first animations. Then i realized this would take way too long, so I needed to cut back a lot on the animations and also streamline quite a few bits. So I wrote the second script and while this was better, I felt that the final product was not as corehent as I thought it would be when reading the script. So a third script materialized where I reordered a few things, also dropped a few more parts of theory that would hopefully explain themselves when showing it (show, don't tell;) and the third script was born. Since I was busy with other stuff I had to record it in several takes (which you can see in the date stamps in the task bar and also sometimes hear when the voice changes a bit). And finally editing it is always a huge timekiller as I have to cut out all the pieces where I misspoke or rambled on forever or had to take the occasional re-shoot when I missed removing a thing from my trial runs. So I definitely learned a lot when making this and I hope this whole process will be smoother as time goes on. I'm also not really happy with Camtasia for editing, while it makes it really easy to control things like the mouse cursor and adding these speech bubbles and other annotations it becomes really sluggish to use once you go over 30 minutes. I'll evaluate a few other options and see where I can get from there. If you have some tips for me they are more than welcome!
Wow, I think you probably make the best Godot lessons/tutorials available today. Just truly excellent explanations for how Godot really works. Thank you!
This is one of the best tutorials in godot. This tutorial teach me to build something, not just following tutorial and not able to modify it. Please keep your good work sir. Thankss
I'm lucky that you started this tutorial series around the time that I've started playing with Godot! Out of all of the tutorial series I've seen, I think yours are the most clear and thorough. Thank you for your time in making them! Do you have any published games anywhere I can check out?
I am so glad that people like you exist. I personally have a strong background as a fullstack engineer and just wanted to have a look at gamedev. There is almost no video that explains the concept better than this one. I am a beginner in gamedev but not in programming and I felt completely understood. Providing such knowledge for free AND making it understandable is not a matter of course.
You have the best game development tutorials! In addition to being clear and complete with your information, I love the graphics you put on screen that really bring certain concepts home, and I really appreciate the speech bubbles that not only help reinforce the ideas, but also provide entertaining moments as well. Really stellar work!
Love your teaching style! Showing us the whole chain of "problem -> solution -> new problem -> new solution" takes more work but it really drives the point across, and helps me understand some of the ways I could reason about these things. Thank you very much!
Every Godot dev should watch this. Instantiating new scenes at runtime is a powerful concept that isn't apparent, and I loved how you demonstrated how utilizing signals can replace singletons/autoload scripts. Thank you!
From what I read of the docs, Singletons/Autoloaders are meant for determining global variables that aren't scene dependent. So you can have something like the players gold count carry over into a new level/world. If you had a single level, you wouldn't need to use them.
This is the best godot tutorial I have ever seen... Because is not a tutorial, it is a full lesson that covers a LOT of very important things. Great job and thank you!
Well done! This is exactly the type of content I'm looking for when learning something new. Tight, to the point and taking philosophy and pitfalls into account and blissfully free from "dude-in-a-room-with-coloured-LED-lighting-taking-up-80%-of-the-video-talking-about-other-stuff-and-or-today's-sponsors" ✨
I think The reason why this works is because it doesn't show you how to implement a certain system or mechanic, and instead shows applications of Godot for a feature that is universal for all games. It shows the fundamentals of a topic, and how you explore that topic is up to you.
Really great tutorial. As a slightly more advanced user I still appreciated how clearly it was presented and it reinforced a few ideas for me. I was questioning the autoload reference in "custom signals" section then you immediately addressed that in "signal relays", haha
Excellent quality. I particularly appreciated the large cursor, highlighting of key points, and breakdown of chapters. It feels like you put a lot of thought and care into this video.
(@38:56) No, absolutely don’t do this; use collision layers and masks instead. Collision layers will take the place of the groups, and collision masks tell each object with a collision layer what they can collide with; this is already handled by Godot, so your code doesn’t need to test an object to see what group it’s in. So make collision layer 1 for the player (tower), 2 for the projectiles, and 3 for enemies (here, the two fish.) Now you just define what can hit (collide with) what, using the masks. Since the tower can collide with only enemies, set its mask to 3. The projectiles can only collide with enemies, so it’ll also have mask 3 selected. Finally, the enemies can collide with projectiles or the player, so all the enemies will have both 1 and 2 selected in the collision mask. Much cleaner, and your code doesn’t have to test for group (set) membership, which reduces coupling.
Collision layers can indeed help with this a lot and in this case they will indeed simplify the code bit. So its another great tool to have in your belt. Thanks a lot for showing an alternative way!
Yeah, having re-watched this video, I can share my experience I just had a couple of hours ago, funnily enough. I was creating a System to display Cards to the player in my Trading Card Game. I was knee deep in "Spaghett", when took a small break from the matter. Sure I could sort my cards by ID, by Name, Ascending, Descending Order, I could Show all Cards available, which I decided to turn around, if the Player doesn't own them yet, all that displayed in 3D, no less... All that was a lot of work but in my pursuit of "an easy and quick solution, polish the stuff later" I created something that I already couldn't manage anymore. I wanted to add a feature where I can show only certain Types of Cards, for example "Support" and it broke me. After a while I figured out a way how to improve this, drastically and got a nice, to the point solution, which now let's me add stuff like a breeze, and it's crazy that I wasn't even far off the first time around, the program looks really similar, just shrunk in size actually... This story neatly ties into the end of this video, that's why I wanted to share. I learned a couple of lessons today: "Sometimes, to "get the pig to fly" is not a viable option. But if it's your only option, you should take it, see why it isn't working and perhaps this learning experience takes you further than you would've thought!" And also: "Keep to the principles. You want to solve a problem that you can't solve right away? What is the smallest part of the problem that you can fix right now with 100% certainty? Start there!"
Thanks a lot for sharing your experience! In my projects I have also gone through a similar cycle where just changing a small thing about how stuff worked suddenly made everything a lot easier. I definitely second the "do the smallest thing that works" statement, it really avoids getting stuck in analysis paralysis.
Gotta say, another great tutorial. You make an excellent teacher, especially when you demonstrate options. I can tell it takes a lot of work to make videos like these and really appreciate them. Hopefully your efforts for what you want to achieve pay off here. Also, I really dislike, not your fault, how much Godot uses strings for things. I don't know how they can fix this but it's very much prone to mistakes being made and can be very difficult to debug and fix since all the errors are at run time and only if you hit a certain scenario.
Yes the string thing is a bit unfortunate. With the new scene unique nodes and the changes they added in Godot 4 to make signals and functions first class objects which get proper autocomplete this problem was at least a bit reduced and the editor will now tell you when a signal doesn't exist. But in the end its a dynamic language with limited refactoring possibilities, so large scale refactorings are still not great to do in it. Which emphasizes the need for small, self-contained components which need little refactoring ;).
this is a brilliant introduction to how to break down games into approachable chunks, as well as how to get those pieces communicating efficiently. Great stuff
I don't usually leave comments but I absolutely love this channel. Every time I watch one of your tutorials I instantly figure out so many things about how Godot works and questions I didn't know I had get answered. Keep up the great work!
Tutorial seems intresting but at 2.41 i noticed you multiplied with delta inside a _physics_process(delta) function. _physics_process runs at a set interval time if i recall correctly so the values dont need to be multiplied with delta as it is already frame rate independent.
You can still modify the physics tick rate in the settings, e.g. to improve collision accuracy or save CPU resources. If you do this and didn't use the delta in your scripts, your whole game will behave in _interesting_ (read unwanted) ways. Therefore I always use it (except for physics bodies which will use it automatically under the hood).
@Godotneers, your videos are some the most informative and pedagogical out there. Always to the point and flawless teaching style. What sets you apart is the way you explain by using an iterative process, highlighting potential problems as you go. In my opinion this is far better than just going through a “do this then that”-approach that most tutorial videos use. Bravo! I hope to see more content 😊
Absolutely excellent tutorial, good content, very well explained, and perfect pacing and legibility. Thanks for making it, please make more like this !!!
Thank you so much for you patient and barebones instructions. Thank you for keeping it simple: 1 enemy spawner, 1 tower. So many tutorials would have added unnecessary complexity. I am so glad you didn't. I really appreciate your videos and the time, energy, and thoughtfulness you have put into them. Thank you very much!
Goodnight ! Excellent tutorial, I really mean it. But, in the part about "Detection with slide collisions" you said that it is more performant this way than using area signals, is that correct? Have you confirmed before? If so, I believe that the best way to pick up items is to use this approach and limit the use of 2d areas as much as possible, what do you think about that?
I think I could have been a bit more clear. What I was trying to bring across is that if you do a move_and_slide you already paid the cost for moving the character and calculating its collisions. The engine needs to do this so it can properly slide the character in reaction to collisions. So then one can just use the results for which the CPU already was paid for instead of slapping an area on TOP of it. If you put an area on top of your CharacterBody, the engine now has to compute both the move_and_slide AND the area. But if you are using the area alone (e.g. just a sprite with an area and no CharacterBody2D), this will likely be cheaper than using the physics body because the area just detects overlap and doesn't actually influence physics. If you have a simple collision shape like a circle an overlap can be calculate very quickly. All that is to say - don't worry about it too much. Use what works best for your case and gets you the results you need. In some cases combining a CharacterBody2D AND an area is totally a thing (e.g. if you have units that have detection radiuses). If you have performance issues, its time to break out the profiler to see where they come from. More often than not, it's not where you would expect.
Your tutorials are by far the best ones that I have seen, explaining very fundamental topics, that aply to many different problems. Keep up the good work!! Subscribed.
I know it's a tutorial, but the during the wrong way to do it part I was literally screaming SINGLE RESPONSIBILITY PRINCIPLE while you were shoving everything into the tower script. xD
I watched the whole thing, thank you for providing content about the right way to do things instead of just alluding to doing it differently in a production codebase like others sometimes do.
Many thanks for the outstanding tutorial! Can you please give some advice on how to make scalable scene variants? For example, you have created a large number of fish species with different parameters and at some point you decided to add a new node component for them. Is there any way to avoid manually fixing each object? As far as I understand, in unity such a concept is called "prefab variants"...
Coming from another engine, and I find yours videos very useful, thank you much. I hope you will continue to provide us with updates as Godot evolves very fast.
Great video, one question. For futher expandibility of the project is not better if in 37:00 the fish instead of calling directly themethod when collide it send a signal to an andler and the endler set the damage? is not easyer implement modification or status effect inthis way or it's just stack extra steps with no reason? yeah I answered at myself while coding. you can just implement status flags inside the turret no need of a third party. BTW I'm trying to code as hobby and your videos are amazing thx for your work. You really helped me making some progress, I was stucked in tutorial hell.
Is there any way you could provide assets w/these so I can follow along? I want to try and follow along on my own and it's kinda hard w/out the assets 😕
For being a non-native speaker, your voice has excellent cadence and the video is very clear and moves along nicely so it's always engaging. You have a talent for teaching. Very well done, subbed
Your tutorials have pushed my work and understanding so much further, but I am so conflicted about those commercial-AI-service-generated assets. I use them myself too for sketching out ideas but I dread the day where we have games flooded with oversaturated DALL-E assets...
Amazing video! I think its the best I've seen online since starting to learn Godot a few weeks ago! Would be great if you could do a tutorial for a game that uses a 2D tilemap where characters can move around the grid using AStarGrid2D. Figuring out how the characters, character movement, collision and attacks work with the tilemap has been doing my head in!
This is an excellent tutorial. I would actually recommend this as a starting point to any Godot beginner, despite its rather specific title. One thing I’m currently struggling with, though: at 30:25 you change the collision mask for both types of fish. I would like to set up a fish class that predefines this sort of thing. E.g. if you create a new fish, it should already live on the designated enemy layer etc. I know I can set the values in _init() and declare a @tool script so it shows in the editor, but the editor won’t reflect it in the individual scene, only when it’s instanced. Is there any way to achieve this?! Basically I want to extend CharacterBody and change some inherited default values. Thanks!
I'm a computer scientist working on my masters and find your videos to be incredible. Please keep it up. I've just been learning Godot for fun and your structure is so much better than all the other tutorials I've watched. You walk through each challenge and problem instead of just providing the answers. I've watched all your videos. Incredible. Thank you.
Quite a nice tutorial. The only thing you forgot is to add a "ShotGrinder" to destroy those shots because they will keep flying forever to nowhere after the game stops ) I personally don't like using physics everywhere (i would do some simple checks myself) BUT i believe it's important to show the people the power of concept "work with the engine instead of against it" )
Can I have a component library (database) and link these to objects if they are relevant to them? How would this be done? For example, I have a database with components relating to the various skills I have available in the game. My player can acquire one of these skills, just as an enemy can have them by nature. Is it possible to link a component to an object by code?
Hello. A great tutorial, especially for beginners. I'm not fluent in English, so I apologize for any mistakes. When I was learning about signals and the methods of implementing them, a had one question that is, isn't signal relay method expensive? It basically doubles the amount of signals that are being called whenever something happens to the scene/node, doesn't it? And after all do you happen to know whether it's more expensive to use autoloads' custom signals or signal relays? I find it interesting enough to discover the most efficient way of writing my code, although some people say that it's not the best approach for a novice. But as long as I feel that it's captivating, I don't see any valid reason to stop doing so, even if it takes way much more time to learn the engine. All of all, I would be really interested to read your opinions on my answer. Best wishes and keep up the great job!
Both ways will result in an equal amount of function calls. With the autoload whenever a fish dies the fish will call a function on the autoload and the autoload will call a function in the game script through its signal. With the signal relay, the fish will call a function on the spawner through its signal and the spawner will call a function on the game script also through its signal. So it's two calls either way. In general I would not worry about performance too much, especially not at this low level. I think it's more important to build something that is easy to understand and maintain. If you run into performance problems you can still use Godot's profiler to find out where performance is lost and then optimize the parts that actually need optimizing. More often than not the bottleneck is not where you would expect it.
@@godotneers Got it. Thank you very much for the answer. I generally understand the point of not worrying about performance issues until they show up, however as I believe, when one learns an engine, unless one's making a game for a Jam, it's more interesting to find and/or create effective tools in order to use them later on at some serious projects with medium/high level.
Sure thing. If you are into performance optimization have a look at the profiler, it's a great tool to evaluate performance and compare different implementations: docs.godotengine.org/en/stable/tutorials/scripting/debug/the_profiler.html
If you care about performance you should always use tests instead of relying on anything else like feelings and hearsay (even if the person answering knows something, the tech might change and some things become faster a month later etc). Do you think using signals is slow? Try spawning thousands of objects that communicate via signals then try the same thing with function calls through node references, compare the result and decide if the benefits of doing it the faster way are large enough. In practice you should always go with the easy to implement and maintain solution and only try to optimize things when you actually find your game to be slow as optimized solutions are often less flexible and highly specific which means they set your game up to be hard to modify and develop further. You want to leave your systems open for experimenting at the beginning and signals are great for that. Anyways, remember to write benchmarks to prove slowness before believing something is actually too slow.
Hands down, you make the best Godot tutorials I've ever come across. You go into such detail explaining every aspect of what you do in such a clear manner that the concepts just lands so easily. It's rare to come across tutorials where I have no lingering doubts, let alone where I'm able to stay awake till the end. I'm so glad I found this channel!
The theoretical knowledge presented in this video could also easily be applied to React components :) The principles stay the same even across the domains of web and game development
This is incredible! After finding so many useless step-by-step tutorial where sometimes even the creator doesn't know what they're doing, it feels like a fresh air watching you talk in-depth on high-level principles, and how to actually design games efficiently in Godot. I'm definitely putting this and your channel on my list of resources to learn Godot
I want to thank you for these great lessons. You are very clear in your explanation. There is one topic that I have tried to understand for some time. And that is networking and match making. If you take suggestions on topics. That would be mine. I do love your content and will be happy to learn all I can from you.
Great tutorial as always, thanks! Would be nice to have source code posted on any platform to mess around, as GDQuest does it. Start and finish folders, to follow along the video and to check if smth went wrong.
the tutorials are so good, and i feel silly for saying this since it's completely unrelated, but i wish you wouldnt use ai art :( i understand, though. a bit silly to complain about it now since its practically everywhere at this point, and its easy and cheap to use...
Coll stuff! Is it ok, that we preload and instantiate a projectile in physics loop every tic? Maybe it would be nice to move this operations to the timer to free some resources? (oh, a see it's done a bit later : )
Thanks for the video, you are the best Godot tutorialist I've found. You just taught me what contracts are and the usefulness of groups. I have a question regarding using components with objects that can change the game state in drastic ways, something along the lines of an ability in Valorant, League of Legends or Dota. Is it still correct to use components for these, when it needs to access almost every system in the game or is there a better alternative?
13:06 The reason the projectile is misplaced is because the scene he saved positioned the projectile relative to its parent (the top level scene node), but when he added a new instance, it was positioned according to a new parent (the tower). The issue would be avoided by leaving the projectile as a child of the tower.
praying to the ADHD gods i can watch this and not just leave it as an open tab. migrating from unreal has been tough and this is exactly the kind of thing i need
Awesome tutorial video! I'm on my 3rd week learning and creating my game in Godot and your videos really helps a lot. Thanks and keep up the great work.
Man, you are the man - this is so clear and concise! thank you - after researching paper books I have learnt that there are so many errors - in 99% of them. This video is a breath of fresh air! thank you.
This is great! I just want to add that the reason a lot of these ideas work is because we have an expectation for what each of these things are supposed to do. For example, our projectile hurts things. Once we know what our projectile does, it becomes a lot easier to ask questions like "hurts which things?" clear and easy to understand purposes lead to clear and easy to understand code (most of the time)
The ai art is super disheartening to see in this video cause you seem like you teach well. There are free art packs out there that woul be cool to see. Supporting the art community that is so important in the dev scene. Good luck out there.
Your tutorials are great! I'm a bit familiar with Godot 4 and when I started with it a year ago, I didn't find good tutorials. Yours are good. Happy to see new ones and learn new stuff.
