Requesting Guidance from Playmaker Officials and Experienced Developers

[Leecm]

Hello Playmaker community and team,

I am an artist-turned-developer, understanding functional logic but lacking hands-on programming experience. I have developed two games using Playmaker; the first is already live, and the second has recently completed testing. However, both projects have faced stability issues related to events not being sent as expected through SendEvent. These issues were not replicable in my testing environments, either in Unity or in the built versions. After an in-depth investigation, I discovered that the issue stemmed from SendEvent failing to find the target GameObject, which I temporarily resolved by introducing a slight delay (0.1s) in SendEvent.

I would like to seek advice from Playmaker officials and seasoned developers: Is it possible that messaging between FSMs in Playmaker might encounter timing discrepancies on varying hardware? How can such issues be preemptively addressed? Moreover, are there specific strategies or tools that could help me detect and resolve bugs that could impact the stability of my games before officially launching my second project?

Your insights and advice will be greatly valued as I strive to enhance the stability and overall quality of my games.

Thank you very much for your support and time!

[Roat1959]

Yes, it's possible for messaging between FSMs to encounter timing discrepancies on varying hardware. This can be due to differences in processing power, which affects how quickly events are handled.

[600]

I often put Next Frame Event after Send Event actions

[vladimir]

Instead of SendEvent, I suggest using Global Variables to share information between FSMs. This can be more reliable than event messaging, especially for simpler data.

[Broken Stylus]

I second that because sometimes, when the FSMs get heavy, it does happen that data associated to events can get lost or tangled with other the data of other events. So you need to add pauses and carefully plan your logic for sending events.

[jeanfabre]

Hi,

 I also use Next Frame Event in strategic places to make sure I don't send multiple events with data. I also would be careful with events triggering states that have actions that takes up resources, it can create similar issues.

Bye,

Jean

[Broken Stylus]

I think Playmaker 2 could really need to improve on that side and provide far more visibility as to what happens with events, whence they come, where they go to, when and what they carry at any time, any frame, etc.

Now I'm going to get back to a few earlier questions.

How can such issues be preemptively addressed?

You already found one by forcing a pause. Note that a wait with 0.001s will be enough too to shift operations by one frame.

There's a custom action called Next Frame Event Advance that lets you control how many frames you want to let lapse before sending an event.

Another one is to keep FSMs very small and eventually multiply them on a same GameObject.

Moreover, are there specific strategies or tools that could help me detect and resolve bugs that could impact the stability of my games before officially launching my second project?

Many analysis tools are already available within Unity now. The greatest difficulty is being able to understand what they output because it's not necessarily intuitive, but if you think your code properly ahead you will find that it's in fact very robust and barely prone to performance drops.
Truly, I barely encountered any performance issue with PM because I always kept in my hand to keep operations to a minimum, recycling objects in pools, deactivating whatever GameObject that really didn't need to keep running until the game needed it, etc.

Perhaps one thing to get right is the Garbage Collector, when to flush it and how big of a heap you can purge at a given time and under what conditions.

The other strategy is to play your game and stress-test it by doing all sorts of silly things that push it to its limits, like for example seeing how your controls react when you move very fast or press the same button many times a second. Play like a spastic monkey and really go jackass on your own game, you may quickly begin to find problems.
Same when you have to test physics and colliders and see if there's enough colliding tests done per second so that no object flies through a collider that should have stopped it just because it flew too fast.

Another obvious solution is to produce a build and have friends and family members test it on different hardwares and devices.