Hi,
What concept you actually don't understand? let me clarify the steps:
Say you have a robot. It has a root game object. Attach to this gameObject a fsm called "META DATA" or something.
Now every variable or property that define the robot should go there. Typical example: the robot is holding an object. You need a boolean flag to know if the robot is holding something: define this fsm bool var in "META DATA" like "is grabbing".
Now the claw that will detect and grab an object is a game object within the hierarchy of this robot. The fsm responsible for detecting and managing the claw will set directly the "is grabbing" bool at "META DATA". It will not host a duplicate of this property. You have only one variable responsible for this property. This is the key to remain sain over time as the project will grow. If several fsm keep their own reference to something identical, you will for sure run into variable sync problems as the spec changes or when it gets more complex.
Note that any gameObject can access that "META DATA", say your robot has a floating head not necessarily attached within the hierarchy of the robot itself, no problem since you can reference any fsm. My point being: it's really up to you during developing to enforce the right strategy and the right encapsulation of data.
Now, your AI wants to know at some point if the robot is holding something: all the AI needs to query is the meta data fsm attached the the robot root game object. Everything within "META DATA" can be read from external systems ( read: anything that is not the robot but needs to get properties from the robot).
new case:
Now if you want to communicate with the robot and tell him about the speed he should move at. You have two options, the easiest is to set the speed variable hosted in "META DATA" but that dangerous and not very efficient. it's dangerous because as your project will get more and more complicated, you will certainly loose track of who set this speed variable when it actually should not... not a pretty sight to debug, when you have 70+fsm... Instead you can create an event "SetRobotSpeed" and fill the float variable of the event data to the speed it should reach. Now you dont necessarly need to host this event in "meta data", you can create a new fsm for it, host this event, extract the speed value from the event data, and then take all the appropriate state to inform the robot and the various parts that need to know about a speed change. This is much better than polling constantly for the speed ( yet, sometimes it's simpler and easier, which is ok if it's something occurring almost constantly during your game loop).
The same is true if you want your robot to send event to the outside world. Say: the robot itself decided to adjust the speed: If you only set the variable, other elements of your world will not be aware of this change ( and will have to poll for it, not very nice in a game loop...).
If you instead use an event to set the robot speed internally, your fsm responsible for the speed variable received your internal event like "SetRobotSpeed" ( you can reuse the same event, tho be careful of infinite loop, use a different event or check for the sender so that it doesn't get back a speed change... since he's the one who initiated the change, that will not be good... ). Like so, you can in turn alert the outside world about a speed change like "RobotDidChangeSpeed" and conveniently set the event data float to the new speed value.
think of this like an interface layer hosting variable and catching events coming from the outside world as well as from internal parts. This is a sain approach, maybe not the fastest to implement, but a safer one. Playmaker give us total freedom, this is real cool but can be a very bad thing if not carefully constraint into something rational and logical.
Hope this is clear.
Bye,
Jean