> I suppose there could also be a "During Message" condition that would activate every tick that animation frame is showing too.
>
This is what I was trying to say
Fire an event = send a message. The event is On Message
Ah, okay
Only one event is needed, which fires as long as the frame is on (so that would be "During Message"). Why? because the event system already has "Once while true". ^^
Good point, using Trigger Once in conjunction would suffice.
Anyway, I was thinking about this whole messaging system a bit more... it seems to me that ALL game objects could benefit from it. In addition to the On Message condition for every game object, you could have a Send Message action. That way you could set up some very complex interactions between game objects very easily, and it would have the added benefit of making encapsulation* much easier. The fact that you could broadcast messages defined in sprite frames would just be additional functionality to the basic message listening system, a perk of the sprite object if you will.
*For those that are wondering, encapsulation (wiki link) basically means keeping your various game functions as separate and independent as possible. For instance, if you have fifty different sound effects that each need to play under certain conditions then you will be setting up a whole lot of +On collision between such and such -> Play sound, +If global(score) >= 10,000 -> Play sound, etc. conditions. This means your sound engine is dependent on knowing what the other objects in your game are doing. The thing is, XAudio2 doesn't actually ever need to know why it's doing anything. All it needs to know is when to play a sound, period. If you have a bunch of sound events that are all dependent on knowing what other objects are doing, like things colliding, player input, etc. then when you make changes to your collision or input events you could end up breaking your sound events and you've just doubled your workload because you have to fix those too. But if you have all of your sound events run off of message conditions alone, then you don't have to touch them when you're working on the collision stuff in another event sheet. By limiting the information that XAudio is dependent upon to work you've effectively created a stable, autonomous entity that can easily roll with any changes you make to the rest of your game. Additionally, good encapsulation practices can help immensely with debugging your game, since your events are streamlined and easy to read.
But anyway, yeah... I suppose I should bring this idea up elsewhere because now it's getting off topic