 This video was brought to you by my Patrons, thank you so much for your support! Godot Engine has tons of nodes that solve all sorts of problems, from rendering an image to handling collisions. Nodes give us the base we need to achieve all sorts of games. Yes, even that MMORPG with GTA racing mini-games for children generated words and microtransactions you've been dreaming about. But there is a saying from Vilfredo Pareto, an Italian engineer and economist claiming that 80% of effects come from 20% of the causes. I don't believe this is necessarily true, but there is indeed a high correlation. So instead of trying to understand and master all the nodes Godot offers to us, let's use our energy smartly, and let's focus on the 5 nodes that, in my experience, are the ones with the most potential, the 20% that can build 80% of a game. Let's start with buttons, those little widgets that are easily triggered by players. A fun fact about them, they were what made me change from Unity to Godot. Back then, Unity didn't have the UI system it currently has, and we had to draw buttons and all sorts of interface related stuff by hand using code, and it was a mess. When I saw the button node and I realized that it simply worked out of the box, I was completely hooked. Anyway, buttons are very important for all kinds of games, and there are even some genres that can be pretty much built literally 80% just with buttons, such as clicker games and idle games. Buttons provide a simple and effective cause-effect functionality. You can use the button up, button down and press signals to trigger all sorts of events and create all sorts of mechanics, especially for mobile games, not to mention their role in menus and other UI elements. Okay, this one is one of the best. Tile maps are amazing, simply because besides they were designed to be used together with a tile set resource, thus behaving like a tile map, they have all the tools we need to use them as a high-level abstraction of a grid. They can map positions easily using their word-to-map and map-to-word methods, meaning they are perfect for a cell or rather tile-based movement. We use this extensively in GDQuest for our RPG projects. But not only that, they are perfect for match-tree games and other puzzle games, since they are basically a grid is easy to store a dictionary with a vector 2 key representing a cell, x and y position, and then you can assign an object in order, whatever, as the key value, meaning that you don't need to do a 2D matrix by hand and sync this matrix with the game's grid. You can keep this responsibility with the time-map node. Time is one of the trickiest things to work with in games. It can be the difference between a real-time strategy and an idle strategy game. It is also used as a threshold or a limit for certain game design protective mechanics, such as a carrot jump, input buffering and more, not to mention power-ups and other in-game effects. The timer node is so simple yet so useful, but most people don't notice it and go straight into reinventing the wheel. When I am wandering on good old projects on GitHub, it's very common to see something like this. This is a perfect valid approach, but just so you know, there is a node specializing in handling time-based events, and with the time-out signal that timer node has, you can pretty much do this with no effort. Now we reach what I think is an absolutely most-have-for-action games, detecting overlapping objects, and for that, GitHub provides us the error-to-denote. Detecting if a player is in contact with a predefined area in your game is a very essential ability, especially to trigger events based on players' position in your game. From portals to hitboxes, ambience like having a cave, or if the player is underwater, checkpoints, boss pits, and many, many more. All of these can be achieved very simply with good old error-to-denote, but there's something else very interesting about these nodes. Errors can be used to detect input events that happen inside them, so for instance, to make a system where you can select an object in your game, you just need to simply use the errors to the input event signal, and see if the event was a mouse click. If so, the object is selected. Okay, I think we picked here. This is the most incredible one, a tool so powerful that I would risk to say that together with a trigger, maybe a button, a timer, or even an error-to-denote, you won't need to code in your game. Of course, your game will be very limited if you decide to do that, but it's possible especially if you want to build a prototype. We are talking about the animation player node. In Godot Engine, with very rare exceptions, you can animate pretty much anything, from objects' properties to function calls. This means that to create a chain of events, turning on collisions, opening or closing doors, moving obstacles, casting nobilities, and even creating whole cinematographic scenes, you just need to play an animation. I just can't express how powerful it is to use animations as drivers for in-game events. With the way Godot implements animations, they can very easily be the primary layer of programming. They can be the 80% of effects caused by the 20% of causes, the later being the triggers, which can be fine-tuned using GD script. One of the few limitations of using animations currently is that they can dynamically access and use values. In other words, they won't use the value of the property you are animating, as it is in the time of the animation is called. So once you animate the values, they are deterministic. They will always be executed in the same way. This is changing for some properties though, with the newest root motion addition, which allows for instance, instead of animating the position of a character, you can offset it by the animation's values, which makes so that the character can move in the world with zero lines of code. These are the nodes that I think that once mastered, allow us to achieve 80% of the games we want to create. Not alone, of course. It is necessary that we also master the parent classes, such as node2d, control, and especially and most importantly, the very node class. And of course, other supportive nodes, like the sprite, label, audio stream player, and particles. That said, what do you think? Do you have a different top five? Leave a comment below if you would change anything in this list. That's it. Thank you so much for watching. Keep developing and until the next time.