playMaker

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

waveform

  • Playmaker Newbie
  • *
  • Posts: 28
    • View Profile
Improve your FSM design magic
« on: July 08, 2019, 05: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: 14400
  • Official Playmaker Support
    • View Profile
Re: Improve your FSM design magic
« Reply #1 on: July 08, 2019, 06: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
    • View Profile
Re: Improve your FSM design magic
« Reply #2 on: July 08, 2019, 07: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: 14400
  • Official Playmaker Support
    • View Profile
Re: Improve your FSM design magic
« Reply #3 on: July 08, 2019, 09:23:08 AM »
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: 307
    • View Profile
Re: Improve your FSM design magic
« Reply #4 on: July 08, 2019, 11:42:36 AM »
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, 11:44:50 AM by Thore »

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 4466
    • View Profile
    • jinxtergames
Re: Improve your FSM design magic
« Reply #5 on: July 08, 2019, 03: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.
FOR HIRE:Playmaker/C#

Playmaker Samples <-------------> Easy Exporter <---------------------> TPA Actions

Broken Stylus

  • Full Member
  • ***
  • Posts: 216
    • View Profile
Re: Improve your FSM design magic
« Reply #6 on: August 18, 2019, 04: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

  • Full Member
  • ***
  • Posts: 216
    • View Profile
Re: Improve your FSM design magic
« Reply #7 on: August 18, 2019, 04: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: 14400
  • Official Playmaker Support
    • View Profile
Re: Improve your FSM design magic
« Reply #8 on: August 18, 2019, 11:36:49 PM »
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: 14400
  • Official Playmaker Support
    • View Profile
Re: Improve your FSM design magic
« Reply #9 on: August 18, 2019, 11:47:12 PM »

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: 307
    • View Profile
Re: Improve your FSM design magic
« Reply #10 on: August 19, 2019, 09:50:52 AM »
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: 14400
  • Official Playmaker Support
    • View Profile
Re: Improve your FSM design magic
« Reply #11 on: August 20, 2019, 11:21:02 PM »
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