Wed, 05 Oct 2011 17:14:24 GMT
Progress! Signals and stairs and solidity overrideI'm not sure which of those I'm most excited about, but probably the solidity override. It's not tested yet, but when it works properly it means that deformable terrain is possible, in true roguelike fashion.
Stairs are pretty simple now; all I added was the player position on ascending/descending - this part's still broken, actually, but I think it's just the usual tiles vs. real coordinates kerfluffle. I should really standardise this at some point soon.
Finally, Signals are an event framework. What this means is that instead of, when something happens, having to write functions that pass parameters around and around to all the things that are interested in them, I can just fire off a signal (event) and have all the interested parties be alerted and take action as appropriate. This just keeps code much cleaner and more intuitive.
The best example for this is exactly what I'm using it for, combat. Before signals, I'd have to call: creature hit; creature doing the hitting; splatter emitter; kill checker; noise propagation; terrain deformer; and maybe even more as I keep adding features. Each of those would have their own needs and data requests to keep track of, too.
With signals, I just say "a combat action happened" and everywhere I put a "listener" I add the appropriate action. Since it's a universal signal this also helps me figure out a universal set of data needed for the event - in this case I send along an event type (like say PHYSICAL_COMBAT or DIGGING or EXPLOSION) and the elemental type resulting from the action (PHYSICAL_HIT, FIRE EXPLOSION, ICE ERUPTION, etc). So far that seems to be all that's needed ...
I can't wait to add signals on signals :) Can you say possible chain reactions? I know I can ...
Stairs are pretty simple now; all I added was the player position on ascending/descending - this part's still broken, actually, but I think it's just the usual tiles vs. real coordinates kerfluffle. I should really standardise this at some point soon.
Finally, Signals are an event framework. What this means is that instead of, when something happens, having to write functions that pass parameters around and around to all the things that are interested in them, I can just fire off a signal (event) and have all the interested parties be alerted and take action as appropriate. This just keeps code much cleaner and more intuitive.
The best example for this is exactly what I'm using it for, combat. Before signals, I'd have to call: creature hit; creature doing the hitting; splatter emitter; kill checker; noise propagation; terrain deformer; and maybe even more as I keep adding features. Each of those would have their own needs and data requests to keep track of, too.
With signals, I just say "a combat action happened" and everywhere I put a "listener" I add the appropriate action. Since it's a universal signal this also helps me figure out a universal set of data needed for the event - in this case I send along an event type (like say PHYSICAL_COMBAT or DIGGING or EXPLOSION) and the elemental type resulting from the action (PHYSICAL_HIT, FIRE EXPLOSION, ICE ERUPTION, etc). So far that seems to be all that's needed ...
I can't wait to add signals on signals :) Can you say possible chain reactions? I know I can ...