Very handy and clean way to have separate child scenes talk without have to load sibling nodes constantly. I never knew it had a pattern name, love ya work.
Your philosophy "Call down, signal up" makes a lot of sense of how to simply work through the use cases in your mind. I like how short, simple, and clear this video is. Here's a like from me! I also like how you mention when it's appropriate to add dependencies. Having the World scene have dependencies since it should always have or expect certain nodes but using signals for children that may or may not be used in such a world (such as if you have multiple worlds or they are used elsewhere) to just throw a "Hey, I did this. Somebody handle it." makes a lot of logical sense. I tend to work through these things myself, but it's usually not a clean method in mind like this, so this helps!
I believe you can also emit the signal with the syntax of `player_has_jumped.emit(count)` which is a bit cleaner than passing the name of the signal as a string!
So sure! That is something new in Godot 4. In my case I have the habit of doing it as it was done before in Godot 3, but without a doubt that way is better as we can avoid using a literal.
Thank you very much for the encouragement, yes, making a video like this takes many hours. It's a little difficult sometimes to dedicate so much time being TH-cam as it is but we will do what we can 💪
Observer pattern should really be object1.emit(someEvent), and object2.observe(someEvent, callback). This is more like getting access to both object1 and object2 and connecting them together in some unrelated place which kind of misses the whole point. I should be able to easily subscribe multiple objects to the same event in their classes by just calling some subscribe method.
1:32 this is not true, using signals is literally like: func _physics_process(delta): for o in all_objects: if area_collided_with_object(o): call_body_entered(o) # it more complex in reality, checking collision mask and layers, but similar it still continiously checking all colliders to understand when to emit signal
We are mixing concepts. One thing is that you are looking in each frame to see if there are collisions, another thing is that you are asking in each frame if there are collisions (to the component that detects them). With signals you avoid the second, not the first.
is it possible to do this through scenes? I have a player scene and I want to emit a signal to my main scene, but I have to send it through an autoload script for it to work.
Yes, of course, if both nodes are present in the node tree then it is possible to connect them to each other using signals, it is not necessary to use Autoload.
@@GameDevWDavid if 2 nodes are not present in the same node tree can i not connect them with signals? should i be using autoload instead or is there another method
🌟 If you enjoyed this video, you'll likely appreciate another one I made about the Command Pattern: th-cam.com/video/nWUngckUbe8/w-d-xo.html
Very handy and clean way to have separate child scenes talk without have to load sibling nodes constantly.
I never knew it had a pattern name, love ya work.
Thank you 😊
Your philosophy "Call down, signal up" makes a lot of sense of how to simply work through the use cases in your mind. I like how short, simple, and clear this video is. Here's a like from me!
I also like how you mention when it's appropriate to add dependencies. Having the World scene have dependencies since it should always have or expect certain nodes but using signals for children that may or may not be used in such a world (such as if you have multiple worlds or they are used elsewhere) to just throw a "Hey, I did this. Somebody handle it." makes a lot of logical sense. I tend to work through these things myself, but it's usually not a clean method in mind like this, so this helps!
Thanks for your like! And I'm glad the video was useful to you! 😊
I believe you can also emit the signal with the syntax of `player_has_jumped.emit(count)` which is a bit cleaner than passing the name of the signal as a string!
So sure! That is something new in Godot 4. In my case I have the habit of doing it as it was done before in Godot 3, but without a doubt that way is better as we can avoid using a literal.
I do also like this video about the observer pattern in godot!! Nice channel and very nice work 😊
Nice videos so far! I can tell you put a lot of work into those, so big kudos to you. Please never give up!
Thank you very much for the encouragement, yes, making a video like this takes many hours. It's a little difficult sometimes to dedicate so much time being TH-cam as it is but we will do what we can 💪
Dude that’s exactly what I was looking for, a nice intermediate example. I hope you keep making tutorial videos like this!!
Of course, after the previous video and this one there will be more videos on design patterns!
Observer pattern should really be object1.emit(someEvent), and object2.observe(someEvent, callback). This is more like getting access to both object1 and object2 and connecting them together in some unrelated place which kind of misses the whole point. I should be able to easily subscribe multiple objects to the same event in their classes by just calling some subscribe method.
You can, if you create a third script, a signal handler of sorts as an Autoload script.
Use that to emit and connect to signals
Very useful 👍
Thank you so much!
Would be nice to show other scripts registering with the master script. This reduces the child coupling. And allows for dynamic children as well.
And allows for a many to many relationship :)
1:32 this is not true, using signals is literally like:
func _physics_process(delta):
for o in all_objects:
if area_collided_with_object(o): call_body_entered(o) # it more complex in reality, checking collision mask and layers, but similar
it still continiously checking all colliders to understand when to emit signal
We are mixing concepts. One thing is that you are looking in each frame to see if there are collisions, another thing is that you are asking in each frame if there are collisions (to the component that detects them). With signals you avoid the second, not the first.
is it possible to do this through scenes? I have a player scene and I want to emit a signal to my main scene, but I have to send it through an autoload script for it to work.
Yes, of course, if both nodes are present in the node tree then it is possible to connect them to each other using signals, it is not necessary to use Autoload.
@@GameDevWDavid if 2 nodes are not present in the same node tree can i not connect them with signals? should i be using autoload instead or is there another method
@@nahouiramzi3449 if 2 nodes are present in the node tree, it is possible to connect them with signals.