Making games, regardless of the engine, requires you to not just do what other tells you to do, but also understand why you got to do those and what each line of codes and each methods/techniques is meant for.
This universal fact might be the biggest challenge for anyone who try to make something in Godot, coding-wise, because unless you take proper course in programing, what you’ll learn from 1 tutorial will always clash against another tutorial, hence the trick is to find good tutorials that deeply explain what everything does at various levels. To give example, the various “e-school” around that teaches how to program in Godot (for a price) usually use the “Beginner”, “Intermediary” and “Expert” tag to define how deep in explanation the teacher goes. (Beginner basically covers the basics of C# or GD-Script most basics coding. intermediary brush over basic coding fast, but explain advanced tricks & codes formulas. It feels like you’re back in high school advance math with algebra. Expert is where the coding starts to get deep into the actual functions of the engine such as optimization and inter-systems manipulation such as advanced codes & shaders manipulations and such.)
Following & watching channels on something like Youtube can be a good way to learn, but as you’ll be learning from multiple people from various background and each have their own pros & cons, habits and all, it’s also a really hard thing to do as one might explain X is better while another might explain that Y feel better and you’re the only one who can decide by the end and something might break if you use X with Y or vise versa.
I know how it’s hard to force yourself to “stop there and try something different than what’s shown in the tutorial so that you fully understand what was explained”, but that’s how you’ll be able to advance.
If you just “copy what’s explained”, you’ll never be able to do much.
One tip I can give you regarding things like scene handling such as scene transitions is to know that you don’t have to close/load scene from the Tree() level. You can simply load and place scene as children of the Tree() level and simply “disable” scene unused that you know will return shortly later.
It goes a bit like this:
Tree() (top level) is an empty scene with a single Node with a script that has something like “SceneHandling.cs”. In this script, there’s the required code to load the first scene when the game opens, but also to load scene as children of this particular node. Whenever you change scene, you actually only enable a “Loading screen” node under this “Scene Handling” node which hide whatever happens, either “disable” or remove the child scene that is active (if you want to keep it to return to it later or if you want it gone from cache), load the next scene as another children of this node. If necessary (which is mostly is), you can then call some code from the top node of that new scene’s hiearchy to initiate/start/begin/load whatever you want in that particular scene.
For example, set the player in the right place with the right assets and setting the scene to know that the SceneHandling.cs parent has to be called with something like “LoadingIsDone()” function once everything in this new scene is finished).
So, in simple terms: Scene Handling node with a script enable some sort of over-everything loading UI/scene that hides everything, loads a new scene in. If it has to, it either remove or disable any previous existing scene. It call the new scene “handler” to load/begin whatever is required in the new scene. That new scene handler code, once it’s done with loading whatever, call back that Scene Handling Node with a function that tells it “I’m done!” and this allow this handle to remove the loading UI/scene from showing.
And there you go, you got full control of what scene/content gets loaded and unloaded. Your game technically never change scene, but instead change what’s in the scene dynamically. There’s no more any need to try storing tons of primary data outside of the scene since you can now cache anything in the top-level scene handler too. (For example, you can move the player character from Scene A to Scene B by simply changing its parenting while BOTH scene are still present during the loading process.)