playMaker

Author Topic: When Sending Events, Is broadcast slower than Target FSM?  (Read 5710 times)

human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
When Sending Events, Is broadcast slower than Target FSM?
« on: September 20, 2016, 02:27:01 AM »
My project is made 99% with Playmaker, it's growing big. Now I can feel the time of Event Traffic.
I want to know the Logic of Sending and Receiving Events.
Please give me some instructions. Thanks.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #1 on: September 20, 2016, 09:42:50 AM »
hi,

 Can you precise what you mean by traffic? and explain your fsm designs as far as event sending? are you broadcasting, sending to targeted GameObject?

Also, what makes you feel it's slowing down? do you get missed events, or slower Frame rate?

I would also look at what is done upon receptions of your events, it's likely some actions that are performant sensitive that could be the source of the issue rather than the event themselves.


Bye,

 Jean

human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #2 on: September 20, 2016, 07:23:12 PM »
hi,

 Can you precise what you mean by traffic? and explain your fsm designs as far as event sending? are you broadcasting, sending to targeted GameObject?

Also, what makes you feel it's slowing down? do you get missed events, or slower Frame rate?

I would also look at what is done upon receptions of your events, it's likely some actions that are performant sensitive that could be the source of the issue rather than the event themselves.


Bye,

 Jean

Time Slow or Fast is a relative concept. Logic is much more important.
I've got an Example, A father GO got 10 Children GO, all 11 GO listener to a "DS" event, which send to the Father GO with the setting of "sent to Children".
The action to respond this event is "Destroy Self" with the setting of "Detach Children".
After fire the "DS" Global Event. The result all children will remain. Cause the Father Destroy itself and "DS" event won't pass to the event to it's children.
If I put a "wait" actions before fathers "Destroy Self", for only 1e-40 second. All children will destroyed.
So it's not about time.

I'm not a programmer, actually i'm an architect (design building) now design my game. I can read C# but not so deep.And English is not my native language, sorry for that, hope you understand what I typed.

During some simple test. I've Found that all the FSM using "Event Data(Info)" or "Event Properties" are using the same "Mailbox". Which I think may be a Static Class or something. So it could be overwrite by other FSMs during play.

So I have to refresh my FSMs to make sure every Event with "DATA" or "Property" is sending as soon as it set the property. And Receiver FSM Get the property as soon as Receive Event. No other Action should put in middle of this. Cause I've got a lot of FSMs talking to each other.

I think the "Mailbox" is Burning. Is there any Possibility to cause bug or data lose?

Directly Set FSM variables is not good i think. Cause I need the Sender FSM to sign its name to make sure the massage data is from it. And I can make generic FSM to answer for different Event Data. And RPCs have to use Event Data. 

Could I make Event Data or Properties with Event independent ones? Like FedEx Package? And with A queue Function to prevent Data lose?

(Now I use "Send Events every Frame" and Feedback event to make sure the Event be received. And Make some Buffer FSMs listener to RPCs to prevent data lose. )Which still got possibility for lose and performance threat.

Wish for Deeper Knowledge for EVENT THINGS.
 
 

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #3 on: September 20, 2016, 11:25:52 PM »
Hi,

 I see, thanks for the clarifications. your english is totally fine :)

In your first example, don't wait for a given amount of time, simply use "Next frame event", this is a very important action that saves you from all these trouble. having a wait is dangerous on slow Frame rate device, what if the user device has a spike that makes your wait timer shorter than the next frame call... you'll run into user bugs you can't repro locally. So never use timers for logic behaviours, only for animations and obvious use of time like a stop watch or something.

In a sequence of events that possibly will conflict due to the static and unique nature of event data ( you are very right about this, you seem to already pretty much know how it works internaly :) ), simply cut down your processes in frames so that there are no conflicts, that's all. I would not try to find a more clever approach in most cases.

Sometimes, when things get really complex. I force everything to follow a MVC pattern as much as possible and I use IOS native code patterns on how it names functions and communicates between various elements ( check out the "uGui Ios View Controller sample" on the Ecosystem for a taste on this).

