SuperZazu wrote:
Yes, but that would mean that you'd have a condition each frame of the game update... Not so pretty, mainly if you have a lot of objects to test.
How is it expensive in the slightest? Chances are, it's just
function Player:isDead()
return self.health <= 0
end
Or similar. And when do you not have a condition every frame? How does this post even make sense? You still have to somehow check if the player is dead somewhere every frame in order to fire the event anyway.
SuperZazu wrote:
Yes, but that would mean that you'd have a condition each frame of the game update... Not so pretty, mainly if you have a lot of objects to test.
How is it expensive in the slightest? Chances are, it's just
function Player:isDead()
return self.health <= 0
end
Or similar. And when do you not have a condition every frame? How does this post even make sense? You still have to somehow check if the player is dead somewhere every frame in order to fire the event anyway.
Well, you do. But the player class takes care of the player, and the game state is just a big container of objects.
If you start checking if the user is alive in the game state, you couple the classes with each other. With a signal, you can avoid that :-)
I'm not gonna say anything for decoupling or against it, but for god's sake, don't blindly follow it if it makes things more complicated and more difficult for your code to weave through and understand.
But I'm not even saying signals aren't useless, just having a signal object that could only have one connection. How we got to this tangent is beyond me.
