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