for example I would have:

OnWillDoSomething ( "something" could be started the next frame by convention)
OnDidSomething ( could also be fired a frame later by convention)

if you send an event to an fsm telling it that you are going to do something, it has then time to adjust, and even cancel the execution of "Something" because it has a full frame to act upon this information ( provided that you are starting next frame). Then when "something" is done, you'll also get an event.

I think this kind of design pattern is something worth toying around, it has been working great for me, especially when dealing with UI and complex behaviours. you always want to firewall your logic from your UI views or visual GameObjects, it's a very good approach ( the MVC approach attempt in Unity is tricky, skip the model for example and have only an MV pattern) and will allow you within controllers to marshall these timing issue. You say it's not about time, I actually think it's all about time, about "timing" to be precise.

I have to admit I did tinkered with the idea of improving this "mailbox" thing for my event Properties set of actions to bind event properties with the event name, or the absolute time so that it's unique and never conflicting, If in your case, this would totally solved all your problems ( ;) ) I can build that. Just let me know. However, I don't think this is a all around solution and you will still end up with race conditions conflicts, because it only really post pon the problem if an Fsm down the chain of event relies on a data that's only set later during the frame since you can't control the order of executions between Fsms), you'll still need a "next frame" temporisation somewhere. It's almost unavoidable, even without PlayMaker. The nightmare of complexed initialization processes is there for any developers on any development solution. Unity for example has Awake, Start, OnEnable just to kick start a Component.. ouch... and we could win with more options in many cases :)




Setting directly variables to Fsm is appropriate if you follow a strict convention. I call such generic fsm "Meta data" Fsm, and it sits at the root of My Prefabs typically. And so communication between managers and prefab instances when too complex to deal with with just events is done via these "Metadata" fsm, the name of the fsm is always the same, and the variables follow a strict convention, this way I remove the need for sending events for anything and everything.

As always, this only works if you are very serious about convention and document your project and fsm properly. Keeping a google doc or something is also a good idea to refer to it later on during long projects. If you know deep inside you won't stick to your convention, simply dont' try, it will be a major mess if you have to refactor, so this tip is really for advanced developers aiming for heavy projects.

 Last note. I would totally get rid of your send event every frame technic, this is really not the way to fix your issues. This will only make things worse down the road.

If you have some use cases, we could talk about them specifically? I am very interested in design patterns and discussing them is always good to get better at development. The overall structure of a project is critical.


Bye,

 Jean



human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #4 on: September 21, 2016, 08:37:58 PM »
Thanks. Jean.

Now I realize that "Next frame Event" Actions is not just for a loop ::). It can be used as a dynamic "Wait" based on Processing. To avoid race between FSMs and make the sequence clear, some FSM should give a "Frame Wait".

I'm not a programmer, and not familiar about MVC. Just google it. It seems a structure that split jobs and make them work independently. Follow a convention could avoid duplicated work I think. I couldn't follow a Convention, Cause I really don't know one. But I make some "Pattern" or "Habit" to design my game to avoid duplication and complication. And I split FSM up to small one to get it easy to upgrade or Debug. (DebugFlow is great).

And about my send event every frame. It works like below. Receiver FSM uses closed sequence flow. I think Senders should not loop many times. It only resend the Event when the Receiver is Doing Processing Job and not in the Listening State.



human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #5 on: September 21, 2016, 08:45:44 PM »
Quote
Setting directly variables to Fsm is appropriate if you follow a strict convention. I call such generic fsm "Meta data" Fsm, and it sits at the root of My Prefabs typically. And so communication between managers and prefab instances when too complex to deal with with just events is done via these "Metadata" fsm, the name of the fsm is always the same, and the variables follow a strict convention, this way I remove the need for sending events for anything and everything.

Do you got some PM Example for this? I thinks this is a worthy design pattern to learn.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #6 on: September 21, 2016, 11:32:17 PM »
Now I realize that "Next frame Event" Actions is not just for a loop ::).

