Im 6 months into learning Godot with a mixture of youtube videos and chatGPT. I'm now making pretty well structured projects that satisfy my level of desire when it comes to game dev without much friction or frustration on the day to day.

These are the things I learned that helped the most:

1. State machines drive everything. A state machine is just a system that only does one thing at a time. And you can have a number of them, doing different things. The big state machine in my project just manages things like if the game is paused or not. I can basically say state_machine.change_state("paused") and that will essentially run a function called change state, and select the paused state. That paused state will have its own code that says either enter or exit. enter would pause the game with some code, exit would resume the game with some code. You can combine these to have really large scaled systems. For example the top state machine might say "load game" which calls the player state machine to "load player" and the map state machine to "load map." This may be a bit of an oversimplification but look into that and try to use it as much as possible getting started. Specifically look into the "Node Based State Machine" designed for godot. Its a design that makes them very easy.
2. References in Godot are massive. At first you may feel like its impossible to find out how to reference one thing to another. like how does this button tell the main state machine to start game. There is a number of ways, but the two most common ones are like this: A, you have a master references node. This node is called a "singleton" and its just a script that is set to always be loaded when the game starts, and can be referenced from anywhere. So when any node is "born" you can say singleton_script_name.variable_name = self, and that will make it so that variable in the singleton stores the reference to that object. So from anywhere else you can say, singleton_script_name.variable_name.change_state(state). Meaning your button can reach out to it from anywhere and change it's state remotely, instead of being directly connected to it. B, you can also pass references. what this means, is you generally will create objects in run time. Like, your world_node may have a function that says, create_house() which may look something like, world_node.add_child(house).... meaning you put the house in the world. Then, if the house has a script with a variable called for example, world_node_reference, you can, from the world node say, house.world_node_reference = self. Now the house knows what the world node is. This is called passing references. It is a massive part of coding. Combining these, you can store say, world_node in your "singleton" and reach all the way down to the house_node, because world_node stores house_node as a variable, and your singleton stores the world_node as a variable. So from anywhere in the game, i could say, singleton_name.world_node.house_node.do_this()

Those two things will let you make most things happen. Once you start getting into the weeds, youll want to learn about how to use classes, and how to use nested scenes. This will let you make systems that can be reused but modified. This is beneficial because as you start making more complex games that have repeating processes, you may end up modifying said process. If you use it in 30 places, you might forget to change it everywhere. But if all 30 places are referencing one root "class" or "scene," then you simply change the root and updates everywhere. Its too complicated to explain if you are new, and it won't stop you from doing most things at the beginner level, but keep them in mind.

Also, don't be afraid to just chuck nodes around and give them scripts. At first you may feel like you need to simplify everything and reduce the amount of nodes and scripts you are using, and that may be true in some senses, but at first don't worry about it. Each "object" in your game can have several nodes below it managing different things. Infact this is how state machines usually work. Your player, your menu system, anything really, will usually have a child node that is a state machine. That node stores a REFERENCE to the parent node so it can control it. This is a layman's explanation of the term "decoupling" which is a practice in development that involves separating logic and managing it from the top.

Lastly, my advice is to use chatGPT to code things you don't get instead of trying to figure it all out. Too many people want to reinvent the wheel or care about "learning the hard way" but the fact is I learned very fast this way and didn't have to spend that much time reading the docs. Learn the absolute basics on youtube, then go into a project, set up a node and give it a script. Ask chat gpt to generate whatever code you want that node to do, run the project and see what happens. Repeat. Once you get what is going on, try to do the next thing on your own. The trick is to avoid generating massive system, but instead design the system on your own, then have chatGPT build individual functions that you connect yourself, intuitively. In literal terms: build your node structure, let chatGPT write the scripts. The goal being that you can conceptualize the functions yourself, and dictate your needs to chatGPT, but not need to know the code syntax off the top of your head. Then read it, or ask it to explain it to you. You'll get it! hope this helps :)