 Hello there, well, every project reaches the point where you start working with very complex systems. It can be a mess if you don't know where is that object you were working on. In this video we'll talk about how Godot Engine handled this with the amazing SYN system. To better understand what we've come, we need to first understand how we compose our games with Godot Engine. So let's talk about the SYN tree. The SYN tree is where everything begins. It is basically the tree of processes of your game, where you will state what will be processed in addition to the default backend systems. It is here where you will compose your game by using Godot nodes. From now on, I will be using a metaphor to explain it. By default Godot developers already gave some botanics related names, so let's use botanics as a metaphor to SYN tree. By default, a SYN always has a root node, which is hidden below what you can see in the editor. It actually has this name, root, and it's a viewport, since you will need a viewport anyway is there by default. You can access this node with the function getTree.getRoot. The first node you actually add to your SYN can be called trunk, when it's a main SYN, which will not be instantiated. This node can be called stem, when it's anything which composes a main SYN, or will be instantiated inside it. A trunk provides the structure for the tree, while the stem provides the structure for branches, which we will talk about later. After the trunk, you start to add branches to your SYN tree, and that's where stuff starts to get interesting. When you reach this level of composition in your game, you will start to think about breaking the complexity of your SYN, so that you can focus on a specific topic, solve it, and move on. And while Goddard offers to us the option to save a SYN as a branch, by doing so the node will be saved as a new SYN tree, therefore the base will turn into stem, since it's a branch composing the main tree. And Goddard will create an instance of this node in the SYN you are working on. From now on, you can focus on your working in this branch, every chain will reflect in the instance. This also provides an awesome tool to reduce the ability of your behaviors, since this branch is saved separately from the other SYN, you can now create more instants of it and use it in other branches. That's what I call graft, when you cut a tree branch and join it with another branch or even another tree. But that's not the only way to make a graft in Goddard, you can always merge a branch from a SYN. This means that you can take a branch or even the whole SYN and add it to another. This method will not create it as an instance, so if you change the original node it will not reflect in the merged one. This will allow you to reuse backgrounds, animations, parkour system and such, but independently. No changes on the original branch will be reflected. If you want to extend the SYN behavior, adding more complexity and specific systems, you can create an inherited SYN. When we do this, I like to say that we are using a SYN. Other behaviors, the DNA of the SYN, will be inherited. But now we can keep adding more stuff to it, while the SYN node will keep being updated with the SYN changes. This is called class inheritance in object-oriented programming and it's one of the most important concepts of this paradigm. The ability to create a base object with general behaviors and then create new ones from it with more specific behaviors while both levels of complexity are linked through a hierarchy of inheritance. But that's not everything yet. In addition to inherit a SYN and modify it as you want, without breaking the link it has with the template SYN, I call the process of modifying the structure of a SYN a mutation when it inherits a SYN. You can also do the class inheritance within a script and extend the script of the SYN inherited. To do this, you just need to pass a string with the path to the GD script of the inherited SYN and insert it after the extents keyword. By doing this, a link will be created between the scripts and every change in the print, the one which was inherited, will be reflected in the new scripts. This will allow you to decentralize some of the behaviors, just like if this new script was a branch of the inherited one. As you could see, the inherited scripts didn't have a single line of command but to extend another script. Even so, they have the same behavior. That's why class inheritance is so powerful. If you want to modify, add or even remove a general behavior, let's say, of all your enemies, you just need to do it in the base enemy class. That's all for now guys. If you have some doubts or if it isn't clear to you, leave a comment below. If you liked the video, let me know, leave a thumbs up and that's it. Keep developing and until the next time.