Signals vs Immediate Scripts - is this a preferred method?

[jbwb]

In this lecture for the challenge I attached a script to my button and used the _pressed() function directly, because I thought that seemed quite sensible.

The instructor, @Yann_Burrett used a signal to a script attached to the parent node, GameOver.

Could someone explain why this practice is the preferred method?

These are my thoughts leading up to this question:

Previously, @Yann_Burrett offloaded the animation code, specifically to isolate code that only dealt with animation, not player movement, to a separate script. In this situation we appear to be doing the reverse. So why do we want to signal GameOver that a button has been pressed, and not just script the TryAgain button functionality directly?

Thanks!
John

[GrossePistache]

Sorry for my bad english.
One of the best feature of Godot is the simplicity to use signal to control your game logic without calling method on different node… Let me try to explain, in this case, there is only one node who will react if you press the button… but imagine you have a lot of game mechanic behind … and when you will press the button it will need to add/remove/reset some data inside a lot scripts. You will only need to call a single signal to make this happening instead of calling a lot of function on every node.

You could use a script on the button node instead of the GameOver node, but I think it’s okay to use the parent node to control the game logic in this case.

[DerTee]

Hmm, I don’t quite get it …

A signal can only be connected to one single function, so it’s virtually the same thing as calling the GameOver node directly. If there were multiple nodes that need to be informed by the signal, then you would have to send that information to them from the called method.

The only real difference I can find between calling directly and using a signal is that you move the event handling logic to a different node.
An example of where this might be useful:
You build some kind of trap node and instance it in a level node. Now you can connect the event of one trap to a door, the other to a spike that shoots up, another to a boulder that falls down.
That’s the benefit of signals as far as I can tell.

So in this specific case, it’s more or less arbitrary what you use, but I guess in general youshould prefer signals, because they are a little more flexible, albeit a tiny bit more indirect and less obvious to see in the code itself.
So if I know that this specific node really will only ever call that specific other node, then I’d just do it in code, without a signal.

I’d love to hear other opinions on this! Good question @jbwb!

[GrossePistache]

Yes, I think it’s good to call a function too, but I think the advantage of signal it’s keep your code more clean. (That’s my opinion)
A signal is more like a delagate in c#. It’s very useful when you know how and when to work with it. But I think @Yann_Burrett should explain more the benefit of signal over calling a function and when to use it.

[Yann_Burrett]

The main benefit is that we don’t calll functions in other scripts unless we have to. GDScript makes it very easy to call any function or variable from any script in the scenetree, which can be a debugging nightmare if the project gets big enough. Remember, GDScript effectively makes all functions and variables public unless we do some work with setget. Using signals allows us to set up the conditions for a signal in the node that’s responsible for that condition and the response to that signal in another node that’s responsible for that bit.

For example - Bunny runs into a spike. If we use signals, we can send a signal that triggers hurt() on the Player node without too much extra code. We don’t need to have a script in the spike that says Global.Player.hurt().

We could, but then if and when we run into a bug it’s going to be much harder to start troubleshooting exactly where the bug is coming from. Is the problem in Bunny’s hurt() function? In the spike script? In another script that also triggers the Player.hurt() function but is conflicting with the spike? It’s usually much cleaner to have each script and node responsible for only its own things and use signals (or groups) to communicate between them.