Page 2 of 2
Re: Signals & Events Module [FREE CODE]
Posted: Fri May 29, 2015 8:54 pm
by Kingdaro
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
Code: Select all
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.
Re: Signals & Events Module [FREE CODE]
Posted: Fri May 29, 2015 9:13 pm
by SuperZazu
Kingdaro wrote: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
Code: Select all
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 :-)
Re: Signals & Events Module [FREE CODE]
Posted: Sat May 30, 2015 2:27 am
by Kingdaro
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.