playMaker

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

waveform

  • Playmaker Newbie
  • *
  • Posts: 24
    • 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: 14210
  • 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: 24
    • 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: 14210
  • 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: 253
    • 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: 4288
    • 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.