Hi, I know this question has been asked a few times before but I just need a little help with clarification. I started my first project, made a lot of direct references and eventually learned my mistake. I’ve since tried to remake it with Signals in mind. That’s mostly worked out well, my game now runs faster and more compact.
The issue I’m encountering now is, how do you access data from a parent? As I understand you should be less inclined to signal down, and I understand you can send parameters through signals, but I’m not quite sure the best way to go from there.
So I adopted a autoload “SignalBus” type system where the Main root listens to common signals and makes things happen, but now I want a child instanced at runtime to access data that I want to keep track of. I don’t know how many instances will access the data.
I want an instanced child to grab a common data from an array, make it its own, and makes changes to the array.
In summary:
Instanced child(unknown amount) > wants access to an 'inventory pool'
> adds or removes item from pool
Is it…
Child signal (resource request) to parent > Parent receives signal(func(resource)) >
func(resource):
Signal(resource) back to child?
Then child makes its own function? That doesn’t seem like the best way. Both ChatGPT and DeepSeek say just reference it when you instance the child, but I’m not sure if that’s scalable as I won’t know where the instance will be when it needs the resource.
You can store inventory in a autoload/global, or you can declare the common data as static within the script. Signaling back and forth is usually shows that you could call a function or directly access a variable instead.
I see, it’s such a small project I think I might just do a global again. I was just having fun with signals I wasn’t too sure about their use in this case. I will look into the Static option, but that will be a new unknown object for me.
The mantra I’ve heard (and generally obey) is “call down, signal up.” A well designed node generally knows little about its parent / owner. A signal is perfect for this situation, as it allows a child node to say “Hey, something interesting happened, if anybody cares.” They allow a many-to-one pairing between responders and events, and scale well even to complex scenes where parent nodes at several layers may subscribe to a signal. Whether nobody subscribes to the signal, or a dozen different nodes do, the node will function the same
Going the other way, there is an expectation that a parent node knows the state of all its children. The parent typically will configure and/or instantiate its children in its _ready function. For instance, a Car node will either instantiate four Wheel nodes (and store them somewhere), or access them directly from the scene tree (using GDScript’s dollar sign syntax) where they were instanced as named children. Here, you generally don’t use signals. it is completely appropriate for Wheel to expose functions and parameters which are intended for the owner to use. So Car creates a few Wheels and calls front_left_wheel.spin(), or sets rear_left_wheel.tread_wear = 0.5
If you want the parent to access specific info from the child, it can just go ahead and access it. Sometimes it helps to set up an interface, or use set/get functions if the child needs to do some calculations to produce useful data, or emit some signals as a side effect.
Basically, you don’t want the child to query the parent for information. You want the parent to configure the child and to tell it whenever its state changes. The child just operates on its local state. If you want the child to reflect some inventory state stored in its parent, you can give it a update_inventory(new_inventory_state) function, or something along those lines, and have the parent call it in the event the inventory changes.
This kind of carries along if the inventory is a global. You have functions to update the state (e.g. add_item(inventory_item)) which update the state and emit an inventory_changed signal that other parts of the game (like the GUI) can respond to.