playMaker

Author Topic: Improve your FSM design magic  (Read 11283 times)

waveform

  • Playmaker Newbie
  • *
  • Posts: 28
Improve your FSM design magic
« on: July 08, 2019, 08:49:59 AM »
I have seen lot people FSM looks like



or



The Fsm looks bad, fuzzy and very complicated.

That's why I have to write this topic to fix it

Cant wait anymore? Here we go:

1.
Improve switchs:
improve switchs is very important thing, people probably get lost then it comes a huge number.

Bad example:



to improve this need "go to state by name" from ECO system

Good example:



more exampel



2.
Use "Action sequence" to improve "Compares" and "tests".
im pretty sure compares and tests is probably the most used actions in your project, it ends up with a lot states, this`s not you wanna to see right?

let fix it.

Bad Example:



Change it to:



Example 2 :



3.
Reduce events use.
I have seen people use events for any thing and every thing, it end a huge number  of events to make project very difficult to debug and manage.

improve events use by reuse same event over and over again, it require a good namn such as: 0(for false) 1(for true or finnish).

if use unity events:



FSM setup:



4.
Split large FSM to templates
It hapend a lot times, people make a large FSMs for something like, inventory, loops. and it makes hard to debug
what i want to say is: just split it to templates and add finnish action endof the FSM.

nest fsm:



finnish state:



5.
use templates +  "run fsm" to toggle FSMs and nest FSMs.
Stop use a lot FSM componnents to toggle things, it will make inspector lag and difficult to find FSM.

Bad Example:



Turn it into:





Walk setup:



Jump setup:




Example for NPCs:


jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Improve your FSM design magic
« Reply #1 on: July 08, 2019, 09:14:25 AM »
Hi,

 I am sorry, but I strongly disagree with you on this. While perfectly fine, your solution remove an entire section of visual scripting benefits, namely being able to visually follow what's going on even when not running and understand complex/dynamique sequences.

I am actually in favor of what you describe as not good fsm layouts, in many ways. to me they look fine and I am developing exactly like that myself. If I had to comment and critic the fsm you showed, it would be that they take too much responsability, and not because of their actual layout. To me, them layouts are perfectly readable and make sense with good naming conventions and clear sequencing/positioning.

I never use the go to name by state action, unless if by design I wanted a dynamic link to begin with, with is the case in 0.1% of all the cases I encountered in almost 9 years working with PlayMaker. One clear case is matching a mecanim Graph. I made an addon on the ecosystem which lets an Fsm have its state activated based on a mecanim graph. That scenario and its variants is fine.

The other cases, is when you clearly have spaghetti code, but in that case, I always recommend to split in multiple FSM, instead of going for linkless state transitions. Else I recommend to use local events as global transitions ( transition above the state).

Do you understand that your solution means less information in the end for the developer? I am not sure for your solutions that it's intuitive and clear. What if you end up with multiple cascading switch states, your fsm will make no sense very quickly because you won't be able to track down the path of execution easily.

Also, it's a very bad habit to not name states properly, in your cases, you lean states like "State 1" "State 2", and that's not recommended neither. Maybe you could share real fsm that your use in your projects? that would make more sense than making mock ups.

I hope you don't get mad at me for being straight on that topic :) but I think it's important to get feedback on this.

 Bye,

 Jean

waveform

  • Playmaker Newbie
  • *
  • Posts: 28
Re: Improve your FSM design magic
« Reply #2 on: July 08, 2019, 10:50:00 AM »
Hi Jean
thanks for the quick reply
2 years ago, i using 100% playmaker for my project,and decided to deprecate it, because the fsm is too complex to read and almost imposible to debug.

my old FSM looks similar to this image:





Afterthat I started learning code, and feel reading code is actually much easier than watching FSMs.

I got a new understanding of playmaker, I no longer use it as the core system, it`s more just a tool for assisting code, i also improved my FSM design to looks more similar to code, it works very well for me

my most complex FSM in current project





it looks very clean because everything is nested and splited