Well, and even for loops it's not a good idea, because if you have 100's of items, looping through them at 60Fps will take few seconds, whereas if you don't wait one frame, it's done as fast as possible.

 As for your sender/receiver process, I would need to see it in action to make some comment as it looks ok to me as you did it.

On the Meta data technic, check this post, it has a sample. Let me know if it still works ok, it's quite old :)

http://hutonggames.com/playmakerforum/index.php?topic=2534.msg11319#msg11319

Bye,

 Jean


human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #7 on: September 22, 2016, 03:06:24 AM »
yes, next frame event just to makes a big "every frame" toggle for several actions.
I've been inspired by your advice to  build a small "Next Frame Timer Combo" to split a FPS dragging work.
If the time is longer than the target FPS time per frame,it will leave the rest in the next frame to prevent a FPS drop.
Easy to add in a heavy loop, such as a Expolsion Sphere Overlay Loop.

And for some iteration loop actions, the loop must be finished. Or next time you enter it ,the index will start from last index. Which is annoying.

human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #8 on: September 22, 2016, 05:17:34 PM »
Quote
I have to admit I did tinkered with the idea of improving this "mailbox" thing for my event Properties set of actions to bind event properties with the event name, or the absolute time so that it's unique and never conflicting, If in your case, this would totally solved all your problems ( ;) ) I can build that. Just let me know.

Hi, Jean. I've find the experimental function of event queue. If we bind the "mailbox "with the event, and check the "keep delayed events on states exit" toggle. Will it be easier to Solve this kind of event missing problem?

human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #9 on: September 22, 2016, 05:46:40 PM »
Quote
On the Meta data technic, check this post, it has a sample. Let me know if it still works ok, it's quite old :)

Hi, Jean. I've study the sample. I thinks it takes a flag(maybe int or string for multiple events choice) and be watched by the processing FSM "everyframe", If the flag triggered the job, it can get the other FSM variables as input.

And I've got a question, Is there any possibility that "Set FSM Variables" don't complete at the same time, should the flag be set last? And If many FSM want to send and triggered the same Processing FSM, will there be Variables Traffic Jam? The FSM got the trigger and some Variables, and at that time some variables is changed by another Sender FSM before enter the next state?

If use array or something to queue the Variables and Flag, It will be much more complicated to Build a Generic Processing FSM,  some Array processing will be used. More difficult than "Get event Properties". Will there be some New Actions to do this?  ;D  and New Actions for Event things, Which may looks the same.  ;) We don't want to know how you do that, Just easy and happy to use.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #10 on: September 26, 2016, 01:22:45 AM »
Hi,

 I would not rely on the option to keep delayed event, it's really shooting yourself in the foot in the long run. But yes, it could solve your problem potentially, though I am sceptical about it being the proper solution :)

I don't think there are any plans to start queuing up data when facing race conditions. Queuing is such a complex beast that it's best developeed on a per case bases. you can totally do this using ArrayMaker for example. But be aware that it's only creating more problem inside your queuing system, how will you deal with concurrent access in your array or queue? implement locks is a nightmare, be aware of this :)

 so my suggestion still applies I think, make use of next frame event at a global level and consistently within your flow of events, identify what can be called in a single call, what needs to wait a frame, etc.

 for this a sequence diagram is best:



If you can first layout your processes, you'll surely find a way to avoid race conditions.

Bye,

 Jean

human890209

  • Junior Playmaker
  • **
  • Posts: 62
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #11 on: September 26, 2016, 04:47:50 PM »
Thanks, jean. Sequence Diagram is a new tool for me to Pick UP. The website is interesting.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: When Sending Events, Is broadcast slower than Target FSM?
« Reply #12 on: September 29, 2016, 12:45:38 AM »
Hi,

 yes, the free version is more than enough for you to work properly, so don't think you need all the fancyness for describing a workflow.

Sequence Diagram is really going to help you visual the process. Fsm visuals doesn't give you that just yet. Maybe such sequence diagram could be deduced at runtime for later analysis, that would be such a great help. There is a timeline that already give you a sense of sequence, but it's not organized the same way.

Bye,

 Jean