hi,
that would defeat the whole strategy around what an FSM means. What's wrong with a state with two transitions "YES" "NO", or "TRUE" "FALSE", I do that all the time.
Yes, sometimes I would like an action to not perform using a boolean variable, that for sure would be good, but at the same time, SOOO dangerous... as much as I would love that kind of power, I think it should not be implemented ( just my opinion here ) and instead use sub fsm or a different way to organize logics, typically splitting into several Fsm.
Admit it, you want it. Say it.
Using sub-FSMs for simple if-thens is just overengineering this, especially considering the monitoring of vars and the transfer of their values from sub-to-host or the reverse.
If a sub-FSM could quickly be opened as a small window (like a sub-Graph View) within a given FSM, that might be interesting; it's a function I would not ignore as I'm sure there might be interesting uses for this.
But there's no such thing.
So since we're literally talking about expanding the Playmaker system from what it actually is, let's do this through and thorough.
I'm not even sure there would be so much of a danger if the UI properly delivered all the visual clues one needs.
The real risk is having a bloated state but that's on the dev's watch and any unruly dev can mess up a FSM too, make it complete visual nightmare. And isn't it what typical coders complain about? The visual mess of complex FSMs? The dreaded spaghetti effect?
I suppose that PM might court hardcore coders if it were more if / then friendly within states. They might want to use states as something like denser "groups" of actions instead of very simple and almost empty states containing few actions at most. After all, they keep complaining of the spaghetti effect and it is true that trying to emulate a series of if / then logical steps
outside of states instead of
within fewer states tends to increase the risk of this effect occurring.
I often find myself wishing for a little flexibility here because a little if / then system would allow to make a state richer without having to add a whole new blocky state in my little and neatly ordered FSM.
Perhaps if a state contained some such indentation or shortcuts, its own visual appearance should be
slightly different?
This mode could be unlocked for power devs.This raises the topic of
indented actions inside states.
On a similar topic, a state always starts from the top, scanning each action one by one based on their vertical position (order) in the state.
More experienced developers might want to be able to bypass some actions depending on certain conditions and directly target one. Essentially, since the if / then system would allow the implied top-down state-scan to jump inside the state (relying on implied "go to action" functions like one can "go to state" today), such as for example coming out of an action preemptively
but staying inside the state, it would take a little extra coding to push this function into an ability to literally ignore certain actions based on said conditions.
The conditions would range from variable values to specific entering events.
This shortcut ability, in the context of entering events specifically, could even be made quicker by literally allowing the dev to declare an action as the target of the incoming event that enters the state. Most likely, a rectangle with a little downward arrow right above the action's name (and therefore also right below the line that separates this action from the previous one) would show that this action is targeted by one or more events.
Obviously this would have to be shown both inside the PM Inspector side window and in the Graph View, showing a link entering the state to be conditional / shortcircuity (that it targets any action inside the state but the first one), by drawing its line (bezier or else) a little differently.