Hi,

 I am sorry, but I strongly disagree with you on this. While perfectly fine, your solution remove an entire section of visual scripting benefits, namely being able to visually follow what's going on even when not running and understand complex/dynamique sequences.

I am actually in favor of what you describe as not good fsm layouts, in many ways. to me they look fine and I am developing exactly like that myself. If I had to comment and critic the fsm you showed, it would be that they take too much responsability, and not because of their actual layout. To me, them layouts are perfectly readable and make sense with good naming conventions and clear sequencing/positioning.

I never use the go to name by state action, unless if by design I wanted a dynamic link to begin with, with is the case in 0.1% of all the cases I encountered in almost 9 years working with PlayMaker. One clear case is matching a mecanim Graph. I made an addon on the ecosystem which lets an Fsm have its state activated based on a mecanim graph. That scenario and its variants is fine.

The other cases, is when you clearly have spaghetti code, but in that case, I always recommend to split in multiple FSM, instead of going for linkless state transitions. Else I recommend to use local events as global transitions ( transition above the state).

Do you understand that your solution means less information in the end for the developer? I am not sure for your solutions that it's intuitive and clear. What if you end up with multiple cascading switch states, your fsm will make no sense very quickly because you won't be able to track down the path of execution easily.

Also, it's a very bad habit to not name states properly, in your cases, you lean states like "State 1" "State 2", and that's not recommended neither. Maybe you could share real fsm that your use in your projects? that would make more sense than making mock ups.

I hope you don't get mad at me for being straight on that topic :) but I think it's important to get feedback on this.

 Bye,

 Jean

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Improve your FSM design magic
« Reply #3 on: July 08, 2019, 12:23:08 PM »
Hi,

 Thanks for clarifying.

I would however still be careful if someone new to Playmaker reads your post, because I do not think that this is the most effective use of Playmaker by far, however, this is where Playmaker excels and is border line genius: Indeed it is flexible to be used in different ways, such as how you described it.

Bye,

 Jean



Thore

  • Sr. Member
  • ****
  • Posts: 480
Re: Improve your FSM design magic
« Reply #4 on: July 08, 2019, 02:42:36 PM »
Superb topic! I guess one take away is that there’s currently an expertise or tutorial gap for advanced Playmaker designs. For coding, there are all these best practices that are taught alongside the syntax. Playmaker takes care of the syntax, but the rest is still pretty important – and a bit missing.

I early on avoided large christmas trees of FSMs and split them up into units that make sense on their own.

I triangulate between three requirements: (1) keeping the FSM as small and containted as possible doing one clearly identifiable role (2) as little dependency as possible, and (3) while also avoiding redundancy.

In the first point, The “role” is either a mechanic or its representation, but not both, which I keep separate.  I currently work on input mechanics and try to keep them separate as well, but it’s not trivial. For example, the jump currently listens for a bool in another FSM. The Jump FSM itself applies the force, but does not contain anything about sound, animation or particles (“effects”). It only sends off an event that it’s now currently jumping to yet another Effects FSM which then sets everything to look and sound right.

I am curious about Jean’s super atomistic designs, especially how can I keep track of FSM dependency. It sounds you (Jean) use a thousand FSMs, handling miniscule tasks. How do you organise things? How am I going to remember in a few months that some mechanic is composed of three FSMs? How do I keep them syncronized? How do I organize the templates? I find templates a complete hassle at the moment, but eventually need them once I scale up.

One thing I ignored as a newbie, but learned to love are using paths on FSM names (e.g. Input/Jump) and global events, but there lies another danger. And while we are it, is there some way to talk to FSMs without going over a string for Send FSM? Occasionally I needed to refactor, but then every naming breaks and I have to sift through everything to update send to actions. Normally, in Unity, renaming does not break references.
« Last Edit: July 08, 2019, 02:44:50 PM by Thore »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: Improve your FSM design magic
« Reply #5 on: July 08, 2019, 06:56:52 PM »
Hi.
I also like to have more states and transitions that using 'go to state by name'
i have been using that a while but went back from that, when i had to trouble shoot some older project.

All my states are named and many have descriptions as we, so if ever i have to go back to the project a few years later it will be easy to read and find an issue or change something on it.

