PlayMaker Feedback > Feature Requests
IF- statement action
troubleMaker:
Hi,
Maybe this has been proposed already, or maybe it's even implemented already somehow - i don't know - but it seems that Playmaker really should have an IF- statement action. I know there are bools and some actions allow you to store the bool without leaving the state while others allow you to check for the bool, so you can sometimes do kind of IF- operations inside a state.
But i think it would be really cool if you could have an action, which would check for a bool and if(and ONLY if) it is the preferred value, it will perform the next action(or even a number of actions) in the sequence. For me at least this would boost the already powerful Playmaker to new heights.
Also could we have some color coding in the action sequence editor, so you could sort of group actions together for yourself.
Sjones:
Just a few days ago I came up with a similar idea, however If statements do not have to be bool values.
So my idea is to have an if statement that you can select a variable type (or possibly even just an if statement for each variable type) with all the related options from == <= >= != etc. (or maybe allow a custom expression)
Further to this, while the FSM's are great, they can get a little messy and you have to split them up for tests so you can go either way of the result, the if and else.
Taking a page out of normal coding and unity itself, how about a completely new/different system, where if statements will go into a hierarchical structure, if the statement is true then it will do the child actions and similarly have an else statement child actions.
Then just continue with that state with what ever actions are left.
I would find this very useful to cut down on quantity of sates used in an FSM that just need to do an extra step or two if something is correct. instead of doing the first part of the code, then have 2 more states one for the true and false of the if statement and then a 4th state to do the rest of the logic.
With the if statement proposed above this would cut it all down into 1 state, while it has its disadvantages that you cant see the flow logic as easily and that the code/actions within the if statement cant be re-used by other states I think it might be useful for more advanced users and make things cleaner for many different FSM's
I have not updated playmaker in some time due to fear of breaking my project so was not sure if something similar had already been implemented, however as this is a recent post I am assuming it hasn't.
jeanfabre:
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.
Bye,
Jean
Broken Stylus:
--- Quote from: jeanfabre on May 27, 2014, 07:06:17 AM ---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.
--- End quote ---
Admit it, you want it. Say it. >:D
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.
Broken Stylus:
To quote Jean from another thread:
--- Quote ---Thanks for contributing, but I would suggest one thing to avoid the typical issue with this types of actions, what if you want yet another if statement....
--- End quote ---
That's true that actions, precoded as they are, simply do not allow the user to add more if-like elements.
The coder changed that by allowing the user to add more statements but the gain is almost null since this can already be done with conventional actions within a state: in the end, they still drive the flow out of a state into another one.
The controversial topic is about using ifs that drive the flow inside the state, from one point to another point inside the state.
Navigation
[0] Message Index
[#] Next page
Go to full version