playMaker

Author Topic: IF- statement action  (Read 7760 times)

troubleMaker

  • Playmaker Newbie
  • *
  • Posts: 25
IF- statement action
« on: April 19, 2014, 12:16:45 PM »
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

  • Full Member
  • ***
  • Posts: 203
Re: IF- statement action
« Reply #1 on: April 26, 2014, 09:39:56 AM »
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.
« Last Edit: April 26, 2014, 09:56:51 AM by Sjones »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: IF- statement action
« Reply #2 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.


Bye,

 Jean

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: IF- statement action
« Reply #3 on: July 30, 2020, 10:54:27 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.

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

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: IF- statement action
« Reply #4 on: July 30, 2020, 10:59:58 AM »
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....

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.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: IF- statement action
« Reply #5 on: July 31, 2020, 01:28:11 AM »
Hi,

 In state flow control is indeed dangerous, and stretches the paradigm of a finite state machine.

In all these years, I have made similar requests to Alex to implement these kind of things and many more and I am pretty sure that if he had listen to me, PlayMaker would be long gone and discontinued.

 the genius of what Alex build is indeed based on strict rules and conventions, my opinion is that this is what makes PlayMaker so succesfull.

 the downside is for power use, I totally agree. However, it never was an issue to create brutally complex projects with PlayMaker, you just need to work with PlayMaker instead of against. same with Unity, it was so hard for me the first few month to have to attached a script to a 3d gameobject, coming from java 3d, or similar 3d engines where scripts and 3d are really separated, it was really tough... now I embraced it and I am hyper efficient indeed, and I keep getting amazed at how powerful this is once you embrace it. it has its flaws, that's why ECS is coming, but indeed one should not want to mix ECS and Gameobject/Component paradigm together. I think the same holds true with Playmaker FSM and other technics.

Having said all that, indeed I totally understand where you are coming from, and it's important that you express it, it helps shaping the future of PlayMaker.

Bye,

 Jean

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: IF- statement action
« Reply #6 on: July 31, 2020, 10:03:00 AM »
Well I was largely throwing ideas here. No system is perfect, there is always something one can find interesting or better in another system but not being sufficient in itself to warrant the jump to this other tool.

PM is already very good as it is now. It's literally a logical schematic made into computer code instead of a mess of nodes with multiple parallel flows inside the same FSM/nodeSheet. Therefore, one knows the flow is always in one place only. The drawback being things akin to "multithreading" and synchronization between FSMs but that's another topic (I hope PM2 has a transparent meta multi-FSM management tree in the pipe!).

I was attracted to this "IF" topic because no later than yesterday I again found myself in a situation where I had to duplicate a whole rich state just to cover a minor eventuality of a difference in value of a single var.
I was like... mmm you know I'd really really love to be able to filter this action based on that value and move on the next action instead of having to fork the entire thing, with an extra new event, because of one single var that represents perhaps only 6-9% of the state's data.
The state is "rich" in that it computes a group of actions that are thematically related and centered on a single piece of data, and I also find it easier to click on one state and then look into the Inspector window (I don't even have to scroll it) than having to drag the Graph View around and click on plenty of different actions and go back and forth between different states and check their events when they're all closely related to the same "topic".
Of course one should not push this too far because it could be possible, in theory, to cram a whole FSM into a few states instead of having more states all spread across an aerated FSM where each zone corresponds to a kind of task, to a theme that implies certain types of operations.

I also use String Compare Set Multi several times which is clearly a conditional system that allows to pick a specific operation to complete based on a given set of parameters; in this case, it's limited to comparing a string value to any number of other string values (the number of cases can be expanded), and then deciding what value to place into a targeted FsmString declared earlier on.
This is clearly an if / then system, but extremely focused on one var type, for one operation only: setting a FsmString.Value, following a series of comparisons. And the flow stays inside the state.
Obviously the possibility is there and above all it keeps the FSM very tidy and readable.
So, is this action really damaging the concept of Playmaker or actually making things faster? :3
« Last Edit: July 31, 2020, 10:07:03 AM by Broken Stylus »