I do think that run fsm and using templates is a good thing, and the new run fsm on PM Beta looks Promission as it has input and output.

i also mostly use send event by name instead of send event.
I also have a fsm with all the references i need (send events/array maker/easysave/playerprefs keys.

Then on another fsm i will get the needed reference @start and then use the reference for sending events, accessing array lists, reference to save to easysave, etc..
This way if i want to change a reference name i only need to do this in the reference fsm (and on array list component for example)

btw i also recently noticed that you can set categories on templates which makes it easier to find them in the list.
Just select a template in the project window, and you can set a category in the inspector.
you can also use / for sub categories btw.

Other things i also do is color my states to 'group' certain states.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Improve your FSM design magic
« Reply #6 on: August 18, 2019, 07:24:18 PM »
Waveform's methodology obviously breaks the point of a FSM system but if it's not meant to be read by anyone else, then perhaps it's fine. It's a solid example of the potential of the "go to" action.
I think a proper FSM should have classic transitions, but you are going to meat the spaghetti problem sooner or later and it quickly becomes obvious you need to find a way to move the flux around without following visible links.
Typical way is with using local events to return to "zones" in your FSM.
Waveform's alternative is using gotos to do that, but he totally loses visual clues. However, it's his project so he knows what he's doing and it is indeed a great thing that one can go that way, but I would strongly advise against that.

I would just go nuts without being able to follow at least a minimal amount of obvious paths. Those paths have a simple and powerful function: to avoid putting useless (over)pressure on your own mental RAM to remember what every single state does and how it communicates with other ones under the hood.

I triangulate between three requirements: (1) keeping the FSM as small and containted as possible doing one clearly identifiable role (2) as little dependency as possible, and (3) while also avoiding redundancy.

In the first point, The “role” is either a mechanic or its representation, but not both, which I keep separate.  I currently work on input mechanics and try to keep them separate as well, but it’s not trivial. For example, the jump currently listens for a bool in another FSM. The Jump FSM itself applies the force, but does not contain anything about sound, animation or particles (“effects”). It only sends off an event that it’s now currently jumping to yet another Effects FSM which then sets everything to look and sound right.

Oh yes, that's sometimes a hard decision to take. It seems silly but I believe the same problem arises in coding; deciding what script will do what, even for very itty things. You want to have a FSM be logical and intuitive, so before you even know it, you start pushing bits of scripts here and there, perhaps wasting minutes or hours deciding if a function should be handled in this FSM or another one, not for efficiency but uniquely for the sake of order. And in the end, when being satisfied where a certain function is handled, it is actually satisfactory because you don't have to search for it beyond what is fairly obvious as to where it should be. So thinking a lot about how to organize and split FSMs is actually not a waste of time to me.

Quote
I am curious about Jean’s super atomistic designs, especially how can I keep track of FSM dependency. It sounds you (Jean) use a thousand FSMs, handling miniscule tasks. How do you organise things? How am I going to remember in a few months that some mechanic is composed of three FSMs? How do I keep them syncronized? How do I organize the templates? I find templates a complete hassle at the moment, but eventually need them once I scale up.

That's an interesting subtopic in itself. I hardly use FSM templates because I don't find them easy to access for data reading and I'm all too worried about them being created and destroyed as objects and therefore leaving an imprint on memory management.
Can they be recycled? Can a given number of FSM instances be pre-cached/pooled?

Quote
One thing I ignored as a newbie, but learned to love are using paths on FSM names (e.g. Input/Jump) and global events, but there lies another danger. And while we are it, is there some way to talk to FSMs without going over a string for Send FSM? Occasionally I needed to refactor, but then every naming breaks and I have to sift through everything to update send to actions. Normally, in Unity, renaming does not break references.

A tool would have to scan the entire project and its scenes to spot references to events. But since certain actions use text fields as arguments instead of dropdown options with automatically listed references for events or vars, it's harder I suppose to go up the tree and find those little isolated fruits.
It would be veeeeeerrrrrry useful though.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Improve your FSM design magic
« Reply #7 on: August 18, 2019, 07:33:08 PM »
i also mostly use send event by name instead of send event.

Any reason why? Doing so would tend to reduce even more the number of trackable references, right? Unless I get it wrong, Playmaker couldn't see these manually typed references? Or does it keep track of them too now, parsing all string fields in actions known for using events?

Quote
I also have a fsm with all the references i need (send events/array maker/easysave/playerprefs keys.
Then on another fsm i will get the needed reference @start and then use the reference for sending events, accessing array lists, reference to save to easysave, etc..
This way if i want to change a reference name i only need to do this in the reference fsm (and on array list component for example)

The anti-Globals inquisition strikes again!  ;D

Quote
Other things i also do is color my states to 'group' certain states.

Interesting.
The problem with colours is that a large range of them cannot be used because the text remains white. If text colour could auto change to black (or allow colour to be manually set) or/and also allow outlines/underlines on the text, this problem might be solved.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Improve your FSM design magic
« Reply #8 on: August 19, 2019, 02:36:49 AM »
For coding, there are all these best practices that are taught alongside the syntax.

I wish it was the case... but after so many years on google trying to find the best way to code, I have to say that I did not found these best practices to be available in any other form than by small chunk of advices spreaded out across forums and videos. Pretty much the same as with PlayMaker or any other complex systems. Even Unity own Learning content material is riddles with various memory leaks, bad coding strategies, etc etc.

 I don't think there is any other way to learn the best practice then by practicing yourself and along the way pick up a vibe and "intuition" as to how to start a feature, where to create flexibility, where it doesn't matter, where to make sure it performs sharply and where it doesn't matter, and always be curious as to how other would have tackled this, and google for it, ask questions, etc...

Only personal experience can encompass this level of expertise.

Bye,

 Jean



jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Improve your FSM design magic
« Reply #9 on: August 19, 2019, 02:47:12 AM »

I am curious about Jean’s super atomistic designs, especially how can I keep track of FSM dependency. It sounds you (Jean) use a thousand FSMs, handling miniscule tasks. How do you organise things? How am I going to remember in a few months that some mechanic is composed of three FSMs? How do I keep them syncronized? How do I organize the templates? I find templates a complete hassle at the moment, but eventually need them once I scale up.

I don't use template that much, maybe for buttons, panels, and very high level features like that.

 2019 and the new nested prefab makes thing so much easier now anyway.

I use indeed micro fsm a lot, I keep track of it by simply making sure I stick to my strategy on design pattern, then all fsm pretty much look the same, and are expected to perform the same, as far as their responsability, what they could send, what they could want to receive and read, hence the "meta data" fsm, the very descriptive/organized event naming convention, and careful naming of everything, withoitu fear of refactoring should this naming become obsolete and needs refactoring (which happens always, on real world project, where client changes his mind of tells you the key to the project logic mid production...)

Since I went for micro fsm, I realized that  "Divide to conquer" is essential, it works every where, not just in lifef ro good or evile reasons... it works magically for coding. Again, I'll use the Lego analogy, Lego is a wonderful structural guide, make small blocks that you can reuse, like at a prefab level,  but templates, are also part of this.

Yesterday, someone brought me back a book that for me changes my views and sharpened my understanding of coding and how to approach it. I recommend it to everyone, it's meant for project managers, but it's exactly the right level of explanation needed when you are in the blur or want to learn the core of what you are doing.

https://www.amazon.com/Object-Technology-Managers-David-Taylor/dp/0201309947


Bye,

 Jean

Thore

  • Sr. Member
  • ****
  • Posts: 480
Re: Improve your FSM design magic
« Reply #10 on: August 19, 2019, 12:50:52 PM »
I don't use template that much, maybe for buttons, panels, and very high level features like that.

 2019 and the new nested prefab makes thing so much easier now anyway.

I use indeed micro fsm a lot, ...

Can you give an example how :) or walk through a mechanic? Or maybe you did that already, and could you provide a link?

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Improve your FSM design magic
« Reply #11 on: August 21, 2019, 02:21:02 AM »
Hi,

For micro fsm, check out the 2d platformer sample, it uses this technic.

https://hutonggames.com/playmakerforum/index.php?topic=11881.msg55471#msg55471

For nested prefab, It's not really related to PlayMaker per say, and I don't have any samples using the new nested prefab yet.

As for prefabs and reusable templates on complex project, check out the meface sample on the ecosystem.

https://twitter.com/JeanAtPlayMaker/status/968773939630571520

Bye,

 Jean

Twood

  • Junior Playmaker
  • **
  • Posts: 76
Re: Improve your FSM design magic
« Reply #12 on: October 21, 2021, 12:50:37 AM »
It's an interesting topic.

Personally I'm of the style where I started with spaghetti FSM where I needed them, but I did get visually frustrated dealing with the larger ones. I think people have different levels of visual tolerances and large FSMs I would find myself wishing it was easy to just hide transition lines for a minute, or group by folders or something. So I understand why some people switch to trying to design to minimize complexity.

But in my opinion these are helpful too: Conditional Expression action. You can easily do multiple kinds of checks in one spot with the AND / OR operators instead of worrying about bugs in multiple actions/states. The live error checking on it is also REALLY cool. Really nice for games with "deeper" mechanics under the hood.

Another good thing is templates as has been mentioned. They keep from putting too much of the FSM on one screen, which is great sometimes.

I'd also add though, look at some of the data options if you've got a lot of variables, so you don't have to search all over in the editor. Setting up XML for your game and having your own easy to work with database might appeal to you, and will probably just take you an evening or two to figure out.

Those are my 2 cents on workflow anyway, having use PM a lot this year

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Improve your FSM design magic
« Reply #13 on: October 27, 2021, 01:14:25 PM »
Switches
By experience I can say that, actually, the first switch example is very appropriate.
I did try GoTo solutions in several FSMs over the years, to limit the drawing of links, but I find that no matter what, they make the reading more confusing. The reason being that entering Playmaker, you know what to expect. I would sometimes forget about the GoTo implied linking, so it was a hassle more than a freeing power.
By default you expect to see a link or a Global event black box. Even using descriptions in the states didn't cut it. Besides, there's no way to trace the GoTo "event" easily, these transitions are invisible to a Playmaker's user.

As said in another thread, I'd rather have the ability to make some solid links to be dotted or dashed in cases they'd be considered optional (like in a GoTo) and have mouse-placed discs to control the path followed by links and their bending, and also be able to group links so they run parallel to each other, like you do in IT when grouping physical cables in servers or behind computer desks.

The mess of links is due to Playmaker's rigid convention regarding local links: entrance is done by the left, exit through the right. The exit direction can be changed though, it's preferable sometimes to do so. Transitions can also be moved up or down to avoid crisscrossing links.
Logical diagrams normally allow links to exit a node left, down or right usually, with the first node being at the top.
In your "more" example for switches, with a reformed convention, you could have four parallel lines (links), slightly spaced, coming from the bottom of the state "Check", then they would split into two groups, two going to the left into "Frog" and "Elf", two to the right into "Wolf" and "Necromancer". It would look particularly clean in 'circuit' display mode.

I remember also suggesting a condensed display for FINISHED so we could also stack states when the structure is fairly simple (as here), instead of having these spaces between states and these links and arrows leaving and reentering the stack.


Action sequence
There is nothing "bad" about the first example. It should actually be the display choice followed by most users and it's far clearer.
That does not mean I do not use sometimes the cheating option that allows for an early exit within a state (FINISHED or else), but I try to keep these choices to cases where the gain is really meaningful.
True/False, Yes/No, Success/Failure, etc. are really very helpful and you do not need to enter a state to see what's going inside.
For these types of states that do such binary comparisons, I'd strongly suggest using some colour scheme in positive/negative cases, with green colour for the positive outcome and some red for the negative one.
When there's a neutral, so-so third option, use yellow.

Your third example could make use of "Use transition event" set to True at the bottom of the action stack, it would allow you to have both True and False transitions exiting the state.

Overall, the parent/child Graph View displaybwould really be better if right where the template FSM's name is located, a ’Parent>Child' would appear, with 'Parent' being interactive and taking you back to said parent, the one that launches the Run FSM, and 'Child' obviously being the template, like a deep link.


Events
Quote
I have seen people use events for any thing and every thing, it end a huge number  of events to make project very difficult to debug and manage.

There is indeed a severe lack of transparency on the management of events and the data or properties they can carry. Alex replied positively to this remark a long time ago and seemed to agree that events related tools should be expanded upon. I just hope the PM guys have not forgotten about this, especially since I experienced annoying cases when events had issues being carried over to other FSMs or even lost all data and nothing could be collected on the other end.
So there is definitely a good argument to make in limiting, sometimes, the use of events.

Now, the solution of forcing the flow into a given state in a GoTo way from a component (like a button) is an interesting choice but in some of my setups that would have been impossible because I needed to control the ability to receive events. Besides, GoTo-like solutions don't leave much traces in the FSM log so perhaps someone should do this only if your FSM is really begging for clarity and you won't go back into it anytime soon, so it can stay like that forever, or because nobody else will need to take a look at it.

This would not be so much of a problem if states had a little indicator that they were targeted, either by an event, a GoTo flow-sender or simply an action in another FSM keeping an eye on where the flow currently is in another observed FSM.
A bit more self-awareness would certainly help, especially since those little symbols, whatever they would be, would double as menus showing the list of targeting FSM:State:Action(s).


Templates
I unfortunately have never found enough evidence about the management of memory regarding spawned FSMs and I have always been a little bit suspicious of some potential clogging down the line.
Nevertheless, they're rather useful but here again, using a specific colour for states that use Run FSM would be advised.

I still prefer to use several FSM components, although Unity isn't meant to be used that way and it would be better if PM could group them. Basically there would be just one big meta FSM component or proxy containing all other FSMs.
Right now what is annoying is how Unity expands or collapses all components and I wish I could control the setup and fix it at once for a given game object without seeing all my carefully arranged Inspector be reset.

This may be solved by simply opening a new tab and locking each Inspector for a specific FSM but that's so much extra work instead of being able to expand or collapse FSMs' content.
« Last Edit: October 27, 2021, 01:54:53 PM by Broken Stylus »

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Improve your FSM design magic
« Reply #14 on: November 03, 2021, 07:46:08 AM »
It's possible that most new users to Playmaker would expect this to be already implemented.
There is a bit of irony right there in PM's logo featuring an Asiatic symbol but not allow the ordering of its own states in a purely and strictly vertical fashion. >:}
The only confusion I can see thus far is that users would have to remember that it would not be exclusive to Global Transitions anymore. Perhaps the style of a GT's link should be slightly modified to become truly exclusive then instead of simply being black. A black link can also be done manually for any transition.
Perhaps a GT's link should be thicker, or undulating, or look like how motorways are shown on maps?
Logically, a downward link could only apply to the last transition in a state's transition stack, but it would also not need to be limited to the FINISHED system transition.
This reminds me that I talked about it elsewhere, at other times.

Logical diagrams normally allow links to exit a node left, down or right usually, with the first node being at the top.
In your "more" example for switches, with a reformed convention, you could have four parallel lines (links), slightly spaced, coming from the bottom of the state "Check", then they would split into two groups, two going to the left into "Frog" and "Elf", two to the right into "Wolf" and "Necromancer". It would look particularly clean in 'circuit' display mode.

I remember also suggesting a condensed display for FINISHED so we could also stack states when the structure is fairly simple (as here), instead of having these spaces between states and these links and arrows leaving and reentering the stack.

The downward link paves the way for more options. In the quotation above I refer to an older thread I posted:
On the purpose of displaying the FINISHED transition
It is obvious that once you can align states vertically, you could gain even more space by stacking them like Lego boxes, with no space in between.
So I'll link to an even older thread which contains this same suggestion plus a few other ones, just in case:
Vertical transition link + auto-align + stacking
I spoke of vertical links, aligning states (that's mostly a UI option for the sake of graphical prettiness) and stacking states.

More people should come here and second this.