Hey jeanfabre your comments and forum activity are amazing, thanks! :-)
And that's fine that data gets overwriten because if your FSM responds to both, it means it would switch states and therefore context, so it's a very important rule that event data is processes as early as possible in the state stack, preferably in the very same state that implemented the global event. in that regards, event data from a previous events would be very confusing actually because the FSM moved on to a completly different state and flow.
I think you have misunderstood my concept: Each event is packed with its relevant data to one message/object/event/packet. So when an event happens the waiting/listening FSMs do not get informed right away. Instead the message/event (including the data!) is pushed into a messaging-queue. The call to the queue returns immediately and the sender can switch state or do what ever it wants. The events are then processed in another iteration. This concept is described in "Games Coding Complete" (by Mike McShaffry). I try to give a picture:
Involved Objects:
* Global Messaging System handling the event (+data) and the queue
* Player (holding a gun, what else?!)
* Enemy (running in circles)
* SoundManager (wondering why the world is so cruel)
Now the Player shoots. The Player object creates an instance of an event called "PlayerShot". This event is a class and has its own clear and type-safe definition. It includes the Player ID, the position of the player and the weapon type used for the shot. This event is handed to the Messaging System (MS), which pushes the event (+data!) into a queue. After the call to the MS the call returns and no other code has been processed yet. The Player reacts to the shot himself and plays some animation and checks for current ammunition etc. Then the rest of the Player's code is completed and other objects do their stuff in their Update() method, eventually pushing new events with their own data into the queue of the MS. After all those objects have been updated the method "ProcessEvents()" from the MS is called. The events are taken from the queue, one by one, being in the correct order of their appearance, and the listeners (we could call them observers, because its a similar pattern here) are notified by calling the method "HandleEvent(IEvent event)". The Enemy is such a listener and determines the type of the event (this can be tricky in C++ so that it is sort of type-safe, but with little dependencies to lower compilation times) and reacts accordingly by checking data like the position of the event, he might be hearing the shot and wants to take cover or uses the information about the weapon type to switch to an other, more efficient tactic. In the methods handling the event new events can be pushed into the messaging queue, but this time in a new one, because the MS uses a DOUBLE BUFFER queue. After the Enemy, the SoundManager (another listener for this event) is notified and takes the position from the event for some 3D sound effects, also taking the weapon type into account.
When the queue is empty, the Messaging System swaps buffers and processes the other queue. There is no difference to the first queue! This double buffer queue simply offers the ability for the programmer to limit the processing iterations per update loop.
The advantages of such a systems are:
* The code is very clear and developers can follow the code easily and the debugging works like charm because there are no calls to completely different objects where the programmer doesn't know how the listener reacts. Instead, the programmer knows "ok, I've sent my message, everybody interested in it will do something, not my problem anymore"
* The events carry all important information with them, similar to a snapshot of the time when the event happened. The shot from the example above happened with a weapon type at a position from a player, and nothing will ever change this event.
Yes. It's good analogy, PlayMaker events are really methods actually. I guess this comes from the fact that PlayMaker events adhere to the "FSM" meaning of "event".
At first I thought that Playmaker uses events, but now I realize that they are no events in this sense. You are absolutely right, when you see Playmaker as a system for FSMs only. But in the last projects, I was involved in, I realized that FSMs are not enough for a stable and decoupled system. And a messaging system seems to fit perfectly into the system Playmaker offers right now.
I created a system where you can pass more data to events.
Thanks, I will take a look at your scripts. :-)
So if you have a use case, let me know and I'll do a unity scene trying to solve this elegantly.
Is this thread the right place? Should I open a new one, but what would be a useful title? Maybe "Playmaker FSM design discussion for a larger game project"?