I vaguely remember you mentioned a method that you use to decide what Node should have scripts or not, I have a bad habit of adding scripts to everything since I came from Unity, is there a good rule of thumb we can follow?
Thanks,
With the caveat that you should feel free to break from this convention when necessary, where I find success the majority of the time is by adding the script to whoever is the root node in the current scene that I am working on.
The reasoning behind this is that from there it's easiest to access all the children nodes and code the functionality that I need to get them to interact properly. I can always use the built in signals of many of the child nodes to be alerted when something is happening, but I'll try to handle that on my main script that is on my Scene's root node.
Now once you start composing new Scenes out of previous Scenes that you have built, you will naturally have more scripts up and down your scene tree. But I try to make each individual Scene "idea" to be its own self-sufficient, loosely-coupled object.
Don't be afraid to add scripts to child nodes if they need it, but before doing that a good habit to get into is thinking "well if I have a reference to this child on my parent node, can I handle what I need to do from there?"
Yeah I agree, trying to think of your script as a "behavior" of your componentized scenes.
In the chests and gems, you could look at it like. "I'm a gem, what are my behaviors? Ok, I need to move when I'm clicked on and dragged." So you'd create a script on the gem (GDQuest in this example already provided that as a helper)
Then thinking of the chest, what are it's behaviors "I'm a chest, I need to listen for when gems (or anything in this lesson) come near me and open up." That way of thinking generally helps me.
It'd be weird for the chest to look at and move the gems as one of its behaviors, and it'd be weird for a gem (or every other scene) to tell the chest when it should open. Though you might need to do it that way sometimes, it adds chest code into the gem script (or potentially others) which adds a bit more coupling.
I think the hardest part is that there's really a lot of different ways to make each specific game work, and sometimes it's hard to know which way to code it until after and you start using it and editing it and learn and build from it.